私たちは主として業務アプリケーション開発という「プロジェクト」に関わる仕事をしています。ところで、このプロジェクトという言葉が持つイメージと、実際の開発現場との乖離に悩まされることも少なくありません。ここで、私の考え方を整理しておこうと思います。
「プロジェクト」とは、やったことがない、新しい業務のこと
やり方がすでにわかっていて、マニュアル化されていればプロジェクトとは呼びません。
なぜ、そういう自明のことをあえて持ち出したかといえば、新しい業務は誰も経験したことがない分、「リスク」を伴うからです。
このリスクを誰が負担するかといえば、それはプロジェクトの成功によって恩恵を受ける側です。業務アプリケーション開発分野でいえば、それは発注者であるユーザー企業です。
しかし実際には、このリスクをゼロにしようという力学が働いています。それが「一括請負契約」であり、その実体は「丸投げ」です。
この瞬間、プロジェクトのゴールが変質します。本来、プロジェクトの成功とは経営者的な視点では「これまでできなかったことができるようになり、その結果、売上が上がる（またはコストが下がって利益が増える）」こと、です。しかしリスク回避策をとったことで、プロジェクトは「追加コストを発生させることなく、要求として上がったことを実装する」ことが重視されるようになります。自ずと請負側との対立関係が生じ、共通のゴールに向かっていくというチームにならないことは、関係者の多くが知っていることです。
つまり、元々リスクを内包する「プロジェクト」の、リスクをゼロ化しようとすることで、どこかに歪みが生じているということです。
プロジェクトマネジメントとは何か
プロジェクトマネジメントとは、リスクの早期発見と、早期対処を行うことが目的である、と理解しています。
そのためにマネージャは有限である資源（ヒト、モノ、カネ）を割り当てる権限を持っていることになっています。あえて踏み込んだ表現をすれば、再割り当てによって「（やむなく）今回、見送られるテーマ」もあれば、「予算を追加投入してでも、この機能を完成させる」こともあるでしょう。再割り当てとは必ずしも当初の要求を全て満たすことと同義ではありません。
しかし実際にはどうでしょう。資源割り当ての権限は与えられず、リスクが顕在化したときに場当たり的対応をしている事例がどうしても目についてしまいます。
プロジェクトの失敗とは、予算や工期をオーバーすることではなく、プロジェクト達成後の効果を得られるかどうかです。さらに優れた経営者であれば、プロジェクトの効果とは直近の売上増や利益増のことだけではなく、この経験を通して、より大きなプロジェクトに挑戦できる気概をもった「人材」の育成まで視野に入れます。それは社内の人材だけではなく、今後、別のプロジェクトで協力してもらえる外部の専門家との信頼関係の醸成までも含みます。経営者とプロジェクトマネージャの双方が、このような視点を共有して取り組むことができれば、組織を超え、社会そのものを良くするような貢献へとつながることでしょう。
私は予算、納期、品質はいずれも大切であると知っています。しかし「どれも大切なので、すべて満たすように。」というのは指示ではない、と考えています。現実には何もかも足りないのです。その中で何を優先し、何を捨てるのか。そのぎりぎりの判断を決めるときの拠り所となるのは、プロジェクトのゴールはそもそも何か、ということです。それが曖昧な状態で、あれもこれもと欲張ったとき、そのしわ寄せは人材の疲弊に行き着きます。結果として予算、納期、品質を守った（ことになった）が、人材は育たなかったというのでは、そのプロジェクトは本質的には「失敗」ではないか、というのが私の見解です。
プロジェクトを支えるのは、経営者の覚悟である
それほど大変なプロジェクトであるからこそ、最後は経営者がこれを支える覚悟が必要です。「私はITに疎いから、担当者に任せた。現場の意見をすべて取り入れた使いやすいシステムで、かつ他社に差をつけるようなアイデアを盛り込んだものを、一括請負でもっとも安値で受注したところに作らせるように。」という指示には、何の覚悟も感じられません。また、この指示の下、大成功したプロジェクトというのも、少なくとも私は聞いたことがありません。
では、このブログのタイトルとして掲げた、IT業界の「（業務アプリケーション開発）プロジェクト」の、誤解ではない在り方とは何か。さまざまな意見があるでしょうが、私にとってのそれは「発注側による丸投げをやめ、内製化への取り組みを始める」ことです。
困難なプロジェクトには、相応のリスクも、果実もあります。リスクをゼロ化し、果実だけを得るという姿勢では、結局、本当の果実を得ることができない。なぜならリスクに対して真剣に取り組むという経験をした人材こそが、プロジェクトの最大の成果であり、財産なのだから、というのが私の結論です。プロジェクトマネージャがリスクを極小化しようとすることは当然ですが、プロジェクトのゴールは「当初の予算内・納期内での達成」という視点よりも上に位置するものです。それを示し、プロジェクトメンバーの判断の拠り所をつくるのは、経営者の仕事です。
プロジェクトは、人を育てる場でもあります。内製化によってどういう人材を育成するかといえば、それはもちろん「その業務のプロフェッショナル」であり、プログラマーではありません。ユーザー企業の内製化とは、自社に大量のプログラマを抱えることではない。この発想と、それを実現する手法が一般化したとき、丸投げという悪弊がなくなり、IT業界のプロジェクトという言葉に再び、輝きを与えることになる。私は今年、多くの同業他社の方々と意見交換する機会がありましたが、当社を含む、自動生成というキーワードに文字通り人生を賭ける人達が思い描いているのは、こういう世界なのだろうと感じています。
