Services
サービス紹介
Alcogyでは、プロトタイプによる検証を経て本開発を行う「プロトタイプ開発」を採用したシステム開発を行っています。体験重視の要件定義でIT化やDXの効果の向上が期待できます。また、システム開発をより身近で気軽にするため、小規模な依頼向けの「クイック開発」、自社プロダクトを基盤にした「カスタマイズ」を展開しています。
Prototype Development
プロトタイプ開発は「完成後のシステムを開発前に検証する」ようなイメージで進める開発モデルです。画面モックアップや資料の補足程度ではなく、実際にデータの入力・保存・閲覧・操作ができる「動くシステム」としてプロトタイプを構築します。作成したプロトタイプは現場のユーザー様に検証を行っていただき、フィードバックを反映させてプロトタイプを改善しながら要件定義を作成します。
要件定義が完成した後に開発を進めます。プロトタイプをベースにすることで効率的に開発が行えるため安定した進捗が可能です。また、開発後の受け入れについても「思っていたものと違う」を減らすことができ、スムーズなリリースが可能です。
Pillars
Architect
システムには様々な仕組みが存在し、それらを適切に設計するアーキテクトは、超上流工程を支える重要な役割です。「言われたものをただ作る」のではなく「現場が本当に必要なものを形にする」ために、私たちはアーキテクトを大切にしています。
Prototyping
私たちのプロトタイプは「完全型プロトタイプ」を採用しています。UIからデータ登録までを一通り行い、動くシステムとして作り上げているのが特徴です。これにより、完成後のシステムを開発前に検証することができるため、高い精度の要件定義を行えます。
Development
プロトタイピングで固まった要件定義から本開発を行います。業務システムに特化した技術スタックやアーキテクチャを採用しているため、効率的な開発が行えます。また、プロトタイプの構造をそのまま流用できるためゼロから作るよりも高い生産性で開発を進められます。
Cases
プロトタイプ開発は、システム開発でよくある課題を解決します。新規開発はもちろん、保守開発でも大きく貢献してくれます。 実際にプロトタイピングを用いたことで解決できた事例を紹介します。
1. リリースが圧倒的にスムーズになった
これまでのウォーターフォール開発では、受け入れ試験やリリース直後で「ここの仕様はこうしてほしかった」「思ったような使い方ができない」などの問題が多発していました。そのため、リリース前後はあわただしく修正やスケジュール調整が行われ、リリース自体が延期になったこともあります。プロトタイプ開発を採用したところ、要件定義の段階で仕様の認識齟齬やUXの確認ができたため、これらの問題が解決され安定的にスムーズなリリースができるようになりました。
2. 現場に定着する機能か適切に判断ができた
実装された機能が使われないということがあります。システム開発においては機能が使われなくても開発費用は発生し、パフォーマンスや品質は低下します。機能を維持するために保守コストも増えます。そのため、搭載する機能は戦略的機能を除いて必要最小限にとどめることが理想ですが、実際には必要な機能と不要な機能はリリースして現場で使ってもらうまではわかりません。プロトタイプ開発を採用してからは、要件定義の段階で業務への適応や、適切なUI/UXで実装されているかを確認できるため、本当に現場で使われる機能かどうかを開発前に見極められるようになりました。
3. A案／B案の検証を確実なものにした
開発プロジェクトではときどき「こういう背景でこういう目的に対してこっちの機能がいいか、それともこっちがいいか」と迷われることは少なくありません。ウォーターフォールでは、それぞれの開発工数やメリット・デメリットを資料にまとめて比較する程度にとどまっていました。プロトタイプ開発では、A案とB案の両方をそれぞれ実装したものを切り替えて、実際に触って比較することで、正確で早い意思決定が可能になりました。
Other Services
Quick Development
クイック開発
超小規模なマイクロシステムやITツールの開発をします。保守契約も任意のため必要な運用コストはお客様自身が管理するサービスの実費のみ。コストや期間を抑えたDXやMVP開発にも最適です。 クイック開発はこちら →
Customization
プロダクトのカスタマイズ
Alcogyが開発するAIネイティブなプロダクトを基盤に、画面や機能、データ構造をカスタマイズして導入します。ゼロから作るよりも短期間で、業務にフィットしたシステムを立ち上げられます。 プロダクト一覧はこちら →
FAQ
プロトタイプは必要ですか？
プロトタイプは単純な見た目の確認ではなく、企画しているシステムが現場や業務に沿うのかを確認するために必須と考えています。事実として、DXやシステム開発の多くは、要件定義不足と呼ばれる事前の調査やシステム機能や運用確認が不十分によることが原因で失敗しています。これらを防ぐためにプロトタイピングを行います。ただし、現場での検証が行えない、まずは必要最小限の機能だけを作りたいなどで、プロトタイピングが適さないと判断した場合は、そのまま本開発に進みます。
プロトタイプはどの程度まで作り込みますか？
モックアップや画面デザインではなく、実際にデータの入力・保存・閲覧・操作ができる動作するシステムとして作ります。本番開発前に現場で実際の業務フローを試行できる水準を目指しています。ただし本番システムと完全に同等ではなく、セキュリティ・パフォーマンス・大量データ処理などの本番要件は本開発フェーズで対応します。プロトタイプの目的は「これを作れば業務が回るか」を実証することです。
プロトタイプ開発以外は受けてもらえないのでしょうか？
基本的には既存の業務に対してのシステム開発ということでプロトタイプ開発を提案させていただいております。しかし、「新しいプロジェクトのため現場での検証ができず、まずは走り出してから考えたい」や「必要な機能だけの最小限開発からはじめたい」などをご希望の場合は、プロトタイプ開発ではなく、アジャイル開発やクイック開発にて対応させていただきます。開発の進め方によっては要件定義にプロトタイプを使用する場合もあります。
プロトタイプ開発でシステム開発の失敗を防げるって本当ですか？
厳密には、「プロトタイプを用いて、開発前に現場での運用を十分に検証する」ことで失敗を防ぐことができます。これはシステム開発における失敗の原因のほとんどが「要件定義が不十分」「現場の意見が反映されていない仕様」「ベンダーに丸投げ」のためです。これらを解消するために現場での運用検証を必ず行う必要がありますが、プロトタイプを担当者の確認だけで終わらせるだけであれば、担当者と現場での認識の違いを解消できず問題解決には至りにくいです。
自社の業務データをAIに読み込ませても大丈夫ですか？
気になる点だと思います。PoCの段階では実データではなく、類似構造のダミーデータやマスキングしたデータで検証することも可能です。本番導入時は、データの取り扱い方針や利用するAIサービスのセキュリティ要件を踏まえた上で設計します。
AI機能を含める場合、期間や費用は変わりますか？
費用は上がります。通常のインフラに加えて生成AIのAPIなどを別途利用する必要があり、従量課金のためAIを使わない場合と比べると増加します。ただし、大量のデータを繰り返し読み込ませる・大人数で毎日チャットを検証する・不必要に大規模なモデルを使用する、といった使い方をしない限り大幅な増加にはなりません。目安としては全体費用の10〜15%程度の増加とお考えください。
サービスに関するご相談・ご提案はお気軽にどうぞ。
お問い合わせ