Solution

デブサミ2005 レポート

　デベロッパーの復権
　閉塞した状況を打ち破り、開発者が想像の力を取りもどすために、 デブサミは全てのIT技術者を対象に、新しい集いの場を提案します。

Developers Summit の主旨より
TOP > Solution > デブサミ2005 レポート

今年のデブサミ

　去年のデブサミ2004は、トム・デマルコ氏の講演を聴きに行っただけだった。あれから、アジャイル関係の本を通読し続けて、どうやらプロジェクトマネージメント関係の本にも手を出さないといけないと思い始め、PMBOK や CMM の入門書を読んだ。デマルコ氏の言う「彼は天才的で、理論もすばらしいけれども、TOC をソフトウェアプロセスに組み込むということは、結局、個人の時間が犠牲になるだけなのだ」という言葉がずうっと頭に染み付いていた。この意見が、正であれ否であれ、考慮しなければいけないと直感的に思い、(大袈裟に言えば)一年間考え続けてきた。
　アジャイルとは反対側にある PSP（パーソナル・ソフトウェア・プロセス）の書籍も買い、『アジャイルと規律』などと比べ合わせていくわけなのだが、私の中では XP であれ、スクラムであれ、 ウォータフォールであれ、CMM や ISO9000 にしても、適応範囲と適材適所があるわけで、プロジェクトについてどのプロセスが適切かどうか、いや、最適解ではなくて、総じて適切であろうという解をどのように見つけるのか、という結論に至りつつある。
　今回は、そういう視点からデブサミ2005を聴講してみた。なので技術的な部分はさておき、みなさんがどんな形で開発をしているのか、プロジェクトマネージメントとはどういうことを考えていると思っているのか、という形で、振り返ってみることにする。

私の受講したセッション

　振り返ってみるセッションを並べてみよう。 　他にもいくつかのセッションを受けたが、ここでは開発プロセス関係に絞っている。
　自分の感想も含めて簡単に書き付けて以下に書き付けておく。

成功への動機づけに欠かせないプロジェクトマネージメント

　プロジェクトマネージメント学会 副理事長 冨永氏の話となる。
　感想から言えば、PMBOK と EV分析（アーンド・バリュー分析）、そして PSP（パーソナル・ソフトウェア・プロセス）の勧め、ということになるのだが、そこに「動機付け」という形でプロジェクトの「目標」を重視しているのが新鮮だった。　PMBOK や ISO9000、CMM の入門書を読んでいくと、プロジェクト如何に管理するか？という手法（特に管理帳票）についての記述が多い。実際、ISO9000 では、エビデンス（証拠）という形で、プロセスからプロセスへ 移るときにクリアすべき基準を明確にし文書として残しておくことが強調されている。例えば、契約プロセスの終了には、取り交わした契約書を残すとか、設計から開発へ移るときには、 設計書が要件を満たしていることを審査や検証などで妥当性を確認せよ、という形になる。CMM であっても、レベル３の段階まではプロセスが再使用可能であることを重視しているので、勢い管理帳票や手順書が重視されがちになっている。　そんな状況の中で、中国では PM（プロジェクトマネージメント）の本が流行っているそうだ。多分、貿易の開放のせいもあり中国内に工場が増え、実際にプロダクト／プロジェクトを管理する人達が増えてきた、ということなのだろう。冨永氏の話によれば、380種類の PM の本があり、駅のキオスクで買えるぐらいなわけだから、相当「流行っている」らしい。
　で、中国の有人ロケットを例にとって、プロジェクトには明確な「目標」が必要であると言い、プロジェクトXとは違い実際のプロジェクトには番組的な「ヒヤヒヤ」や「ハラハラ」は必要ない、と言い切る。私もそう思う。確かに、何か偶発的なものがプロジェクトを成功に導く唯一のものだとしたら、それは「プロ」の仕事ではない。プロは、なんらかの成算を持って仕事を貫徹させるわけだし、成功するか否かのあやふやなプロジェクトばかり続けては生きてはいけない。おそらく、私たちの IT 業界は 30% 以下の成功率しかないから、こんなにマネージメントが下手な状況でもなんとかやっていける会社があるのだろう。これが、80% を超える成功率（たとえば建築業とか土木関係とか）の業界だったら、そんな会社は即座につぶれてしまう。
　そういう中で、管理する手法としての PMBOK そして EV、最後に冨永氏が実際に作ってみたPSP を使って機械を作ってみた実例が示されている。
　PMBOK の手法かつ、 を組み合わせていこう、という主旨になる。
このあたり、マネージメント手法と「明確な目標」や「リードと動機付け」という形の人間的なモチベーションの話になり、実はアジャイルで言われる人を大切にする思想を思わせるところがある。このあたり、PMBOK であっても決してアジャイルの対極ではなく、手段としての EV や PSP を取り入れてみるのもいいかな、と思わせるところがあった。

