話題を少し変え、最近気になっていることに少し触れておきたい。 ここのところ「ＩＴ業界の３Ｋ」が話題になっている。一般に「３Ｋ」とは「きつい」「汚い」「危険」の意味と言われているが、ITの３Kは（諸説あるのだが）「きつい」、「厳しい」、「帰れない」、というのが代表的な解釈のようで、その他にも「気が休まらない」、「給料が安い」、「キリがない」、「結婚できない」などひどいたとえが無限にある。

ＯｐＳ開発に限らずソフトウェア開発ＰＪは他の業種に比べて極めて特殊な性質を持っている。特に企業向けのソフトウェア開発では、まだ誰もわかっていない顧客企業のあるべき業務やサービスの姿を形式知であるドキュメントに変換していくという本質的な困難さがあり、発注者と開発者の間で可視性のある統一的な共通認識を作ることは非常に難しい。工程毎の生産物も人間が書く文章やコードが中心であり、製品の出来上がりが可視的な構造物としては見えない。作文能力の限界によって誰が読んでも１００％完璧に同じ理解になるというドキュメントは作成できない。発注者から見れば「あなた方は専門家なのだから経験で見積もれるはずだろう」という理屈になるが、現実はそうはいかず、発注者の期待と予算に対して受注開発するベンダーの想定見積もりが乖離することが多い。受注する側の営業部隊は受注実績を上げるために不明確な状態でも契約しようとし、不確実な状態を内包したままＰＪがスタートする。このようにソフトウェア開発ＰＪはその当初から「何をするのかが決まる前に価格を決めて契約する」という不思議な状態になっており、ここで既に「３Ｋ」の種が埋め込まれているのである。

プロジェクトマネージャーは最初の見積もり時の開発量を基準に開発体制を組み立てるが、工程が進むに従って様々な要望が具体化して仕様が膨らんできても対応には限界がある。中核となるＳＥは要件定義から外部設計、内部設計と進む過程で顧客の業務要件に関する理解を徐々に蓄積していくため、途中から新しいＳＥを入れても業務とシステム全体を把握するのは容易ではないから、即戦力のＳＥをすぐに集めることは難しいことが多い。顧客との交渉に失敗して予算の増額が認められず納期に変更も無いとなれば、ＰＭは予算内に収めるために可能な限り現時点の資源でやりくりしようとする。元々過少見積もりでＰＪ体制が足りないので、あらゆるところで結果的に手抜きをせざるを得ない状態になり、様々な問題が埋め込まれていく。外部設計から内部設計へ詳細化して行く過程の設計漏れ、異常系処理の抜け、性能方式の検討漏れなどである。現場はわかっていながら黙々と作業を続け、深刻な実態が上位マネジメントに報告されることなく、不作為な手抜きが継続される結果となる。

そして試験工程になってあらゆる問題が噴出する。このときはもう手遅れである。設計から携わってきたＳＥは限られており、余程の幸運（類似システムの経験者が空いているなど）が無い限り同様のレベルの業務スキルに達するには長い時間がかかり、追加投入した人数の割にはなかなか進捗が上がらない。元々のＰＪメンバーの負担ばかりが増加し、「３Ｋ」状態に突入していくのである。

我が業界がこのように喩えられるのは非常に残念なことで、開発現場にいる当事者として３Ｋの汚名を早く返上したいものだ。ソフトウェアの開発の特殊性を顧客と受注者が同レベルで理解した上で、設計工程を可能な限り丁寧に行って顧客の責任者との間で合意形成を行い、製造工程の手戻りを少なくすることが重要である。最近では大手ＳＩｅｒを中心に、発注者と受注者でシステム仕様の合意形成を容易にするためのガイドラインの研究も進んでおり、これらのツールと顧客との合意形成スキームの設定によって、顧客にとっても重大な経営責任となる失敗ＰＪを発生させないようにする、いわば甲乙同じ土俵に立つ文化作りが「３Ｋ」脱却の一つの道と思う。