サボりのモジュール化・サボる部分の独立化：山浦恒央の“くみこみ”な話（10）

トリアージュ方式でデスマーチ・プロジェクトを乗り切る方法について解説。「遅れる前から、遅延回復の準備をしておく」という考え方とは？

[山浦恒央 東海大学 大学院 組込み技術研究科 准教授（工学博士），＠IT MONOist]

　まるで戦場のように、エンジニア全員が命と睡眠時間を懸けてコーディングやデバッグをひたすら行う「大混乱のソフトウェア開発プロジェクト」。このデスマーチ・プロジェクトの救済策として、非常に有望なのが「トリアージュ（野戦病院方式）」です。

　最前線にある野戦病院では、医師や看護師、薬、ベッドの数が限られていますし、これらの補充はまったくといってよいほど期待できません。なのに、次から次へと負傷した兵士が運び込まれてきます。そう、限られたリソースで傷病兵を治療しなければならない野戦病院は、大混乱しているソフトウェア開発プロジェクトとまったく同じ状況といえます……。

　というわけで、今回から数回に分けて“トリアージュ方式で混乱プロジェクトを乗り切る方法”を解説していきたいと思います。

トリアージュ方式の基本

　以前のコラムで、遅れているプロジェクトの遅延回復対策として、優れているものから順番に、

1. スケジュールの延長
2. トリアージュ（野戦病院方式）
3. 人員投入
4. ダイハード方式

の4つがあると述べ、これまで“人員投入”の詳細について解説してきました。

　人員投入に比べてトリアージュ方式が圧倒的に優れているのは、外部から人を追加しないので、助っ人の技術教育に時間を取られることがなく、“プロジェクト全体の生産性が落ちない”点にあります。

　野戦病院では、医師や看護師、薬、ベッドの数が限られているので、運び込まれた傷病兵の症状により対応が変わります。すぐに手当てをしないと生死にかかわる重症患者を最優先に治療し、かすり傷程度の軽傷者は優先度が低く、後回し（あるいは、タライ回し？）にするなど対応が異なります。この野戦病院にこそ、デスマーチ・プロジェクトを乗り切るヒントがあるのです。

　では、ソフトウェア開発プロジェクトでトリアージュ方式を導入するための手順を見ていきましょう。

• ステップ1：開発するプログラムの機能を「必須」「重要」「希望」のように優先度で分類する。
• ステップ2：同様に、各機能の品質レベルを「高」「中」「普通」に分類する。
• ステップ3：プロジェクトの進ちょく、品質の現状を常に把握する。
• ステップ4：遅延している場合、遅れを回復するために、機能と品質の優先度に従い、プロジェクトのリソースをどこに割り当てるかを判断する（ステップ3へ戻る）。

　以降で、各ステップの概要と詳細を紹介します。

ステップ1：機能を「必須」「重要」「希望」のように優先度で分類

　トリアージュ方式で最も重要なことは、「遅れる前から、遅延回復の準備をしておく」という、“リスク管理”をベースにした考え方です。誰もが納得する「言い訳」をきちんと用意してから、“堂々とサボる”のが「正しい怠け方」なのです。遅れが顕著になってから、「泥縄式」に慌てて対策しようとしても遅過ぎます。

　例えば、ソフトウェア開発の経験則に「80％・20％ルール」があります。80％の機能は、20％のモジュールで実現している。すなわち、20％のソースコードを書けば、機能の8割を作り込むことができるというものです。

　80％・20％ルールは、プロジェクトの管理者にとって非常に魅力的な法則といえます。ただし、遅れが顕著になった時点で80％・20％ルールを適用し、開発量を減らして遅延を回復しようとしても、絶対にうまくいきません。通常、1つのモジュールには80％と20％が混然一体となって同居しているため、切り分けがものすごく大変です。最初から80％・20％ルールを意識して設計してあれば問題ありませんが、そうでない場合、後から切り分けるのは至難の業といえます。

　例えるなら、タマネギの嫌いな小学生が、ハンバーグの中のみじん切りになったタマネギを1つ1つ箸（はし）でつまみ出すようなものです。ハンバーグのひき肉とタマネギを最初から分けて調理し、最後に交ぜるようにしておけば、80％と20％を簡単に分類できます。80％と20％が交じったソースコードを無理やり切り分けようとすると時間がかかりますし、モジュール構造が変わってしまい余計な混乱が発生し、バグの原因にもなります。

