空き稼動は悪

実情として，受託開発ビジネスは「人月商売」であり，「空き稼動は悪」です。プロジェクトにアサインしたメンバーには，なんらかの付加価値を生み出してもらわなくてはいけません。これはプロパー（自社の社員）であっても，パートナー（協力会社の社員）であっても同じことです。

つまり，「遊んでるくらいならコード書け」というプレッシャーが，特にリーダーやマネージャにはつきまとうのです。

もちろん私にも経験があります。パートナーさんと契約をしたのに何もしてもらうことがないという状況は，お金を垂れ流していることに等しく，結果的に「先行着手」という消極的な行動を選択してしまうのです。

先行着手とプロトタイピングは違う

要件がはっきり決まっていなくても手をつけやすそうな部分，つまり，

• 仕様が理解しやすい
• 以前似たような業務を経験している
• 技術リスクが低い

といった機能が選ばれて先行着手されることになります。これはプロトタイピングに似ているようですが，このような先行着手は断じてプロトタイピングではありません。

プロトタイピングは，

• 仕様が理解しにくい
• 初めて経験する業務である
• 技術リスクが高い

といった機能に対して積極的に行われるべきものです。プロトタイピングではほとんどの場合，無駄になる（＝リリースされない）ことはありません。また，万が一リリースされなくても気にすることはありません。プロトタイピングの目的は「本質的なリスクの軽減」であり，それが達成できれば書いたコードが捨てられようがかまわないからです。

一方，消極的な先行着手は，空き稼動を避けたいという「非本質的なリスクの軽減」のための行動です。稼動で重要なのは質であって，時間ではありません。時間つぶしのための稼動こそ無駄なのです。

本質的な問題にチャレンジせよ

要件が固まっていない時期や契約の都合で動きが取りにくいときこそ，つまり稼動できず一見無駄が発生しそうなときこそ，プロジェクトの本質的な問題に，メンバー一丸で取り組むべきです。

マスタメンテナンスなどいつでも作れます。いつでも作れるものを先行着手してはいけません。最も難しい問題にチャレンジすれば，その結果は無駄にはなりません。

たとえば，お客さまが一番期待しており，かつ一番難しい要件を分析し，動くものを作ってしまうのも手です。また，開発が本格化したときに備え，テスト計画の具体化・詳細化，テストに必要な工数の実測を行い，品質基準を作り上げてしまってもよいでしょう。

リプレースは簡単ではない

もう一つ，受託開発にありがちなのが「リプレース案件における作りすぎの無駄」です。

受託開発では完全な新規開発はむしろまれで，すでにあるシステムの置き換えが多くなります。ダウンサイジングやオープン化といった懐かしいキーワードを思い出してください。これらは基本的にはリプレースなのですが，単に機能を新しいOSやプログラミング言語に置き換えるわけではありません。

しかし現実にありがちなシナリオとして，お客さまから「今とまったく同じものを作ってくれ」とお願いされることがあります。つまり，「今とまったく同じであること」が要求なのです。

「まったく同じ」はない

伝統を長く守り続けている職人は，ずっと「まったく同じであること」を実現するために，むしろ小さな変化を取り込み続けています。

たとえば蕎麦。同じ「かえし」（蕎麦つゆに使われる調味料。店ごとに特色がある秘伝）を実現するにも，醤油や酒，水の質は時代によって変わります。50年前とまったく同じ質の醤油が今も仕入れられるとは限りません。

システムの仕様も同じことだと思います。現システムとまったく同じ見栄えや機能を実現しても，お客さまが同じように満足を感じるかどうかはわかりません。むしろ，今の時代に合わせた価値を求められているのです。

ここの感覚がお客さまと合わないと，「まったく同じように作ったのに」お客さまの満足は得られず，下手をすると使われない，無駄な機能になってしまいます。

新規のつもりで検討する

「全部同じ」リプレースであっても，新規開発のつもりで要件を再検討しないと無駄が発生します。

私は以前，「稼動して1年たって，一度も印刷されていない帳票」を作ってしまったことがあります。業務の本流から少し外れた機能であったため，「とりあえず現システムと同じでいきます」と提案してしまったのです。

むしろ，このようなあまり重要でないと思われる機能こそ，業務全体の流れからその必要性を検討すべきでした。お客さまは機能を減らさないことに関しては寛容なものです。それに甘え，リスクも低そうだしとりあえず作ろう，といった考えが無駄を生みました。

かかった工数を別の機能，たとえばデータメンテナンスツールなど保守性を向上するための機能にまわせば，システムにかかるコストはもっと下げられたはずです。