方法論やシステムに込められた「魂」が失われる

IT業界で，特定の分野に秀でた方々は，しばしば「魂を入れる」とか「魂を込める」という表現を使う。なにかしら深い洞察により得た工夫を，開発方法論や業務モデル，情報システムなどに織り込み，それらの利用者にきちんと作用することを指して「魂を入れる」と表現している。
　このような話をしてくれる方々への取材は，いつも楽しい。どんな状況でどんな失敗を経験し，何を学んだのか。それを改善するために，どんな工夫を凝らして開発方法論やシステム設計に「魂」を込めたのか。現場から生まれた数々の知見を，実に生き生きと，熱っぽく語ってくれるからだ。
　しかし，せっかく込めた「魂」が失われてしまうことがあるという。ここでは開発方法論に込められた魂＝工夫が失われた例を紹介したい。
　ある大手ITベンダーの品質管理担当者が，こぼしていた。「過去に繰り返された多くの失敗を糧にして，いろいろな工夫を凝らし，開発方法論を改善してきた。それなのに現場では，肝となるアクティビティを省いてしまうケースが少なくない」というのだ。現場が忙しくてつい省いてしまったという場合もあるが，特に問題視していたのは，プロジェクトが始まった時点でも「魂」の一部が失われる可能性である。
　開発方法論（開発プロセスや管理プロセス，各種標準などの総称）は一般に，どんなタイプのプロジェクトでも応用が利くように，かなり幅広いタスクやアクティビティを網羅している。開発の現場ですべてのタスクやアクティビティ，ドキュメントの作成を実施する必要はないため，プロジェクト・マネジャが必要なものだけを抜き出し，開発方法論をカスタマイズする必要がある。まずこの過程で問題が発生しやすいという。
　「プロジェクト・マネジャの中には，開発方法論を『手順書』か『ドキュメント・テンプレート集』くらいにしか思っていない人がいる。プロジェクト・マネジャとしての経験が足りないからなのだろうが，方法論のどこが肝なのか，なぜそういうアクティビティが必要なのかを分かっていない。だから，自分のプロジェクトで省いてもいいアクティビティ／ドキュメントと，そうでないアクティビティ／ドキュメントの区別がついていない」と前述の品質管理担当者が話す。
　省かれやすいものは，例えば「キックオフ・ミーティングでユーザー企業とゴールを共有する」というようなコミュニケーション／プロジェクト運営に関することをはじめ，リスク・マネジメント，レビュー・プロセスなど，「もの作り」に直結していない作業全般に及ぶ。
　あるいは，成功した類似プロジェクトの開発方法論を，ほとんどそのまま自プロジェクトに適用することもあるだろう。当然ながら，それが自プロジェクトで常にフィットするとは限らない。自プロジェクトに必要でありながら，既に省かれているアクティビティやドキュメントがあるかもしれない。
　運がよければ，省かれた部分をプロジェクト・マネジャの力量でカバーできるかもしれない。だが，それは個人の力量に依存した前近代的な開発スタイルである。過去の経験から得たノウハウやベストプラクティスをうまく再利用できていないという点で，方法論に込められた魂の一部は失われていると言えるだろう。PMO（プロジェクト・マネジメント・オフィス）を持つ組織の中には，こうした問題へのフォローを始めているところもあるという。
　「開発方法論は，型にはまっていて役に立たない」と感じているプロジェクト・マネジャもいらっしゃるだろう。もしかしたら，その方法論が本当に役立たずなのかもしれない。あるいは，そうではなく，方法論に関する教育が手薄だったために利点を知らずにいるだけなのかもしれない。いずれにしても，方法論などを「試して，改善していく」というサイクルが失われていることを，魂を込めてきた方々は心配している。