　開発量を減らす、あるいは、開発をサボる場合、遅れが致命的になった時点でアタフタするのでは遅いのです。機能仕様書を書いている段階で、遅延に備えた考慮をしておく必要があります。ましてや、本来必要となる開発時間の半分しか割り当てられていないデスマーチ・プロジェクトともなると、必ず遅れが発生しますので、遅延対策はプロジェクト立ち上げ当初から行わなければなりません。

　機能仕様書を作成する段階でやるべきことは、機能を定義しつつ優先度を付けることです。これを行えば、後の設計フェイズやコーディングフェイズにおいて、実現する機能を1つの塊としてとらえることができ、後から簡単に機能を減らすことができます。ある意味、「サボりのモジュール化」「サボる部分の独立化」をするということです。

　ただし、開発する機能に優先順位を付ける場合、以下の3点に注意する必要があります。

• 優先度を細分化し過ぎない
• 顧客の了解を取る
• 必須をなるべく少なくする

優先度を細分化し過ぎない

　実現機能の優先度を1〜10段階に分けるのでは細か過ぎます。優先度4と優先度5の違いが不明確ですし（というより、どうでもいい？）、4にするか5にするかで悩み、余計な時間を使ってしまいます。ここでは「必須」「必要」「希望」の3つに分類するか、「必須」と「希望」の2つに分けるのがシンプルで実践的な手段です。

顧客の了解を取る

　機能を「必須」「必要」「希望」の3つに分類する場合、開発側と発注側の思惑が異なる場合が少なくありません。プログラマが「この機能はデータをカッコよく表示するだけなので、これがなくても印刷処理全体に大きな影響はないはず。だから、『希望』に分類するのが妥当だろう」と思っても、実は顧客にとっては（あるいは、最終ユーザーには）、非常に重要な機能だったりもします。

　優先順位は、顧客と擦り合わせる必要がありますが、そのとき、顧客から「えっ、この機能を全部作ってくれるんじゃないんですか？ それなら、なぜ、3段階に分けるんですか？」と聞かれたりします。この疑問（というか、顧客の不安）をうまく乗り切らねばなりません。ここがプロジェクト・マネージャの腕の見せどころです。リスク管理の観点で、優先順位を付けていることをきちんと説明し、開発をしているときに、突発的な事件や事故が起きても、納期に間に合わせるための重要な措置であることを顧客に納得してもらう必要があります。なお、ここでの注意点は、優先度の擦り合わせに時間を取り過ぎないことです。

「必須」をなるべく少なくする

　「必須」機能をなるべく少なくすることは、非常に重要です。「必須」が90％もあるのでは、トリアージュの意味がありません。理想は30％以下、最悪でも50％以下にすべきです（「必要」は30％以上、「希望」は20％以上）。

　味噌と豚肉があれば、最低限、豚汁はできます。豚肉がないとただの味噌汁なので、豚肉は「必須機能」です。余裕があればゴボウや大根やイモを入れて豪華に仕上げ（これが「必要機能」）、さらに時間とお金があれば立派な器に盛り付けて立派な箸を添えると（これが「希望機能」）、フル・スペックの豚汁になります。

　デスマーチ・プロジェクトの定義は、『開発に必要な時間の半分しか割り当ててもらえないプロジェクト』ですので、「必須機能」を全体の50％以下にできると、「必須」だけを開発すれば通常のプロジェクトになります。この意味から、「必須機能」を50％以下に絞り込むことは非常に重要なことといえます。

　さて、次回は「ステップ2：各機能の品質レベルを『高』『中』『普通』に分類する」について解説します。お楽しみに！（次回に続く）

【 筆者紹介 】

山浦 恒央（やまうら つねお）
東海大学 大学院 組込み技術研究科 助教授（工学博士）

1977年、日立ソフトウェアエンジニアリングに入社、2006年より、東海大学情報理工学部ソフトウェア開発工学科助教授、2007年より、同大学大学院組込み技術研究科助教授、現在に至る。

主な著書・訳書は、「Advances in Computers」 （Academic Press社、共著）、「ピープルウエア 第2版」「ソフトウェアテスト技法」「実践的プログラムテスト入門」「デスマーチ 第2版」「ソフトウエア開発プロフェッショナル」（以上、日経BP社、共訳）、「ソフトウエア開発 55の真実と10のウソ」「初めて学ぶソフトウエアメトリクス」（以上、日経BP社、翻訳）。