カスタマーコンサルティングチームの矢戸 政法です。
先日、大きなプロジェクトが一段落しました。プロジェクトの楽しいところのひとつに「最後のお祭り騒ぎ」があります。計画段階からコツコツと進めて、いろいろな壁に阻まれながらも前へ前へと推し進め、最後のリリース段階はアドレナリンとかドーパミンが出まくってとても楽しい気分になれたりします。終わってみれば楽しい経験になるのですが、途中段階で現れる「壁」にはいつも悩まされます。今回はそんな壁、特に「スケジュールが間に合わない！」といった問題を乗り越える方法について考察してみたいと思います。プロジェクトの初期段階で下記のように考えていたとします。
しかし、設計を進める段階で要件定義時に定義していた業務要件に変更が入ってしまったと仮定します。通常このような場合はQCDの観点から調整を試みます。つまり、クオリティを落とせる部分があるのか、デリバリー（リリース）タイミングを遅らせることは出来るのか、コストを追加することで人的リソースを増やし対応することが出来るのかという、それぞれの観点で最も実現可能なポイントを探るのです。
QCDのどれかで調整ができれば問題は比較的簡単に解決できるのですが、場合によっては、リリースは遅らせられない、クオリティも落とせない、人的リソースを増やしたところで開発スピードは上がらないという八方塞がり（三方塞がり？）の状態になることも良くあります。しかしこのスケジュール、計画を立てたのは要件定義が始まる前段階で決めた状態のままだったり、要件定義直後にかんたんに見直した程度だったりすることが良くあります。設計が進んだ状態になっていると開発する機能についての理解が進み、「解像度」が上がっている状態になっていることと考えられます。
この解像度が上がった状態で開発のプロセスを再検討すると効率的に開発／製造のプロセスをすすめることでスケジュールを調整できる可能性が出てきます。具体的に考えてみましょう。要件定義が終わった段階では開発／製造すべきシステムが各機能単位で整理されてきているはずです。この各機能を、新規で開発しなければならない機能（グループA）、既存システムの機能を流用できる機能（グループB）、リリース段階では必ずしも必要としない機能（グループC）と分けることが出来るとします。そうすると、「開発／製造」の矢羽も３つに分解することができます。
さらに、グループBの機能は既存の機能からの流用であり、開発およびテストの工程も削減できることが確認できればグループBに関するテストの期間を短縮することができます。テストの期間を短縮できるのであれば、システムテスト（ST）をST1とST2に分けてスケジュールを検討することも可能になります。
またグループCについてはリリース時点で機能としては実装するものの、不具合があってもリリース後の修正で対応が可能であることが確認できれば、更にスケジュールを変更することができます。
このようにすることで追加になった要件をリソースが厚くなったグループAの機能として開発し、リリースに間に合うように調整することが可能になります。一見このやり方はクオリティを下げているようにも考えられますが、必要な機能に必要なクオリティを合わせるという最適化であるという考え方もできます。クオリティを最適化することで開発やテストの期間も最適化出来るようになるのです。
最適化するためには開発やテストについての解像度が上がっている、つまり機能の詳細を検討できる状態になっている必要があるため、プロジェクト開始の時点で最適化するのは難しく、ある程度進行したタイミングで最適化するのが正しいアプローチだと考えます。
デザイン思考的なアプローチは「観察」から始まりますが、スケジュールの設計においても状態を観察することは非常に有用だと思います。状態を観察することで分解できるポイントを見極めることが出来るようになり、スケジュールの組み換えや「やりくり」が可能になるからです。スケジュールに行き詰まった際には問題点や状態をよく観察して工夫の余地を見つけることが解決への糸口になると考えます。