ITSS時代のプロジェクト人材戦略

　加藤氏は、パソナテックという人材サービス会社の方である。パソナテックは、本デブサミのスポンサーでもあり Microsoft や IBM, Sun と肩を並べているところが面白い。
　最近政府では、情報処理技術試験から ITSS という形で技術者の能力をレベル分けしようとしている。技術が細分化していることもあるし、転職市場を活発にして個人の能力を引き出そうという意図なのだろう。
　まず、加藤氏は冒頭に「プロジェクトは何故失敗するのか？」の理由のひとつして「PMに依存しすぎている」という話を出している。社外の折衝や予算管理、契約管理、進捗管理など、PM（プロジェクトマネージャ）の仕事はかなり多いのだが、これらを満足にこなせる PM は少ない。なので、会社としては「優秀なPMはいないだろうか？」という形で、人材サービス会社にコンタクトを取る。だが、世の中そんな優秀な PM が余っているわけもなく、優秀な PM ならば会社が手放すわけもないので、はっきり言って、「プロジェクトの成否を決めるのは PM だから優秀な PM を雇えば、赤字プロジェクトを抱えなくて済む」というのは夢物語なのだ。
　その昔（いまでもそうかもしれないが）、スーパープログラマ偏重の時代があった。プロジェクトのキーマンとして優秀なプログラマ（開発者）を入れれば、進捗遅れをすることなく素晴らしいアプリケーションを完成してくれる、という願望だ。しかし、これも変な話で、優秀なプログラマがそうそう市場に転がっているはずはない。
　プログラマにしろマネージャにしろ、自己能力の出来不出来がある。また、嗜好によりさまざまなキャリアを用意しておいたほうが、人は伸びる。そのために ITSS を利用しましょう、という提案のようだ。
　確かに、プロジェクトを立ち上げるとき、「Javaプログラマが欲しい」という漠然とした話よりも、「Javaでネットワークを組めるレベル2以上のプログラマが欲しい」という客観的な指標があるにこしたことはない。また、現在の IT 業界で、給料をあげようと思うと、どうしても管理職（マネージャ）にならないといけないという風潮がある。優秀な開発者であっても、リーダ職やマネージャのように現場を離れないといけないために、現場から優秀な開発者がどんどん抜けていく、という変な現象が起きている。何時までたっても、プロジェクトは、2,3 年の若手プログラマが開発を行うか、（言い方は失礼だが）給料に固執しない年老いた開発者の手に委ねられてしまうのである。これはちょっと、というかかなり惜しい。
　Microsoft は技術者を優遇することで業界一にのし上がってきたわけだが、これは少し例外的なところもあるので、一般的な業界を例にとれば、「技能試験」や「免許」という制度があって、国や公共団体が客観的な指標を示しておけるとよいだろう。
　既にある指標として、XML/UML 技術者や、Microsot/Oracle 試験があるわけだが、ITSS の場合はもっと広い範囲で技術者をカバーしていけるのではないだろうか。
　あと、加藤氏が話していたが、ITSS の認定と社内の階級（課長、部長など）とは切り離して考えなくてはいけない。ITSS は ITSS なりの指標を持ちプロジェクトを進めるための役割を割り振るために使う、足りない人選があれば「人材サービス」に求める。という宣伝風な感じの意見もあったが、なぁに、外注する場合も同じことで、相互に得意分野を寄せ合うことで、スーパーマネージャやスーパープログラマを必須としない成功プロジェクトに結びつけることができれば、Win-Winの関係になる、ということだろう。

失敗から学ぶプロジェクトマネージメント

