プロジェクトの予算承認という課題
Application Modernizationという、既存のアプリケーションをモダンに作り変える提案をいろいろなところでやっています。アプリケーションアーキテクチャ、プロジェクトの流れ、品質の管理等多岐にわたって色々ご説明しています。その内容については今後順次公開していきたいと思っています。私の拙い説明にも納得いただけるお客様が多数いらっしゃいまして、ありがたい限りです。
ですが一方で、「言っていることは理解できる。しかし、もう一歩踏み込めない。」というお客様もいらっしゃいます。今日はそこで出ている課題について書きます。
Return On Investiment (ROI) を示さないと上層部を説得できない！
わかります。費用を出すには効果が見込まれていないと予算化が難しい。経営視点からすれば、効果が無いものに対して費用を垂れ流すわけにはいきません。説得するための資料として、ROIがわかるものを提出する必要があります。
製品を採用した場合や手作りをした場合等、複数のシナリオを立てて導入する製品の金額、設計・構築する費用、運用の費用を算出し比較する必要がありますね（お買い物が大好きな人は意外と楽しかったり...）。製品の金額は「定価」「標準小売価格」等が大体の場合存在しているので目安を付けやすいです。問題は「設計・構築する費用」です。
今までと同じアーキテクチャ・同じやり方で設計構築するのであれば、過去の経験から見積と効果が見えやすいです。しかし、過去と同じことをやるのであれば、モダンに作り変える必要も無いですよね？ つまりこれは考慮に値しないのが一般的です。
お客様の上層部はイノベーションを求めてます。提案側はイノベーションを起こすための「新しいツール」「新しい手法」を提案します。しかし、お客様のシステム部門の現場は、責任問題を回避するために「実績のあるツール」「実績のある手法」に固執される傾向が強いのです。そして、見積の妥当性を定量的に測る方法として、ソースコードのステップ数で測ろうとします。そうすると、製品で自動生成されるソースコードの量とスクラッチ開発時でのソースコードの量を比較したり、CI/CDをやると言いつつWaterfallな開発手法を取るなど、そもそも論...的なおかしな話が噴出します。最終的にはその中で「コスト」だけが独り歩きして、上層部の意思決定として一番安いもので決定してしまうということになってませんかね？
Return on Investment と言う言葉は、日本語に訳せば「投資に対する効果」のはずです。それを「投資金額」だけで判断するのは間違いなのではと強く思っています。効果とは、「想定しているものが、品質良く作成・稼働し、それによって会社に恩恵がある」ところまでなのではないでしょうか。つまり、初期の構築費用だけではなく、その後のメンテナンス性、業務に変更があった場合に速やかに対応できる仕組みでありつづけることまでを考えるべきかと思います。
もちろん、先の話なんてわかりません。このblogを書いている(2020/4/8)間も、新型コロナウィルス感染症予防のために緊急自体宣言が発令されていますが、6ヶ月前に予見できたかといえば、そんなことは無理でした。ならば、先のことを考えずに今の投資だけ抑えるべきなのでは？という考えも、一部理解はできます。ですが、業務のプロセスや基準を自由に組み替えられる仕組みがあったら、危機へのインパクトも低減できるはずで、ベネフィットを過小評価した考えは投資ではないと思います。
ROIを出す必要がある場合は、初期の開発コストだけではなく、5年間での経営計画に則った業績の数値を出してみてはいかがでしょうか。例えば構築するシステムで年3%の改善（コストダウンや収益の増加等）が見込めるReturnとして計算することで、投資金額としていくら位が妥当なのかもわかるはずです。Investment を最小化、Returnを最大化せよというのはわかりますが、何事もバランスが必要ですし、めちゃくちゃ美味しい話はそうそう転がってないものです。
新しい開発手法では見積もれない
「システムはWaterfallで構築し、瑕疵担保責任付きの請負契約で作ってもらうものだ。なぜなら全体の工数がわかってからでないと予算承認ができないし、責任分界点も見えにくいから。」
そう言われるお客様の多いこと、多いこと... 私も心が折れそうになります...
ITのシステム構築費用の算出は、建築業などがお手本になっています。箱やインフラを作れば、あとは自由にできるというところから来ているのでしょうか。未だに官公庁ではシステムの構築のこと「工事」と言っていたりします。ところが、ソフトウェアである業務アプリケーションは、箱やインフラではないのです。箱の中身になるわけなので、そもそも算出方法も工法も違うはずです。無理やり合わせていることにすごく違和感があるのは私だけではないはず。
ならば、私が今ここで宣言します！
変えましょう！ アプリケーションの 構築手法と見積手法。
私が提唱しているのは「イテレーション開発」。AgileやScrumのようですが、それよりも少し粒度を大きくし、1週間〜8週間で要件の整理・設計・開発・テスト・振返りを行うスタイルで、完成基準を満たしたら初めてリリースできる手法です。この手法の目的は品質の向上です。小さな目標を立てて、そこまで作ったら必ずテストを行い、問題の早期発見と修正をしやすくすることで問題が大きくならない、手戻りが発生しない、要望に柔軟に対応しつつ品質良く短期間で開発が終了するという特徴のある方式です。（別途紹介したいと思います）
良いのはわかるが、これにどれだけの予算を計上するのか。いつまでも繰り返し開発が発生して、当初の予想より費用がかかってしまうのではないか？という疑念が踏み切れない理由かと思います。最初に全体がわからないというのはその通りですが、ではWalterfallなら完璧に全体が把握できるのでしょうか？無傷で終わる大規模プロジェクトは見たことがありません！
コトを大きくするから難しいのです。開発規模を小さくしてみれば見積もしやすいのです。例えば、イテレーションの期間を、4週間等と区切ってしまえば見積はしやすいはずです。最初の1回は8週間等、少し長めに期間を取ります。これは基礎固めをしっかり行うためです。基礎がしっかりしていると、建築物も完成するのが早いし長く住めますよね。8週間 x 5人でできる範囲を設計・実装し、どのくらいの品質で達成できたかで一旦締めます。締めた後は振返りを行い、良い点・悪い点の意見を出しあって方向性を確認し、次のイテレーションとして4週間等と期間を定めて、必要な予算を計上します。イテレーション開発の最初の1期間は長いですが、課題の少ない確固たる基盤が出来上がることで、各イテレーションは短くなっていきます。
たとえ最初の1回で失敗したとしても、8週間 x 5人分であれば傷は大きくないはずです。修正も容易に効きます。最初の1回で成功した場合、その次のイテレーションを回せば全体でどのくらいの予算が必要で、どれだけの開発生産性になるか、見通しがつくはずです。最初から全体を一気に予算化しようとするか難しいのであって、全体像を描いたうち、イテレーション開発として最初の1回を試行すればよいのです。 2,000人月を使い切って初めて品質を満たしていない事に気づいて炎上するより、遥かに良いはずです。
リスクを下げ、品質を上げてコストを下げる。みなさんこれを目指しているはずです。それは、単にフレームワークだけ変えれば達成できるというものではありません。アーキテクチャ、開発手法、テストの方法、品質の確認方法等、全てをもう一度見直してみる必要があると思いませんか？
相談先
レッドハット社では、ITのプロフェッショナルという視点でコンサルティングサービスを行っています。業務課題から要素技術のマッピング、それをカバーするレッドハットの製品の選定、さらにはその仮設に対する検証としてのサンプルアプリケーションの実装、パフォーマンスのチューニング等まで行っています。IT部門の文化を変えるお手伝いを行っている、と言っても過言ではありません。Red Hat Enterprise Linux というOS部分からJava上のアプリケーション層まで、DatabaseとUser Interface以外の広い範囲をカバーしています。どのIT企業よりも尖りまくった人材を抱えているレッドハットに、是非ご相談ください。
