DX(デジタルトランスフォーメーション)推進コンサルティング 株式会社アイ・ティ・イノベーション

ご訪問ありがとうございます！　　　　　　　　　　＜　前回　｜　目次　｜　次回　＞

前回はプロジェクトの継続的改善を図るためには、ありのままのプロジェクト実績データを収集する必要があることを考察しました。システム開発の生産性を向上させるためには、定量的な現状分析が必要なことは言うまでもありません。

しかし、人月清算が浸透しているシステム開発の現場においては、受注側が努力して生産性を高めれば高めるほどシステム開発に必要な工数（人月）は少なくなり、受注額が少なくなってしまうというパラドックスがあり、生産性向上の大きな阻害要因になっています。

【　特急は乗車時間が短いのに料金が高いのは常識　】

～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～
ＪＲの特急は乗車時間が普通電車より短いことで、追加料金を支払うのが常識ですよね。特急電車は長距離の移動に配慮して、座席のすわり心地が良くなっていたり、客室乗務員によるサービスがあったり、普通電車に対してサービス面でも差別化が図られています。忙しいビジネスマンの方は、どちらかというと時間をお金で買っているという感覚をお持ちの方が多いのではないでしょうか？

一方、システム開発の世界では、開発期間が短くなればそれだけ工数（人月）は少なくすむはずなので、その分値引きが要求されることはあっても、早く出来上がった分追加料金をもらうなんてことは、あまり聞いたことがありません。。。

【　受注側としての生産性向上の必要性　】

～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～
とはいえ、開発規模や受注額について発注側と合意して一括請負契約を結んだあとは、受注側としては開発生産性が高ければ高いほど、開発原価が小さくなる分利益率が大きくなることになります。というか、システム開発を行う上でさまざまな問題・課題が発生してトータル生産性が下がれば、開発原価が大きくなる分利益率も下がり、最悪の場合は損益分岐点を超えて赤字プロジェクトとなってしまいます。（※１）

まあ、あたりまえのことですけどね。システム開発ベンダーとしては、受注額を合意したときに想定した利益が少なくならないように、トータル生産性が下がらないようにシステム開発のプロジェクトをマネジメントしていく必要があります。たぶん開発現場としては「なんとか利益が無くならないように」ぐらいの目標感だと思いますが、経営層は「もっと野心的に生産性を上げて利益率を高める」ことを現場に求めてきます。

そういえば、一般的なプロジェクトの成功判断基準（サクセス・クライテリア）のひとつであるコストの評価基準は、次のうちいったいどれなのでしょうか？（※２）

１．受注額合意時に想定した利益があがる開発原価（計画時の目標原価）

２．利益がマイナス（損失が出る）とならない開発原価（損益分岐点）

３．多少の損失が出ても、受注側の組織として許容範囲の開発原価

普通に考えて「成功は目標の達成」なので、サクセス・クライテリアとしては上記の1番目（計画時の目標原価）が妥当と思われるかもしれません。しかし、私のこれまでの経験から推察する限り、２番目（損益分岐点）を成功の判断基準としているケースが多いように感じます。つまり、「計画時の目標原価は達成できなかったものの、赤字にはなってないので失敗とは言い切れない」という程度のゆるい感じではないでしょうか？（※３）

【　生産性向上のポイント　】

～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～
ここで、私のシステム開発経験上の生産性向上ポイントをいくつかご紹介します。いろいろポイントがあると思いますが、私としては、【第７回】フルトヴェングラーのプロジェクトマネジメント　でご紹介した「フルトヴェングラーの震える指揮棒の定理」や　【第１０回】落合「オレ流野球」はＣＭＭＩレベル５か？　でご紹介した落合博満氏「オレ流野球」の「自発性」がキーになると考えています。

＜生産性を向上させるポイント＞

１．原価意識、生産性意識の徹底
どんなことでも「どうしたら早くできるか」を常に意識する習慣をプロジェクト参画者全員に徹底する。仕事を早く終わらせることで、自分だけではなく、周りの人、会社全体やお客様含め、関係するステークフォルダ全員にメリットが出ることを意識。システム開発の仕事の本質は生産性向上にあると認識する。

２．標準化、機械化、再利用
プログラム、ドキュメント、仕事の仕方・・・あらゆることを標準化することで、機械化（自動化）や再利用の可能性が広がることを常に意識する。もっとも生産性があがるのは、新たに作らずに既にできているものを使うこと。標準化、機械化、再利用が進めば、品質も高まり、不具合対応等の手戻りも減らすことができるはず。