　失敗から学ぶということであれば、「失敗学」が有名なのだが、伊藤氏の話からは失敗学は出てきていない。ある目標が決まれば、結果が出たときに成否が分かる。成功もあれば失敗もあるわけで、どちらから学ぶのかといえば「失敗」から得る価値のほうが高い。というのも、成功の要因はある偶発性の結果という不確定要因を含むのだが、失敗の場合は、それを避ければ少なくとも同じ失敗を繰り返さなくて済むという学習と再現性を含んでいるからである。
　伊藤氏が語るプロジェクトの失敗原因を並べたものは となる。これが全てではないだろうが、ワインバーグによればプロジェクトの失敗は50%以上は管理の問題にあるので、マネージメント意識の不足はプロジェクト遂行において致命的であるといえる。
　で、失敗から何かを学ぶのであれば、人の失敗から学ぶほうがよい、と加藤氏は言う。私もそう思うし、ワインバーグも同意するだろう。自らの失敗は客観的に分析しづらいということもあるが、あまり失敗を繰り返してしまうと肉体的・精神的・金銭的に疲弊していしまい、将来に成功できるかどうかもあやふやになってしまう。だから、自分の乏しい経験よりも他人の豊富な失敗経験から学んでいこう、というのが正しい学び方なのだ。
　そんな中で、加藤氏は「プロジェクトマネージメント費用を見積もりに組み込む」ことを推奨している。見積もりには管理費用を組み込むことができない場合が多い。というのも、顧客からみると、ソフトウェア開発において具体的な製品と呼べるものは「納品された可動できるソフトウェア」という印象があり、盛り込めるのは設計書やコーディング時間、試験であり、品質活動や管理費用などの間接費用は認めない、という顧客/大手SIが多い。勢い、マネージメント費用は、プロジェクト外で積算するか、その他の工程に薄く散らして積み上げる形式になることが多いのだが、そういう外部的な見積もりと、内部で製品を仕上げるための金額比による二重帳簿的な扱いによって、マネージャが本来の業務を忘れる、という落とし穴に落ちてしまうことがある。つまり、管理費用を忘れてしまう、あるいは、管理費用がないので管理しようとしない、という現象が発生する。そういう失敗を犯さないために、マネージメント費用はきっちりと見積もりに含めるほうがよい。
　また、会社ではいくつものプロジェクトが平行して動いているのだが、マネージャは手元にあるプロジェクトしか見ていないという場合が多い。これは、手元にあるプロジェクトの成否がマネージャ自身の評価を決めることが多く、他のマネージャとの競争である以上、マネージャ同士はあまり協力したがらないというゼロサムゲームの関係にあるからだ。しかし、本来は、会社の業績があがらなければ、蛸壺化してしまっているマネージャの給金はあがるべくもない。このあたりは評価制度の欠陥もあるのだが、それをフォローするためには、プロジェクトの枠を超えた組織内でのPMO（プロジェクトマネージメントオフィス）という存在が必要である、と加藤氏は言う。またステークホルダーとして「人」を重視したマネージメント手法が必要ということだ。
　最近、大手の会社では本部長制度に移行している。本部長というのは部長の上に位置する役職で、いままで各部毎に利益を競い合っていた状況、あるいは内部発注により一見仕事が発生しているようでいて実は内部で金が巡っているだけという部毎の不都合を回避し、各部署をまとめて組織として採算をアップさせる目的を持った役目を本部長が担う、という制度になる。これは TOC制約理論による部分最適化から全体最適化という流れになるだろう。
　PMO の主な役割としては ということになるそうだ。このあたりの実施は、まさにトップからの決断とサポートが必要で、下層（スタッフ、プログラマレベル）からの活動だけでは為しえない。テレビの CM ではないが、「上司に恵まれなかったら」と思っている人も多いに違いない。

なぜ「オープンソース」でうまくいくのか？

