ソリューションのヒント

■属人性ということ。 属人とは辞書では人を基準に考えることとあります。 ８０年代頃から，システム開発やプログラム開発に当たっては，「属人性の排除」という言葉が金科玉条のごとく叫ばれていました。 当時の論理は，次のようなものです。 「属人性のあるプログラムは，その人しか分からない。 プログラムというのは誰が見ても分かるようなものでなければならない。 そのうちには（つまり今現在頃），CASEツールなどによってプログラム自体をコーディングする必要が無くなるだろう。つまり，システム開発というのはいかに属人性を排除するかがポイントである。」 と言われていました。 属人性というのは本当に悪いことでしょうか。 結論を先に言えば，「やっぱり人です！」といいたいというのが，今回のテーマです。

■従来型のプロジェクト管理とプログラマの属人性 　 属人性の排除とは，この絵のように誰でも同じように プロジェクトのメンバーとして振る舞うことが要求される。 属人性の排除という前提で成り立っている従来型のプロジェクト管理技法では，プログラマを，単に仕様書をその言語に翻訳する「コーダー」だという考え方をする事が多いです。 一般的にビジネスシステムの開発においてはプログラマの地位はあまり高いものとはいえません。 　この考え方は，基本的に属人性がないからこそ分業体制で開発をすることが可能だという考え方で成り立っています。プロジェクトマネージャは，この規模のプログラムは何人月ということを積算し，プログラマを調達します。属人性排除の原則のもとではプログラマはリソースなのです。 こういったことでマネージメントするプロジェクトマネージャは腕が良いなどと言われていました。しかし，最近のシステム開発ではこれが様々な点で実体に見合わなくなっています。 仕様が堅く確定しているプロジェクトでは，これは全く正しいやりかたです。ちょっと経験のあるプロジェクトマネージャならこのやり方で，ほぼ先（結果）が読めます。 しかし，現実に大部分のビジネスシステム開発では，こういった方法を実践するうえで必須条件であった詳細な仕様書など存在しなくなったということ。さらに言えば，要件自体がかなり柔らかい，つまり仕様変更は日常茶飯事であるということです。 　プログラム開発を海外などの外注先に全面委託するいう方式は，「詳細な仕様書」がないと成り立ちません。詳細な仕様書なしで，外注先にまる投げすれば，「なにをつくるのか正解を渡さないで開発をしろ」と行っているようなものです。出口のない開発を行うことに他なりません。 この状態で，生産性や品質を云々すること自体ナンセンスです。実際にこういったケースはよく見られます。 ■プログラマは部品じゃない！という反論 しかし実体は・・・ 組織の都合にあわせられる人間は少ない。 実際に，メモリなどと同等のリソースなんて言われた，プログラマ本人にとっては，どうでしょう？仕事の喜びとかやる気がでるでしょうか。 昔から腕の良いプログラマはゲーム業界に行き，ビジネスの開発は「でも・しか」プログラマしかいないと言われていました。これは，とりもなおさず，従来型システム開発におけるプログラマの地位を物語っています。 一方，９０年代に流行った，スパイラルアプローチという技法では，プログラマがスワットチームとして，現場の人間と直接やりとりをしてその場で問題を解決しました。こういった状況でのプログラマは，その場で問題を解決していきますから，従来型の開発に比べて生産性は１０倍も違うということが事実としてあります。私どもで経験したプロジェクトでも，リリース後に問題が発生し，増員もふくめ数十人のプログラマが対応しても，解決しなかったところに，こういった問題解決型のプログラマを数人投入したら，１週間ほどで収束したという事実があります。 ダイレクトに問題解決するプログラマは，仕様書の翻訳でなく，ソリューションを行っています。いっぽう従来型の「属人性を否定している方式」では，変更仕様書を渡して「ここをこう直す」何時まで！という感じで翻訳作業を行っているだけですから，徹夜が続くとおのずと極端に生産性や品質が落ちます。 　逆に問題解決型のやりかたでは，目に見えて現場の人間の信頼を得ますからプログラマ本人のやる気も出てきて，うまくいけば本当に短期間で問題解決ができます。今はやりのＸＰ（エクストリームプログラミング）などというのは，このあたりのメリットを全面に打ち出しているわけです ■やはりプロマネが重要！ プログラマのやる気を引き出し かつ全体の方向性をコントロールするのが あたらしいプロマネの姿勢です。 ただしこれは，管理面からは両刃の剣です。つまりうまくいけば生産性はあがるが，下手をすると組織として管理不在のプロジェクトにになるということです。 　ＣＭＭなどの段階論でいえば，「そういうスーパーマンがいたために，たまたまうまくいった状況で，常にそういったパワーが出るような組織としての力になっていない」ということになりがちです。 でも本当にそうでしょうか。 つまり，直接現場で問題解決するプログラマは，基本的に職人気質に近くなるので，マネージャが言っていることよりも現場の人間の言葉を優先するようになります。これは，プロジェクトの目的達成と同じ方向を向いているうちは，成功しますが，えてして現場の人間は経営目標などより自分が楽になる方向に意見をいいます。 結果，統制のとれない，いろいろな方向を向いたプロジェクトになってしまいます。 いったんプロジェクトの目的と違う方向に動き出したらもう止まらないということです。 この組織と属人性というトレードオフをどう解くか？ これらのトレードオフを説くカギもやはりプロジェクトマネージャです。新しいプロジェクトマネージャに求められているのは，この点なのです。 従来型のプロジェクト管理手法と，ＸＰなどのライトウエイトなプロジェクト管理の接点をみつけ，ハイブリッドな新しいプロジェクト管理手法が今求められているのです。 これはそれほど難しいことではありません。 ＰＭＢＯＫなど従来型のプロジェクトマネージメント手法に準拠しつつ，プログラマとの接点（指示の仕方）を工夫するとか，スケジューリングを細かく変更できるように工夫するとか，要所要所にＸＰ的なノウハウを入れるとか，そういったちょっとの改善でプロジェクトは同じ方向（目的）をむきつつ，現場プログラマのやる気を導き出すプロジェクトが実現できます。 　たとえば，プログラマに指示を出すときに，範囲と目的をちゃんと説明して，細かい解決策自体はプログラマの自由な発想にまかせるとか，やり方はいろいろ，現場によって適応方法を区賦してみてください。