３．ボトルネックの検知と排除
システム開発（他の仕事も同じ）の中で、どこに一番時間がかかっているかを常に考える。時間がかかっている作業があったら、まず、その作業はそれだけ時間をかける価値があるかどうか疑問に思う。そして、その作業をやらないで済ませることができないか、代わりのやり方は出来ないか、から出発して、ボトルネックを排除する。これを繰り返し行うことで、継続的改善につながるはず。

４．80対20の法則の活用
【第３８回】80対20の法則でプロジェクトを変える！　でご紹介した「80対20の法則」を活用できる場面は無いかを常に意識する。活用方法は仕事の内容や作業者の性格などによってさまざま。「とにかくがんばる」を卒業し、「効率的にがんばる」方法を模索する。

５．初期品質を高める
上流工程での十分な検討、再利用時の流用元をきっちり作る、単体テストでの十分なバグつぶし・・・初期品質を意識して高める。初期品質が悪いと、不具合が増幅されたり、修正に修正が重なる可能性が高くなり、効率の悪さが増幅されていくことを考える。力のいれどころ、時間のかけどころを意識する。

６．打合せ、レビュー会等の効率化
打合せ、レビューは複数人が参加するため、参加している人数分の時間（工数）がかかっている。会議の無駄は、出席している人数分増幅されている。「時間がかかってもやるしかない」という短絡的な考えは極力捨てて、５分でも１０分でも短縮する工夫を心がける。打合せのゴール設定、アジェンダ設定、会議参加者の絞り込み・・・小さな工夫、小さなロスのどちらも増幅されることをよく考える。

７．プロジェクト・リスクに対する備え
前回　【第４５回】ありのままのプロジェクト実績データ収集　で示したように、失敗による手戻りも含めた生産性実績データを収集する。これを分析することで、どの失敗がどれだけのロスを生じたかを定量的に把握することができれば、次のプロジェクトにおいてどのリスクに対して重点的に予防策を打てばよいかが浮き彫りになるはず。メリハリをつけたリスク予防策がしっかりできていれば、失敗による手戻りを減らすことができるので、トータル生産性の向上に大きな効果が得られるはず。

８．上記ポイントを計画、スケジュールに組み込む
生産性向上を「意識する」から「実践する」に高めるための具体的なアクションをドキュメント化する。プロジェクトの全体計画（マスタースケジュール）、各工程単位のＷＢＳ、各個人の予定管理・・・あらゆる階層の計画類を策定する際に、上記のポイントを盛り込むことを習慣づける。
そして　【第３１回】禁断の裏マスタースケジュール　で示したように、リスクを考慮して「先憂後楽」、後半にスケジュールバッファを持たせることを忘れずに！

さあ、これらの生産性向上ポイントを意識してシステム開発（他の仕事も同じ）を行うことにより、自分が工夫したことがプロジェクト実績データの中に成果となって目に見えてくることで、きっと仕事が楽しくなってくるはずです！そういった工夫が「楽しい」と思えるようになればしめたもの。あとは次の楽しみのために、日々工夫を重ねるという好循環に入ることができ、デスマーチなどの暗い世界からきっと抜け出せることでしょう！

「生産性向上意識が高まり、成果が見えはじめると、システム開発が楽しくなるぞ！」

それでは次回もお楽しみに！　　　　　　　　　　＜　前回　｜　目次　｜　次回　＞

工藤武久

～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～
応援してくださる方は、クリックよろしくお願いします！
◆　人気ブログランキング
◆　にほんブログ村
～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～

※１　トータル生産性については、【第４４回】パイロット開発の落とし穴～瞬間風速とトータル生産性　参照。

※２　プロジェクト・サクセス・クライテリアについては、【第３５回】プロジェクト・サクセス・クライテリア（成功判断基準）　参照。

※３　ここでは主にシステム開発受注側の「損益分岐点（利益がゼロ）」のことを指していて、発注側の「損益分岐点（システム化の費用対効果が均衡）」とは、ニュアンスが異なります。このニュアンスの違いは、発注側と受注側のサクセス・クライテリアは異なっているということを示しています。
【第４２回】プロジェクト制約条件の起源～数字はひとり歩きする！　では、＜コスト制約のもととなる条件の例＞のひとつとして「新システムのリリースで予測される効果金額（費用対効果の損益分岐点）」をあげました。