　前半は、風穴氏による Linux Kernel 開発の様子の説明。後半のまつもと氏との対談の前置きということなのだが、一応「オープンソース開発」についての説明になっている。ただ、風穴氏も話していたが、オープンソースというテーマがちょっとデブサミに似合わなく、先日オープンソースカンファレンスも開かれたことなので、「オープンソース」の定義について結構ややこしい状態になっているので、歯切れの悪い話になってしまった。
　日本では、オープンソース開発の流れは VA Linux という会社が 日本版の sourceforge を提供していることもあり、利益の追求と GPL が掲げる文化とは現実的なところでは、まあ、うまくやっているように見える。水面下ではいくつか論争もあるだろうが、いまのところ GPL が裁判で取り上げられたことはないそうだ。実際、GPL のような権利を主張しない権利（という言い方もちょっと語弊があるけど）に対してどれだけ効力があるのか、どれだけ著作権／特許権のような主張する権利に対して有効であるかは、まだ現実に証明されていないことだろう。
　Linux Kernel の開発は、Linus 氏を尊重して行われているが必ずしも中心人物とは言えない、というのが Linux Kernel 特有のオープンソース開発だろうと思う。現在「オープンソース」の定義には、ソースを公開するだけでは駄目で、いくつかの制限というか規約みたいなものがあるので、sourceforge に登録し、ソースを公開たからといってオープンソースとは限らない、という妙な感じになっているのだが、いくつかの企業が OSS（オープンソースシステム）に積極的なのは、Windows 一辺倒の開発から離れることと、いままで公開されているソースコードを利用して利益を得ていこうという資本主義的な行動が中心になっている。勿論、最近では政府の後押しもあり、ソースをオープンにすることによりセキュリティ問題を早期に解決できる、バックドアのような仕掛けが作られにくい、という利点も強調されているのだが、Windows vs Linux の TCO 削減効果という記事があちこちで見られるようにコスト面と運用面では、オープンソースだからといって単純にコスト安とは限らない、という面も持っている。セキュリティ／運用コストのひとつであるウィルスの存在であっても、Linux 自体が Windows 程度のシェアを持てば悪意あるプログラマのターゲットに成りかねない。実際、オープンソースの筆頭にも属する FireFox にも脆弱性があり、Linux をターゲットにしたウィルスも増えていることから、「オープンソースだから」というのは賢い顧客に対してはセールストークにならなくなるだろう。
　そんな状況もあるのだが、私的に言えば私はオープンソースが好きだ。なによりもソースを見ることができ、プログラマとして学習する機会が多くなる。後半のまつもと氏の話にもあるが、Unix 文化から育ってきたプログラマは、一般的にソースを共有することを厭わない。自己主張という意味もあるのだが、ソースを公開して貰ったら、ソースを公開して社会／コミュニティに貢献する、というギブ・アンド・テイクの思想が心底根付いている。勿論、「大人」であるので、生活費を稼がないといけない、なんらかの企業秘密は公開できない、などと色々制約はあるにせよ、プログラムコードを通じて相手の頭を除き見て関心し、自分の実力をアップして誇示する、という子供じみた遊び（とは私は思わないが）が好きな人は多いだろう。開発系のメーリングリストで「こんなのできたよ！」というのが多いのはそのためだ。

　さて、後半はまつもと氏と風穴氏の対談になるのだが、だいたいは風穴氏がまつもと氏にインタービューするという形式になっていた。詳細はmatzにっきに詳しいのだが、私の印象としては、オープンソース開発を支えているのは、やっぱり個人の熱意なのではないか、ということだった。私が Ruby を知ったのは 5 年程前だったのだが、大学の頃から perl を使っていた私にとっては、ruby をいまさら勉強する気にはならなかった、オブジェクト指向言語ということで C++ に注力していた関係もあって、perl のようなスクリプト言語にはツールとしての役目を求めていたためでもある。
　で、ruby 自体を見直したのは 2,3 年前の UnitTest の動きで、実際、業務で UnitTest のフレームワークを独自発想的に作ろうとしていたところで、ふと見た RubyUnit という本に魅了されてしまったのである。なんだ、世の中にはこういう方法でやっている人もいるんだ、ということで UnitTest の世界を漁り、まずは文法も分からない RubyUnit の本を通読、JUnit を探して、CppUnit, CUnit を知り携帯開発業務に使う、という流れを得た。本格的にオブジェクト指向言語として使い始めたのは、3ヶ月ほど前なのだが、CGI を組むときに perl で DOM を扱うよりも ruby のほうがいいのは？と思い立ち急遽勉強。perl5 でクラスを書いてもよいのだが、私の知識は perl4 で止まっているので、どうせ学ぶなら新しい言語がよかろう、という形だ。
　そんなわけで、ここ 3ヶ月ほど ruby-list をしばらく眺めているのだが、まつもと氏のアプローチは、突っ込み過ぎでもなくかといって冷ややかでもなく、フルタイムで ruby 開発に関わっているのでレスポンスは早いのだが、なんらかのトラブルにはほとんどタッチしないという姿勢は、ruby 開発を 12 年間と長く続けていくので必須な原動力ということだろう。実際、ruby-list で流れていたのだが、めんどうなことはやらない、という性格（？）が幸いしていると思う。
　そうであっても、長い間投げ出さずにここまで続けてきた、おそらくこれからも続けていくのだろうが、その根底にはプログラマ特有の熱意が潜んでいると思う。Linus 氏の Kernel 開発もそうなのだが、大きくしようとか有名になろうとかいうよりも、自然に広まるまでコツコツと続けている姿勢が大切になってくる。勿論、ビジネス的には、シェアを保つこと、セールスをすること、というビル・ゲイツ氏的な視点が必須になってくるのだが、そのあたりは別な話なのだ。どうやら、ビジネスの話は避けるという打ち合わせだったらしいので、受け答えとしては面白い形になってよかったと思う。

