プロジェクトにおける検討の順序は何が正解か
私が在籍している会社の製品特有の話なのかどうかはわかりかねるのですが、お客様にて新システムを検討する順序が正しくないように思えるケースが結構あります。
私がオススメすべき検討順序を先にご紹介したいと思います。
お勧めする検討順序
業務・ITの課題の整理
システムは業務を支援するものです。基幹システムと言われるようなものであればなおのこと、業務と密接に関係してきます。従って、最初に検討すべきは「現在の課題と、業務としてどういうコトをやりたいか」なのかを話し合うことです。一見すると要件定義のように思えますが、実はその前の段階の話です。ただし、ココをFIXしないと全て無駄になるのかというと、そうではありません。業務は生き物であり、情勢によっていくらでも変わります。なのでココで重要なのは検討事項をFixさせること自体ではなく、「業務側の誰がオーナーシップをもって進める決意をするか」です。もし業務側の意識が「IT側が良いように進めてくれれば良い」となってしまうと、最終的に「コレジャナイ」になります。ほぼ100%で。
アプリケーションアーキテクチャと開発手法の仮説立案
次にやることは、その課題ややりたいコトを実現するための俯瞰的な全体像を描くことになります。しかし、ITとしてのプラットフォームからアプリまでの詳細を描くことではありません。フォーカスすべきは、アプリのアーキテクチャと開発手法になります。どういうアーキテクチャであれば破綻しないか、どういう開発手法であれば品質を高められるかを検討します。コストについても重要ではありますが、この時点で全体でいくら掛かるかはまだわからないので、費用の提出をベンダーに求めても、リスク込みのとてつもなく高いものしか出てきません。
アプリケーションアーキテクチャと開発手法の仮説の検証
アプリケーションのアーキテクチャと開発手法についてある程度の仮説（コンセプト）ができたら、まずはそれが正しいかどうかの検証をすることをおすすめします。一般的にはこれを、Proof of Concept (仮説検証、以下PoCと略）と言います。この仮説検証に膨大な時間を掛けることは出来ないと思いますので、是非その道のプロフェッショナルをご指名いただきたいのです。検証すべきは、主に下記のようなものになります。
・このアーキテクチャを採用することで、現行システムにおける課題の解決が図れるか
・このアーキテクチャを採用することで、持続的な業務の変化に迅速に対応出来ると考えられるか
・このアーキテクチャを採用することで、性能問題に対して柔軟に対応できるか
・この開発手法を採用することで、個々の品質の向上が図れるか
・この開発手法を採用することで、全体工数の削減が図れるか
・この開発手法を採用することで、業務部門とIT部門がより密接な関係になれるか ... 等。
単純にアプリを作って「できるか／できないか」を評価するのではなく、コンセプトを理解し評価することが目的です。PoCで作ったものを改造してそのまま使おう、なんて考えは絶対にしてはいけません。なぜなら、方向性の仮説の検証をしただけであり、業務要件やシステム要件を満たすほどの実装はしていないからです。
そうは言っても、予算だって限られているわけだし、生産性を最大化するよう厳命されているんだ！とおっしゃる方、痛いほどそのお気持ちは理解します。ですが、このPoCというフェーズは大体2-3ヶ月で行います。PoCで全てが出来ていしまうくらい簡単なシステムであったのでしょうか？ PoCでは、ユースケースの1か2つが通る程度しかできません。
先日も、PoCで実装したものをそのまま流用されているお客様がいらっしゃいました。PoCではシステム要件が定まっていないため、データが画面から1件来たらその答えを返す程度で作っていました。2年後、それを100万件を一気にバッチ処理として投入したところ、遅くて動かないとクレームされてきました。はい、事前に提示されていないことまでカバーするほど、我々は未来を予知できる神様ではありません。100万件をどのくらいの時間で処理しなければならないか程度の情報があれば、全体のアーキテクチャも含めて提示することは可能です。
他でも同じようなお客様がいらっしゃいました。皆様、作り直しが必要な状態で、余計なコストがかかっております。PoCでの成果物をそのまま流用するのではなく、改めて要件を確認した上で、使えるなら使う、問題がありそうであれば見直すということをやるべきです。
プラットフォームアーキテクチャの仮説立案と検証
アーキテクチャと開発手法についてコンセンサスが取れたら、次はプラットフォームのアーキテクチャを検討します。アプリケーション・アーキテクチャが有効に機能し、開発手法にもマッチしたプラットフォームを検討するのがベストです。そのプラットフォームでどのような運用ができるか、想定図を描くことも必要となってきます。マイクロサービスアーキテクチャを採用されるのであれば、オンプレミス/パブリッククラウドかは別としても、コンテナ環境を利用するのは理にかなっています。なぜなら、コンテナ環境というものが、マイクロサービスなアプリケーションを稼働させることを前提に考えられているからです。また、繰り返し型開発も、コンテナ環境ではベストマッチです。
マイクロサービスアーキテクチャでもなく従来のウォーターフォール開発を選ばれた方も、アプリケーションの使い方を考えたあとにプラットフォームを選択する順序を強くお勧めします。
またまた経験談になりますが、先にプラットフォーム（ハードウェアとOS）を決めてしまっていて、その上で動かすよう言われたプロジェクトをやったことがあります。性能目標が、開発前に伺っていたのは秒3件だったところ、開発終了前に突然、秒100件出して欲しいと言われました。ある程度のチューニングもやりますが、さすがにハードウェアの増強も必要ですと進言しましたが、ハードウェアはもう決まっていて動かせない、なんとかして欲しいと。連日徹夜で対応しましたが、当初のアーキテクチャを全て壊し、メンテナンス性を犠牲にするようなコードを書いても達成は難しく、ギブアップした経験があります。こうなると、誰も幸せにはなれません。（そのプロジェクトは他の手段でやっても同じ結果となり、2倍掛かった費用も無駄になったと聞きました...）
プラットフォームアキテクチャの仮説の検証も、出来ることがあればやったほうが良いです。自社にオンプレミスでの構築を考えているとなると、物理的なハードウェアが揃うまで検証ができません。パブリッククラウドを使う前提であれば、結構簡単にかつ低価格で動作の確認などはできます。そういう観点でもクラウドの利用はお勧めしたいところですが、クラウドのインフラの障害からのリカバリー検証は、残念ながら難しいでしょう。
ここまでの仮説検証は、検討すべき項目数などからすると。一回ですべてをカバーすることはほぼ不可能です。そのため、ベースを作って、必要な分だけ繰返して追加検証するような方式がおすすめです。このやり方こそが、アジャイル開発の基礎になります。
製品の選定
アプリケーションのアーキテクチャ、プラットフォームのアーキテクチャが揃ったら、どの製品で行うかの選定を行います。すでに決定事項のある状態で製品の説明を聞くわけなので、営業トークによって方針がブレることも無くなります。
最初に製品選定をしてしまうこと、特にHWやプラットフォームの製品を先に決めてしまうことは、上記の例の通りリスクでしかありません。どういうアプリケーションをどのようなアーキテクチャで動かすのか、想定したデータを流してどのくらいの性能のCPUやメモリが必要なのかをあらかた計算してから、製品を選定すべきなのです。
試行開発
製品を決定したら、試行開発を行います。検討に沿ったアーキテクチャ、体制、環境、期間で本当に出来るかどうかの、プロジェクトのテストを行います。プロジェクトの最初の段階なので、技術的な問題は多発すると思われますが、それをこの初期の段階で解決しておくことで、その後の開発がスムースに進みます。行うことはプロジェクトとして、参加者と役割についても検証します。作成したプロトタイプについては、機能テストだけではなく性能面も想定したテストを行います。最初に設計が詰められていないところ、必要なCPUやメモリ、記憶媒体の性能などの見通しをつけます。
ここまで行うと、全体でどのくらいの工数・期間・費用が必要かが判明してきます。経営陣からの承認が得られれば、あとは常に「カイゼン」の精神を持って、不具合を早い段階で潰すこと（つまり、品質を高めること）を念頭に進めるだけになります。
まとめると、下記のような絵になります。
お勧めしない検討例
上記にも書いていますが、改めてまとめてみました。
プラットフォームを最初に決める
動かすアプリケーションの特性や現在の課題を吟味しないまま、プラットフォームだけを先に選択してしまうと、開発言語や拡張性などの観点で、より良い選択肢が選べなくなってしまいます。プラットフォームを導入したものの、その上で走らせるアプリケーションが無い状態にもなってしまいます。国内外のお客様を見ても、このパターンは本当によく目にします。特に、アプリ本体の構造改革をせずに既存アプリのマイグレーションをやっている場合が顕著にその傾向にあります。
プラットフォームへの過剰な投資によって、アプリケーションへの投資が少なくなり、以前より使い勝手の良くないアプリケーションが作られる等、負のスパイラルに陥っていることも見受けられます。
アーキテクチャや開発手法よりも使う製品を先に決める
おそらくはパッケージ製品を買う感覚のまま、フルスクラッチをやろうとしているのではないかと思われます。製品を決めてからアーキテクチャや開発手法を決めようとすると、その製品の特性や制約、時にはセールストークに縛られて、理想とするアーキテクチャや開発手法を取ることができません。概念と実装は別であることを確認いただき、まずは概念レベルは製品にとらわれること無く策定しておき、ブレない骨太の方針を作っておくべきなのです。
PoCや試行開発をしない
全体の工数を計上する際によく用いられているのが、過去のソースコードの量と経済産業省が出している言語による生産性の標準値があります。過去のソースコードベースで計算しても、不必要な機能は実装すべきではないですし、大概の計画は大幅なリスク込みのスケジュールと工数になりがちです。そうなると費用は自ずと高止まりし、費用削減を行うために過去に作成したものは極力使いまわせという、理想とは真逆の構成になっていきます。それをやるなら、今の仕組みを変えないほうが良いとさえ私は思います。
アーキテクチャや開発手法についての策定を行ったのであれば、それでどの程度の開発工数になるのか、想定した体制、製品を使って試行的に開発をやってみることを強くお勧めします。対象は、一番難しいところ（複雑である・性能的に厳しい条件である等）がよいです。難関クラスでどの程度の工数が必要なのかがわかれば、それより簡単なものは、どんなにかかっても難関クラスをMAXと考えればよく、工数の合計としてそうそう足はでないはずです。
また、PoCやった工数、品質と、現行システムの同じような部分での工数の実績を比較することで、投資対効果はある程度見えてきます。過去の工数に対してどのくらいの低減率が期待できるかがわかれば、全体の工数や必要な体制ももっと明確化されていきます。
まとめ
何が正解か というタイトルを付けましたが、本当に正解なのかどうかは、日々新しい考え方や技術が出てきている中で、正直わかりません。ここでは私の複数のプロジェクトを経験した観点で書いてみました。いかがでしょうか。ご参考になれば幸いです。
ご意見・お問い合わせなどありましたら、ぜひご連絡ください！
この記事が気に入ったらサポートをしてみませんか？