アジャイル実践！アジャイルはトヨタ生産方式か？


　坂田氏の発表は、社内でトヨタ生産方式を全面的に導入し、その上でアジャイル開発を組み込もうという試みになる。永和マネージメントシステムの平鍋氏のサポートを得てプロジェクトを進めたそうで、平鍋氏の「見える化」と重なるところが多かったが、プロジェクト終了後の詳細な分析には目を見張るものがあった。
　発表対象のプロジェクトは、Webアプリケーションでサーバ側のみの2ヶ月間の開発となる。マネージャを含めて、総勢９名のメンバであり、開発歴は10年程度が2名、5年以下が7名という比較的若いメンバで占められていた。ある意味、若いメンバのほうが、従来のウォータフォール方式のなじみも薄くおかげで、技術要素やプロセスも新鮮なほうが導入しやすいともいえる。
　導入したプロセスは基本をXPとして、これにトヨタのカンバン方式を加えている。 　たくさんのプラクティスがあるが、これは平鍋氏をコンサルタントに迎えて、なるべく多くのプラクティスを導入しようと努力した結果だそうだ。普通のプロジェクトの場合、なかなかここまで導入するのは難しい。マネージャ／リーダが率先して受け入れない限り、「ペアプログラミングの生産性は？」、「受け入れてストは誰がつくるのか？」という問題が発生してしまう。また、ウォーターフォール型のプロセスを顧客から要求された場合、ストーリーカードのような流動的な要求導入をするのは難しく、設計書や要件変更定義などを管理する必要がある。この対象プロジェクトの場合、幸いにも、そのあたりの制限から外れることができたそうだ。
　プロジェクトの進捗状態は、普通 Excel シートを使って電子文書で管理することが多いのだが、坂田氏のプロジェクトでは「ソフトウェアかんばん」ということで、ストリーカードをホワイトボードに貼り付けて進捗状態がひと目で分かるようにしている。これは、スクラムのバックログ管理にも等しいし、ワインバーグのPPPにも等しい。常に皆の目に見える状態にしておくと、何が遅れているのかが明確になり、隠し事によるプロジェクトの失敗が激減する。自分たちの遅れを隠そうとする心理的な問題、また、無意識に難問から目をそむけてしまうマネージャとは違い、進捗自体がオープンになっているので、問題があるときは誰が見ても問題があるように見える、のである。こういう雰囲気は、非常に大切で、リスクマネージメントをマネージャに依存させてしまうよりも、全員が分かる立場にいるという現場の雰囲気がポイントになってくる。
　あわせて、バーンダウンチャートを使うことにより、全ストーリー数／ポイント数のどれだけが終了したのか？を一目瞭然にすることができる。この「完了」の度合いは難しいものがあるが、できることならば、このプロジェクトのように受け入れ試験済みのストーリー数をカウントしたい。以前、同じようにバーンダウンチャートを使いモジュール数で計測してみたことがあるのだが、単体試験済みではなくコードの完了で勘定してしまったため、コーディングが終わっても製作工程が終わらない（単体試験が済んでいない）という状態になり、ずるずると製作＆試験工程が延びる結果になってしまったことがある。
　ただし、発表プロジェクトのような「受け入れ試験」をうまく作れないことがある。今回の場合は、Webサーバアプリの開発であったので、クライアントPCからの要求という形で切り分けができたのだが、GUIを持つ業務アプリケーションや性能要件(スピード／容量）を含めると、どのような受け入れ試験を作るのか、が難しいときがある。うまく切り分けができるような設計が必要になるだろう。また、受け入れ試験を本当の顧客が作る技術を持っていない場合も多いので、顧客をサポートする「顧客プロキシ」の働きも大きいだろう。
　統合的結合は、単体テスト済みのソースをチェックインするガード役として非常に重要である。ただし、これは自動ビルド、自動試験が必須になる。たとえば、UnitTest を使わない単体試験の場合、シートにチェックマークを付けながら試験をすることが多いが、これを毎日行うことは不可能に近い。毎日毎日すべての試験を再度行う必要があるのか？という議論になってしまう。そのためには、自動で行う仕組みが必須になる。また、自動で試験ができるような設計をあらかじめ行っておくこと、つまりコンポーネント化／オブジェクト化が必須になるのである。
　さて、アジャイル開発がトヨタ生産方式か？、の私なりの回答になるのだが、そもそもが、スクラムの発祥が『知識創造企業』なわけだし、『知識創造企業』が研究対象にするのが刺身方式と呼ばれるトヨタやソニーの開発形態なので、ぐるっとひと回りして戻ってきただけかなぁ、と思ったりする。ただし、「ソフトウェアかんばん」のようにローテクを使い壁に紙を貼る方式、そのローテクの中から PDCA を廻して日々改善行動を行うという実体験は何にも変えがたい創造性を生み出す現場を作ってくれる。
　「楽しい現場」、「やりがいのある仕事」である。

Microsoft Solutions Framework


　これはコンサルティング本部の小泉氏の発表になる。
　MSF(Microsoft Solutions Framework)は、10年前から開始しているのでアジャイルよりも古い、ということなんだが、スクラムの提唱者ケン・シュエイバーは、元Microsoft勤務なので、このあたりはズレがあるのだろう……というか、MSF は若干「厳密」なプロセスの部類に入るのかもしれない。
　MSFチームと役割群と職能領域ということで に分けられる。前半の３つは従来のプロジェクト管理手法の領域になるのだが、後半の３つが蔑ろにされているためにプロジェクトが失敗している、ということが多い。つまり、「プロダクトマネージメント」不足のために顧客の要求しないシステムを開発してしまう、「ユーザ・エクスペリエンス」による調査不足のために顧客に使いづらいシステムを提案してしまう、「リリースマネージメント」をしないために運用後まったく動かされることのないシステムを納品してしまう、ということだ。
　この役割と人の割り当て、職能として定義され社内の階級とは異なる点、つまりプロ化というところでは、ボーランド社の推奨するFDD（ユーザ駆動開発プロセス）に似たようなところがある。FDD もアジャイル開発のひとつになるが、モデル駆動、UML駆動等と同じように、ユーザ機能を中心としてプロジェクトを運営していこうという手法になる。FDD では、比較的規模の大きいプロジェクトを対象としているので要求定義や設計書の作成を重視している部分も多く、ISO9001 や CMM、複数社間でのウォータフォール開発に混ぜ込むことが可能になっている。
　小泉氏の話でちょっと面白かったのは、小さなプロジェクトで MSF を導入したときに、いくつかの役割を兼務することになるが、このときの注意点である。たとえば、プロダクトマネージメントはプログラムマネージメントと兼務できない。つまりプロダクトマネージメント（通常PM）は、顧客の立場になり考えるのでプログラムマネージメント（通常PL）のように社内のチームの立場を重視した再計画を立てづらい立場にある、ということである。顧客の立場に立てば、納期や予算は PM にとって最低限守るべき砦となるわけだが、PL にとっては予算よりもアプリケーションの完成度が目標になってくる。このような相反する役目を兼務してしまうと、心理的な葛藤が起こるか、どちらかに判断が偏ってしまうという結果になり、プロジェクトのバランスが崩れ失敗してしまう。
　また、開発者（いわゆるプログラマ）は、その他のどの役職とも兼務していはけない。これは、電話のベルや不要な会議から開発者を守る、ということを重視し、Microsoft 社特有の開発者重視の姿勢の表れだと思う。逆に言えば、PM や PL は開発に着手してはいけない。PM や PL がコーディングをし始めたプロジェクトは必ず潰れる、という結果を MSF は示しているわけである。
　そのあたりのノウハウが一切合切入っているのが MSF であり、それを他社にも提供しているようだ。日本語のドキュメントもあるので見ているのもよいだろう。

ソフトウェアの「見える化」


　永和マネージメントシステムの平鍋氏の講演になる。『リーンソフトウェア開発』の訳者でもあり、トヨタ生産方式とアジャイルを混ぜて実現していく、という形になる。
　『リーンソフトウェア開発』の最初に「バリューストリームマップ」という図があり、プロジェクトに実際にどれだけの時間を使ったか、という使用時間と待ち時間を比べた図がある。たとえば、顧客に質問状を送って回答を待ったり、設計書ができあがったときに承認待ちに入ったりして、プロジェクトを進める場合には意外に待ち時間が多いのだ、という証拠になる。もちろん、待っているといっても漠然と待っているわけではなく、平行してプロジェクトを進めていたり、空き時間に食事をしたりと、別なことをやっているので完全に無駄（リーン）とは言えないのだが、生産現場における「短納期」を実現しようとしているとき、この待ち時間は確実に無駄には違いない。この無駄を省く＝待ち時間をなくす、ということがリーンソフトウェア開発の主題になる。いわゆる JIT(Just In Time)なわけだ。
　で、本講演はリーンソフトウェア開発ではなくて「見える化」の実例になる。「見える化」は、人の頭の中を図にしたり、言葉だけで交わされている会話を図式化したり、プロジェクトの進捗状態をホワイトボードに書き残したりする「図解」という手法になる。セッションの中での説明として、野球のスコアボードの例を出していた。スコアボードは９回までの点数の経過が分かるし、各チームの選手名や守備も分かる、打順もわかり、現在何回の攻撃かがわかる、優れた「見える化」の例である。こんな風に、ひと目でわかるものをソフトウェア開発の現場でも使っていこうという提案＆実践になる。
　このような「見える化」を日々繰り返し実践することで、フィードバックを行う。フィードバックを受け次の行動をカイゼンすることが「管理」なのだ、というわけだ。実際、私もそう思う。ワインバーグの言う「舵取り文化」がこれにあたる。フィードバックを考慮せずに最初の計画で突っ走ってしまえば、道を逸れて畑に落ちてしまう。カーブをうまく曲がるためにはハンドルを少しずつ調節しながら進まなければいけない。
　他の「見える化」の例として、マインドマップ、SKMS、タイムラインが挙げられている。理系な私としては、図を描くこと、議論をするために数式とグラフを駆使することは通常行っていることなので、これには非常に賛成できる。さらにゴールドラットの論理マップや、ワインバーグのフィードバックの図も加えるといいだろう。

振り返ってみて

　木曜日、金曜日の二日間でデブサミに出席した後、土曜日、日曜日とかけてこのレポートを書いている。レポートというほどまとまったものでもないし、私見もおおいに含まれているので、参考程度あるいは覚書程度に残しておく予定だ。
　デブサミの場合、開発者向けということで製品カンファレンスのような管理者向けのアピールは少ない。つまりは、経営層／管理者層がなんらかの効率化のために開発ソフトウェアを買い、下層にいるプログラマに与えるという上意下達方式が多いということだろう。開発者自身にアピールするのは、やはりコミュニティの重視、いかに仕事をたのしく過ごすか、ということだろうか。私の出席したセッションは技術系のものではないので、どちらかといえば背広を着た50代の人達や、アジャイル関係の人達が多かったようなのだが、それでも日ごろ「デスマーチ」に明け暮れていたり、上司や顧客に振り回されている下っ端の立場から開放されて、似たような立場の人達が頑張っている姿を見ると、かなり元気が出てくる。アジャイル開発の基本は、フィードバックそして改善という当たり前の行為なのだが、ISO9001 や CMM のように繰り返し生産を前提としているシステマティックな管理手法には及びつかない行為を必要としている。勿論、ISO9001 や CMM も改善のフィードバックを持ち、PCDA を行うことを前提としているのだが、いちど「認定」されてしまうと、ほとんど「習慣化」してしまいフィードバックを怠り改善されずに盲目に突き進んでしまうという行動学の分野に踏み込んでしまう。デマルコの言う通り、CMM は、最も期待はずれの技術なのかもしれない（現在は、CMMI として CMM 自身を改善されつつあるし、ピープルCMMというのもあるので、期待していいのか、どうなのか私はわからないが）。
　プロジェクトX方式であれ、トヨタ生産方式であれ、結局のところは、人間が創るものなのだから、人間の気持ちに即した形でソフトウェア開発を進めていくのが、より人間らしい仕事ができる現場となると私は思う。チームEQ やプロフェッショナル志向、エンドユーザ指向という形で、今後の私は進めていこうと再度思う。
copyleft by t.masuda