« 2007年12月 | トップページ | 2008年2月 »

2008年1月

2008/01/27

そのボタンを押したら何が起きるのですか?~アーキテクチャは利害関係者のコミュニケーション手段

「実践ソフトウェアアーキテクチャ」を読んでいたら、アーキテクチャと利害関係者、特に要求を出すユーザとの関係について、興味深い挿話があった。
ソフトウェアアーキテクチャについて再考してみる。

【ストーリー】

政府支援のITプロジェクトは、スケジュール遅延・予算超過で問題となっていた。
政府は過去の怠慢を何とかしようとして、マラソンのような長時間のプロジェクトレビューが始まったが、ユーザでもありプロジェクトを管理する政府の代表者たちは疲れきっていた。

とある午後、議題は、システムのソフトウェアアーキテクチャ。
若いアーキテクトが威勢良く登場して、巨大なシステムのソフトウェアアーキテクチャが、信頼性や可用性、効率性などの要求をいかに満たしているかを説明し始めた。

アーキテクトは、四角や線の表記法で描かれた図で、システム実行時にどんなソフトウェア要素が動くか、つまり、データフロー、メッセージパッシング、プロセス同期について、理路整然と説明した。
その記法はアーキテクトが作ったものだが、中身の詰まったプレゼンテーションだった。

「障害が発生した場合は、、、」とアーキテクトはレーザーポイントを使って説明し始めていた。
突然、
「そのモード選択ボタンを押すと何が起きますか?」
と聴衆の一人が質問した。
彼は、そのシステムのユーザコミュニティを代表する政府出席者だった。

「もう一度、ご質問を」とアーキテクトは聞き返す。
「あなたがそのボタンを押すと何が起こりますか?」とユーザ代表者は尋ねた。

「えーと、それはこのデバイスドライバのイベントをキックし、、、」とアーキテクトは続けて、
「イベントを判断し、モード選択ならば、表示板に信号を点灯させ、そのイベントを処理するオブジェクトへ信号を送ります。」
と答えた。

「いいえ、私は、システムは何をするのか、と聞いたのです」とユーザ代表者は遮った。
「表示をリセットするのですか? システムの再構成中にこのイベントが発生したら何が起こるのですか?」

アーキテクトは少し驚いて動揺して、レーザポインタを落とした。
アーキテクチャについての質問ではなかったが、アーキテクトである彼は、要求に精通していたので、答えを知っていた。
「コマンドラインが設定モードであれば、表示はリセットされます」と彼は答えた。
「そうでなければ、エラーメッセージが制御用コンソールに表示されますが、信号は無視されます」と続けた。

「私の質問は」とユーザ代表者は言った。
「あなたの図を見ると、表示用コンソールは信号をターゲット位置のモジュールへ送っているように見えます。」
別の参加者が質問した。
「何が起きるのですか?」

「システムを再構築する間、本当にユーザにモード情報を取得させたいと思っているのですか!」
と更に別の参加者が尋ねた。

そして、それに続く45分間、ユーザ代表者を含む参加者は、様々な難解な状況において、システムの正しい振る舞い(つまり仕様)は何か、について討論し続けた。

この討論はアーキテクチャに関するものではなかったが、アーキテクチャが論争に火を付け、アーキテクトや開発者以外の利害関係者(つまりユーザ)のコミュニケーションの基盤となった。

実は、ユーザはアーキテクチャ説明の前に延々と、機能、操作、ユーザインターフェイス、品質に関して説明を聞かされていた。
ユーザは皆、もう帰りたいと思っていたはずだ。

だが、アーキテクチャに関するスライドが、ユーザに何を理解していないのかを自覚させた、と。

【1】アーキテクチャは開発者だけでなく、要求を出すユーザにも役立つ

「実践ソフトウェアアーキテクチャ」の上記のストーリーが興味深いのは、アーキテクチャという設計者と開発者にしか関係しないと思われる内部書類が実は、要求を掘り起こすものだったという事実だ。
つまり、新しい方法でシステムをみる観点が考えを刺激し、新たな疑問を表面化させた。

ユーザは、システムがどのように機能するのか、という観点よりも、システムが何をするのか、をいつも興味を持つ。
アーキテクトは、ユーザがアクセスできる最初の専門家であるため、ユーザはためらうこともなく、質問を浴びせかけただけ。

公的システムなのだから当然、要求仕様書はあったろうが、アーキテクチャが実装と仕様と要求をつなぐミッシングリングになっていた。

何故実装に手間取るのか、何故この機能は実装できないのか、という理由は、アーキテクチャの仕様に由来すると言っていいから。

【2】アーキテクトは、設計する人ではなく、調停者である

「実践ソフトウェアアーキテクチャ」ソフトウェアプロダクトラインの解説本なのだが、この本を書いた佐々木さんが以前、SEA関西で講演された時があり、印象に残った内容がある。

それは、ソフトウェアプロダクトラインが定義するアーキテクトの役割は、設計者だけではなく、顧客や開発者、そして会社の上司に当たる管理者へ、システムとアーキテクチャを説明することだった。

つまり、アーキテクトは調停者なのだ、と。

「実践ソフトウェアアーキテクチャ」の上記の話では、アーキテクトがユーザに対して、要求とシステムの仕様が一致しているのか、矛盾していないか、という討論になった。

普通は、アーキテクトは開発者へ、こういうフレームワークを使って、こういう仕様とこういうコーディングルールで書いてくれ、と説明し指示するだろう。
アーキテクトから管理者へは、このアーキテクチャで実装すると、これだけのコストがかかりますが、その後の運用保守では楽になります、品質も保証されます、のように回答するだろう。

アーキテクトは、アーキテクチャという抽象概念、つまり設計思想によって、ユーザ・開発者・管理者へ3通りの観点で、システムを翻訳し直す技術力と政治力を必要とする。
つまり、アーキテクトはシステムの説明責任を負う最終責任者であると言える。

「実践ソフトウェアアーキテクチャ」の上記のストーリーの話題は、信頼性という品質に関わるもの。
アーキテクチャの話は、その根本を辿ると、品質特性に位置づけることができる。
例えば、効率性、使用性のような外部特性だったり、保守性、移植性、可読性のような内部特性だったり。

ソフトウェアプロダクトラインの話を聞くと、必ず、品質と再利用の話になるが、その理由は、アーキテクチャと品質が密接に関わっているからだろう。

品質という眼に見えないもの、そして利害関係者の認識がなかなか一致しないものを対象とするのが、システム屋の仕事。

品質について、もっと考えてみたい。

| | コメント (0) | トラックバック (0)

2008/01/26

プロジェクトは冒険ゲームだ

すだち師匠が紹介した「仕事を100倍楽しくするプロジェクト攻略本」を読んだ。
ぷよぷよなどを手がけたゲーム開発者によるプロジェクト攻略のノウハウ本。
プロジェクトをRPGで喩えた中身が面白かった。
印象に残った部分をまとめてみる。

【設定】
・冒険=プロジェクト
・勝利条件=目的
・王国=会社
・冒険の地図=プロジェクト計画(プロジェクトマップ)
・7つの秘宝=スケジュールのマイルストーン

【登場人物】
・勇者=あなた
・王様=うえの人
・仲間=メンバー
・パーティ=チーム

【武器】
・アイテム
・キーアイテム
・秘密アイテム
・必殺アイテム

【最強パーティのキーワード】
・自分マトリックス=自己分析シート
・キャラクターシート=メンバー分析シート

・インタビュー
・Yes And
・4つの距離(自分・相手・仲間・世界)

・アイデアミーティング
・ホットミーティング

【冒険のキーワード】
・現在地
・目的地

・生きている問題 or 死んでいる問題
・冒険の合言葉=コンセプトフレーズ

・冒険の書=プロジェクトふりかえり

【1】プロジェクトは冒険ゲームだ

「仕事を100倍楽しくするプロジェクト攻略本」では、 「一番いい冒険(プロジェクト)は勇者(あなた)が楽しい冒険だ」というフレーズから始まる。

プロジェクトは「冒険」、
自分は「勇者」(つまり主人公)、
上司は「王様」、
メンバーは「仲間」、
プロジェクト計画作成を「冒険の地図を書く」、
問題解決を「クリアする」、
プロセス改善を「攻略する」
などのようにRPG風に言い換えると、何故かワクワクしてくる。

敵を倒すためにはどのアイテムがいるのか、目的地に着くためにどのルートに進むか、などのように発想が膨らむ。

面白いRPGは以前に戦った敵とまた戦うチャンスがあるように設定されている。
冒険を進めて、冒険の地図をバージョンアップすることで、勇者の成長を実感できるはず。

冒険で挑戦する時、目の前の問題が生きているのか、死んでいるのか、判断することは大事。
死んでいる問題とは、既に答えが分かっている問題。
生きている問題とは、誰も答えを知らず、自力で見つける問題。

学校の試験は死んでいる問題。
問題の解決方法が見えているなら、死んでいる問題。

冒険は基本的に生きている問題。
プロジェクト(冒険)は生物なのだ。
だからこそ、プロジェクトで発生する問題は生きている問題ばかり。

プログラマなら、生きている問題は分割統治して攻略するのが基本パターンだ。
プロジェクトリーダーは、開発者やお客様から寄せられる問題や課題に対して、分割統治や作業仮説で攻略する。
つまり、メンバー1人が作業できるレベルや範囲まで分割したり、InputとOutputを決めて、間のHowの部分をモデル化してみる。

【2】王様の攻略方法

「仕事を100倍楽しくするプロジェクト攻略本」によると、王様(上司)は勇者(自分)にとって、味方だけれど、目的も立場も異なる微妙な人。
冒険の目的は、一つではない。
王様の目的は、金儲けだったり、王国のイメージアップだったり、冒険者の成長だったりする。
勇者の目的は、技術を試したかったり、好きな仲間と冒険したかったり、新しい経験をしたいとかだったりする。

でも、冒険を成功させるという目的は勇者も王様も同じはず。
勇者は、王様の目的を聞き出し、冒険のゴールに入れておく。
勇者と王様のベクトルが合っていれば問題ないのだ。

でも、王様と対立することを恐れない。
「仕事を100倍楽しくするプロジェクト攻略本」では、「退屈をぶっ飛ばせ」というフレーズがある。

本来、王様は王国(会社)を基盤とするから、元々保守的な立場。
勇者は、冒険するのだから、挑戦者。
王様とはそもそも立場も目的も異なるのだから、勇者は自分の勝利を譲ってはいけない。

勇者は、冒険における自分の目的をいつもイメージしなければ、王様の保守的な意見に惑わされて、冒険の目的地を忘れてしまう。
だからこそ、冒険の地図(プロジェクト計画)や自分マトリックス(自分の目的や動機を分析したマインドマップ)を作っておき、バージョンアップしていくのが大切なのだ。

【3】最強パーティへの道~4つの距離(自分・相手・仲間・世界)

勇者は仲間とパーティを組んで、冒険していく。
仲間も、初期設定では能力もパワーも低いのが普通。
冒険していくにつれて、成長して、パワーアップしていく。

冒険が終わって、仲間がダメだと思うようでは勇者失格。
冒険が成功すれば、パーティ全員の手柄。
冒険が失敗したら、勇者の責任。
仲間の気持ちをそこまで持っていけなかったということだから。

冒険を進めていくには、勇者が仲間に伝えることが大事。
「仕事を100倍楽しくするプロジェクト攻略本」では、その時、4つの距離があると言う。
この内容に最も惹かれた。

3-1.自分との距離
 自分は理解しているか?
 自分がやりたくないことを体を削ってやっている、とかないか?

3-2.相手との距離
 仲間各人に伝えること。
 1対1のシチュエーション。
 「仕事を100倍楽しくするプロジェクト攻略本」では、勇者と仲間の距離感を最も強調している。

 勇者が仲間から報告・連絡・相談するシーンを「インタビュー」と言っている。
 つまり、勇者は仲間と、相手との距離で話しながらも、「インタビュー」という第三者の客観的視点の雰囲気も交えながら、パーティとの距離感を醸し出す。
 勇者のインタビューを受けたという事実は、仲間にとって一つの「キー」となり、勇者との信頼関係をより膨らませてくれる。

3-3.パーティとの距離
 仲間全体に伝えること。
 「仕事を100倍楽しくするプロジェクト攻略本」では、よくある失敗例として、チームで伝えた内容がメンバーが理解していないことがあげられていた。
 つまり、「相手との距離」と「パーティとの距離」を混乱していたこと。

 情報の共有、問題に対する認識の共有、ブレインストーミングなどは、パーティとの距離を使うのが効果的。
 でも、人の気持ちを変えるとか、意欲を膨らませる方法は、パーティとの距離では馴染まない。
 仲間全員に伝える時、勇者の言葉は平均的になり、仲間の心に響かない。
 そもそも、それは、相手との距離でやるべきこと。
 
 だから、最初は、パーティとの距離で認識を共有し、仲間一人一人に相手との距離で接して、当事者の雰囲気で伝える。
 プロジェクトファシリテーションでも、このテクニックを使っているはず。

3-4.世界との距離
 目の前にいない、パーティ以外の人達。
 「仕事を100倍楽しくするプロジェクト攻略本」では、想像力を強調していた。
 例としては、検収後のお客様の要望や課題などだろう。
 仲間と緊密になりすぎると、第三者の視点が必要になる。

プロジェクトリーダーはコミュニケーション時に、「相手との距離」「チームとの距離」を心がけると、客観的に分析しやすくなるに違いない。

思い出せば、プログラマがプログラムを書きたいと思う動機は本来、業務用アプリを作るためと言うよりも、ゲームを作りたい気持ちを持つ人が大多数ではないだろうか?

とまあ、「仕事を100倍楽しくするプロジェクト攻略本」のようにプロジェクトを冒険に喩えて、ゲーム感覚でやる発想は楽しい。

| | コメント (0) | トラックバック (0)

2008/01/20

【考察】要求と品質の関係性

「成功する要求仕様 失敗する要求仕様」を興味深く読んでいくうちに、「要求と品質の間にはどんな関係性があるのか?」が疑問として上がってきた。
要求と品質について考察してみる。


【要求エラーの種類】
「成功する要求仕様 失敗する要求仕様」では、いわゆる要件定義のプロセスを要求マネジメントと呼び、その重要性を強調している。
成功したプロジェクトでは開発コストの10~20%、失敗したプロジェクトでは5%以下という統計があるらしい。

「成功する要求仕様 失敗する要求仕様」では、要求マネジメントを下記のプロセスと定義している。
但しシーケンシャルとは限らない。

1.要求の導き出し

2.要求のトリアージ

3.要求の仕様化

そして、要求マネジメントで発生する要求エラーを下記として定義している。

【A】認識エラー
要求の導き出しプロセスで発生する「要求として認識されなかった」エラー。
いわゆる要求漏れ。

「成功する要求仕様 失敗する要求仕様」では、マズローの欲求5段階説を持ち出し、システムに対する顧客の満足度は、ある程度の機能を満たさないと次の要求が出てこないと言う。

この指摘は同意する。
例えば、新規開発でVer1.0をリリースした直後は、まずは信頼性を最優先し、性能や使い勝手は後回しにする時が多い。
この場合、検収後、バグや不具合として課題が上がってくる時が多い。
そして、Ver1.1から順にリリースしてバグフィックスしていくと、機能が安定してくる。
すると、お客様から、もっと使い勝手を良くして欲しい、とか、こんな機能も追加して欲しい、という課題が多くなる。
つまり、課題の質も、苦情から期待へ変化する。

期待系の課題は、信頼性という品質がまず確保されないと、使用性や効率性の品質まで要求が上がってこない。
非機能要求は、後々、システムのカスタマイズで要件漏れとして発覚しやすい。

また、「成功する要求仕様 失敗する要求仕様」では、要求の導き出しで必要なテクニックは、ステークホルダー分析とファシリテーションであると指摘している。

「開発者の仕事はファシリテータであり、顧客が要求を理解できるように手助けする」ことだと述べている。
この指摘は興味深い。
つまり、要求候補を洗い出すプロセスでも、開発者が主導権を握って、顧客をコントロールする必要があることを示している。

【B】トリアージエラー
要求のトリアージプロセスで発生する「要求を実現するために十分なリソースが足りない」エラー。
例えば、機能AとBを実現すると、CとDの開発には間に合わなかった、という事象を指す。
つまり、どの機能を最優先で開発するか、という決断が間違っていたことになる。

この事象は、プロジェクトリーダーならいつも遭遇するはず。
プロジェクトマネジメントで重要なプロセスとしてリソース管理、スケジュール管理があげられるが、有限のリソースをいかに上手に使うか、いつも悩まされる。

「成功する要求仕様 失敗する要求仕様」では、スケジュールも要求の一つと指摘している。
つまり、スケジュールから要求の優先順位を付けることを示唆している。

「成功する要求仕様 失敗する要求仕様」では、要求のトリアージに力点を置くという視点が斬新なのかもしれない。

【C】仕様エラー
要求の仕様化プロセスで発生する「要求を文書化する時に全関係者に共通の見解を与えられなかった」エラー。
つまり、要求そのものは全関係者で合意は取れているが、実現した時に間違っていたということ。
要求を理解しきれていなかったことが相当するだろう。

この事象は、開発チームの設計力、技術力と比例するように思う。
設計力がなければ、要求を仕様化した時、仕様の整合性を突き詰めて考えることができないだろう。
技術力(特にプログラミング力)がなければ、1つの要求からどれだけ広範囲にプログラムに影響があるか、見極められないだろう。

また、品質の内部特性がここで発生する。
要求に関係するステークホルダーとして開発者もいるが、開発者の視点から見ると、保守性や再利用性が良くなければ、要求を後から実現することは難しくなる。

ここで分かることは、顧客は品質の外部特性しか見ないため、保守性や再利用性という要求は開発者からしか出てこないこと。

お客からは、信頼性(機能が業務をカバーしていること)、効率性(性能)、使用性(使い勝手)のように、品質の外部特性しか見ない。
開発者からは、保守性(機能追加や修正がしやすいこと)、可読性(ソースコードが読みやすいか)、再利用性(他システムへコンバートできるか)、理解性(アーキテクチャの一貫性)のような品質の内部特性を重視する。

プロジェクトリーダーの視点からは、システムの品質が新規開発時だけでなく、運用保守フェーズでも、チームの生産性に直結する。
要求に品質を上手く混ぜ込むことが大事だと思う。

| | コメント (0) | トラックバック (0)

2008/01/19

【告知】「XP寺子屋」第1回

「XP寺子屋」第1回
~XPの価値について考えよう!

◆内容
■開催日時
日時 :2008年02月01日(金) 19:00~21:00
場所 :大阪市中央公会堂 B1F第4会議室
住所 :大阪市北区中之島1丁目1番27号
参加料:無料

--------------------------------------------------------------------------------

■XPの価値についてみんなで話し合う
ワールドカフェスタイルで、XPの5つの価値(シンプル/コミュニケーション/フィードバック/勇気/尊敬)に沿ったテーブルを用意し、それぞれの価値について話し合います。

--------------------------------------------------------------------------------

■ご持参下さい。
「ワールドカフェ」にちなんで、皆さんのお気に入りの 【飲み物】 をご持参下さい。
お気に入りの飲み物を飲みながら、気軽にお話しましょう!!

!!注意!!
ソフトドリンクに限定します。
アルコールは禁止です。
※アルコールは、懇親会でお願い致します。m(_ _)m

■参加人数
30名

■申し込み締め切り
08年1月29日

※締切日前に参加人数に達した場合、受付終了致します。あらかじめご了承願います。

■申し込み
こちらから申し込み願います。
折り返し、詳細案内を送付致します。

■主催
XPJUG関西

| | コメント (0) | トラックバック (0)

2008/01/18

【告知】フレームワーク勉強会 at kansai.pm

Kansai.pm フレームワーク勉強会

Kansai.pmでは、来る1月26日(土)にフレームワーク勉強会を開催します。

この勉強会は、言語を問わない(Perl PHP Ruby Python Java Javascript .NET Haskell Schema etc...)フレームワークに関する勉強会です。

詳細は

http://kansai.pm.org/cgi-bin/wiki.cgi?action=ID&b=ZLi4nlBxzTtZhqkoUVhTwA

をご参照ください。
時間などが変更になる可能性がありますので、参加をご検討の方は上記URLにて随時ご確認ください。


■日時

2008年1月26日(土) 13時10分~16時50分
開場時間:13時00分

■会場

大東市立生涯学習センター 特別会議室

JR学研都市線 住道駅下車 徒歩3分(住道駅と直結)

ALPSLAB baseでの地図

■定員

54名

■参加費

発表者の交通費などの実費として、500円程度のご負担をお願いし
ます。
学割を用意する予定です。

■名札について

他の参加者との交流を図るため、用意できる方は名札をご持参くだ
さい。首から提げるタイプの名刺フォルダの貸し出しと、名刺サイ
ズの用紙を準備していますのでそちらもご利用ください。

■電源タップについて

ノートPCを持参される方は、なるべく電源タップもご用意ください。
会場ではコンセントが部屋の隅にしかなく、参加者で協力しないと
電源が確保できない可能性があります。

■内容 (順不同)

はしもと
「共用サーバーでも使える軽量フレームワーク CGI::Application」

あきぴー
「DIコンテナとAOP~Seasarの基本思想について」

AzureStone
「国産ウェブアプリケーションフレームワーク TripletaiL - 日本
の文化 -」

ku-suke
「乱立するPHPのフレームワーク比べ2008/1」

Simon Cozens
「難しいものはMaypoleで簡単」

LT

lapis25
「JavascriptフレームワークExtJS」

なみかわ
「Kansai.pm2007年活動報告」


■ 懇親会

場所
「偶」住道北口店

時間
17時30分~19時00分
(少し早く始めるかも知れません)

参加費
女性2,625円、男性3,150円(飲み放題付き)

学生割引
割引額は未定です。社会人の方々には申し訳ございませんが、
学生割引分の追加出費にご協力よろしくお願いいたします。

■参加方法

参加登録フォームから、ミーティングの参加と懇親会の参加の両方を受け付けております。

ミーティングは飛び入り歓迎ですが、懇親会は店の予約の都合上、原則として事前登録をお願いいたします。

事前登録なしでの懇親会飛び入りはできない可能性がありますことをご了承ください。

懇親会事前登録は1月25日(金)正午を締め切りとします
(前倒しになる可能性があります。なるべく早めの登録をお願いいたします)。

| | コメント (0) | トラックバック (0)

2008/01/16

資本政策の重要性

「次世代プロフェッショナルの働き方―27歳からのシゴト論」を読んだ。
日経ITProに連載されていた外資系プロジェクトマネージャー論が気に入っていたのもあるが、面白かった。
感想を書いてみる。

【1】35歳以降は外部から利益をもたらせるかどうかで評価される

「次世代プロフェッショナルの働き方―27歳からのシゴト論」の著者は言う。
ルーチンワーク型よりもプロジェクト型の仕事がいい。
理由は、プロジェクト型の仕事の方が成長が伴うから。

学校にいると、3年おきに成長したかどうか自身で測定できる。
でも、社会に出た後、自分の仕事を意識しないと、自分が成長したかどうか分からない。
実際、10年経っても同じような仕事をして何も変わらない人もいる。
逆に、見違えるように成長する人もいる。

35歳までに何らかのプロになることにこだわって仕事すること。
理由は、35歳以降になると、それまでに築いた人脈、人間関係が大きくモノを言う時期だから。
例えば、プロジェクトをやるには、誰が必要で、その人に自分は信頼されているか、という類のこと。

でも、20代で相手にギブするぐらいのプロは少数派。
だから、35歳までにプロと称されるような経験を積む。
そして、この人なら付き合ってもいい、と思える所があって、コミュニケーションが始まって、人間関係が広がっていく。
こうしたキャリアを35歳までに築かないと、35歳以降の展開に支障をきたす。

35歳までに人脈形成ができないと、ずっと同じ仕事、ルーチンワークをこなすしかない。
理由は、35歳以降では、会社の外部から利益をもたらすかどうかで評価が決まるから。
そのために、人脈が必要なのだ、と。

僕も同意すると共に、インターネットが普及した現在は、人脈はより簡単に作れると思っている。
少なくとも、コミュニティが、緩いけれど深く濃い人間関係を衝突し合う場になっている。
たとえ20代であっても、その人に能力があれば、人脈なんて簡単に作れる。
むしろ、コミュニティで切磋琢磨する方がより刺激的だ。

【2】資本政策が重要だ~資本主義ではバランスシートがPLよりも大事

「次世代プロフェッショナルの働き方―27歳からのシゴト論」の著者が言うには、上場していない会社は、借金する時、社長個人の名義で借りる。
上場した会社は、借金する時、会社名で調達できる。
この違いは大きい、と。

この事象は、実際の仕事でも感じる。
普通のITプロジェクトはおそらくウン千万円ぐらいから始まるだろう。
そんな大金は個人で保証できるものではない。
会社と言う看板があるからこそ、取引できるし、プロジェクトが失敗したとしても、個人に賠償責任がいくわけではない。

また、「次世代プロフェッショナルの働き方―27歳からのシゴト論」の著者が言うには、会社を作って上場させてわかったことは、資本政策の大切さ。
理由は、資本は後から変えられないから。
売上や利益は毎年クリアされる。
しかし、資本は一度切り売りしたら二度と戻ってこない。

上場する時、証券会社や投資会社は資本を取りに来る。
と同時に役員もここで資本を争うことになる。
資本を一番持っている者が、上場した会社の経営主体になりうる、と。

資本主義では、所有と経営の分離が基本だったはず。
だが、資本という所有資産を持っている者が最終的に強いのだ。

「金持ち父さん貧乏父さん」本でも似たような箇所があったのを思い出した。
お金の流れが3パターンある、と。
その日暮らしの下層階級は、収入から消費へお金が流れるだけ。
マンションや家という一生分の借金を背負う中流階級は、収入から負債にお金が流れる。
上流階級だけ、収入から資産へお金が流れて、お金が溜まっていく、と。


歴史を思い出そう。
資本主義と民主主義は何故か同時に生まれて、密接に絡んでいる。
所有と資産、自由。


「次世代プロフェッショナルの働き方―27歳からのシゴト論」は、外資系に行きたい人、これから就職する人にとって、参考になるかもしれない。

| | コメント (0) | トラックバック (0)

2008/01/14

【感想】JavaScript読書会#2

JavaScript読書会#2へ行ってきた。
48人も集まったよ(~o~)
はるばる東京や三重から来た人もいるし!(^^)!

今日も通称サイ本の輪読。
中身の濃かった勉強会の内容を整理するために書いてみる。

【1】関数型言語HaskellをJavaScriptで書き換えてみる

ライトニングトークスでUjihisa君の話「JavaScriptとHaskell」が興味深かった。
Haskell読書会に出たものの、どうしてもHaskellのソースは読めなかったけれど、JavaScriptで置き換えてくれてようやく、Haskellが分かった気がした。

詳細は発表資料を見ればよいが、JavaScriptの無名関数やブロックを巧みに使うと、Haskellのソースを基本的に全て翻訳できる。
但し、Haskellの遅延評価や無限配列はJavaScriptでは書けないらしい。

JavaScriptを関数型言語で置き換えると、どんな利点があるのか?

僕はまだ分からないけれど、少なくとも、prototype.jsの中身のソースにcuury関数が定義されているように、Ajaxのような非同期処理を読みやすくする技術に使われているようだ。


【2】マルチスレッドプログラミングに弱いJavaScriptを補強するライブラリ群

JavaScriptのマルチスレッド関係のお話も興味深かった。

そのライブラリは、わずか40行のソースで、sleep()やwait()、setTimeOut()をJavaScriptで実現する。
そのライブラリを使ったJavaScriptソースを見ると、try{}catch{}構文ではなく、「.」で繋がったメソッドチェーン形式のソース。
#つまり、5.times.(...)みたいなソースのこと。

そのソースは、初めて見る人はビックリすると思う。

JavaフレームワークよりもRailsが優れている点の一つに、メソッドチェーン形式のソースのため、英語の文章を読んでいるかのような雰囲気になる所があること。
JavaScriptでは、非同期処理をメソッドチェーンで書くという斬新さがある。


【3】プロトタイプチェーンという発想がプロトタイプベースのオブジェクト指向を規定している

サイ本を議論した内容は「ステートメントと式の違いは?」「.(ドット)は演算子なのか?」などのような、まるでJavaScriptの仕様を最初から勉強し直すような高度なもの\(^o^)/

nanya_tさんの下記の質問から、全員を巻き込んだ「プロトタイプチェーン」の熱い議論が始まった。
Lingrから抜粋した一部の会話を見よ。
#以下、Lingrから抜粋したので敬称略。

◆nanya_tさん
//falseは何故?
A=function(){}
A.prototype = {
get: function() {return this.x*2;}
}
a=new A();
alert(a.constructor==A);

//trueは何故?
A=function(){}
a=new A();
alert(a.constructor==A);

◆amachang
A.prototype = {} とすると、もともとの prototype プロパティの中身が破壊されるので constructor がおかしくなる(Object で上書きされる)

よって、さっきの例では、(new A).constructor が Object

◆deq
aはAのインスタンスで,Aはconstructorをもってるけどaはもっていない

a.prototype は A で a.prototype.constructor ってこと,でいいのかな?

◆cuzic
個人的にはメソッド探索のチェインが重要だと思うんだけどな。

◆Tagawa
あかん・・amachang先生とnanto先生の議論に付いていけない。

◆kanasan
多分、かなりの人間がついていってない。

◆nitoyon
amachang先生とnanto先生の議論はあとで配布します(別売)

deqさんのログが、本質的な回答になると思う。


【4】Lingrというチャットを使った議論が新鮮

サイ本を読んでいるバックグラウンドでは、Lingrというチャットルームで、参加者全員が質問や突っ込み、告知を行うというスタイル。
#LingrはRuby on Rails で作られているらしい。
#ちなみに「36 chatters and 10 observers」でした。凄すぎ。。

誰も喋らない間でも、Lingrではすごく熱い。
参考URLを貼ってくれたり、サンプルソースを貼り付けてくれるので、非常に分かりやすい。

僕も突っ込んだり、質問すると、必ず誰かがフォローしたり、答えてくれる。
話すよりも書く方が楽な時もあるので、自分の考えをまとめたり、他人のソースコードを読む時に非常に役立つし楽しい。

一昨日のRuby関西でも、Lingrを使った。
こなみ先生のソースインスペクションのレッスンでも、勉強会の議論は少ないけれど、Lingrでは、お題に上がったソースを皆が色んな観点から批評して、逆に勉強になった。

今や関西の勉強会では、Lingrは必須だ!(^^)!


【感想】
関西のコミュニティの中でkanasan.jsは、最も集客力を誇るRuby関西よりも、参加人数も議論のレベルも上回るかもしれない。

48人もの参加者へ細やかな気配りをして頂いたkanasan、そしてスタッフの方々に本当に感謝です。

| | コメント (0) | トラックバック (0)

2008/01/13

【再考】プロセスで品質を作りこむ

「コードコンプリート」第2版下巻を輪読した。
品質、テスト、デバッグの章を読んで、非常に参考になることばかりだった。

「コードコンプリート」を読むまで「プロセスで品質を作りこむ」という格言の意味が分からなかった。

整理するために感想を書いてみる。

【1】テスト自体はソフトウェア自体の品質を改善しない

「コードコンプリート」によると、テスト(単体・結合・システムテスト)をいくらやっても、一般に存在するエラーの高々50%しか検出されない。

テストの結果は品質の指標になるだけだ。
ソフトウェアの品質を上げたいなら、テストを増やすのではなく、開発プロセスを改善しなければならない、と。
その実例や測定結果も載せていた。

この指摘には衝撃を受けた。

どのプロジェクトでも、テストケースを増やしたら、ソフトウェア品質が上がっているように思えないだろうか?
それは、痩せるために体重計にのる回数を増やしているだけ。
痩せないのなら、新しい体重計を買うのではなく、ダイエット方法を見直さなければならない。

つまり、開発プロセスそのものを見直さなければ、品質は上がらない。

【2】ソフトウェア品質の原則~品質を改善すると開発コストは下がる

「コードコンプリート」によると、欠陥を検出したり修正するコストは後工程になるほどコストが高くなる。
エラーやバグが紛れ込んだ時期が早ければ早いほど、そして、ソフトウェアのほかのパーツに紛れ込んで見えなくなるほど、それを排除するコストは高くなる。

これをソフトウェア品質の原則と称して、色んな実例を載せている。

いわく、欠陥の低いプロジェクトは開発工数が短い。エラー排除はソフトウェア作業で最も高価で時間がかかる。

いわく、要求や設計の変更が原因でも、デバッグやテストが原因でも、コーディングのやり直しにかかる時間を減らすことが生産性と品質を上げる最善策だ。

いわく、品質の低いソフトウェアを開発して修正するよりも、品質の高いソフトウェアを開発する方が安価だ、と。

いわく、開発の早いPGは最も多く速く欠陥を検出し、修正した、と。

「コードコンプリート」には「悪魔のささやき」というブラックジョークがある。

・欠陥は憶測で探せ
・問題を理解しようとして時間を浪費するな
・真っ先に思いついた方法で解決せよ

この手法を意外に実行していないだろうか?

特に、プロジェクトリーダーは、納期を遵守するために、本来あるべきプロセスを省いてしまう時が多々ある。
その影響は、品質劣化という結果に直結する。

プロジェクト終盤でプロジェクトリーダーがよくやるパターンは、リリースする機能の数を減らして、限られた範囲の機能の品質を保持することに注力すること。

つまり、7つの品質特性のうち、信頼性を重視するために、スコープを狭くして作業工数を減らす方向へ持っていくことをよくネゴする。
そして、開発・検証プロセスはできるだけ省略しない。

但し、この手法が使えるには相当の政治力が必要。
スコープを狭くするとは、システムのあるべき機能を削るのだから、お客様の本来の業務の一部をシステムがサポートしないことを意味する。
信頼性を削ることと同じ。

この手法を「プロジェクトを成功させる 現場リーダーの「技術」 」では「ウルトラC的アクション」と言っている。
つまり、ゴールの前提条件を変えてしまうこと。
ゴールはお客様との合意の上にあるわけだから、お客様の要求を根本的に変更させるぐらいの相当の政治力を必要とする。

【3】品質改善のために、テストだけでなくソースインスペクション、ペアプロも組み合わせる

「コードコンプリート」では、テストだけでなく、ソースインスペクションなど他の手法も組み合わせることを推奨している。
特に、「コードコンプリート」によると、ソースインスペクションの効果を強調している。
「コードコンプリート」が説明するソースインスペクション方法はとても組織的だ。

モデラー、作成者、レビューアの3人が、設計書やチェックリストから、あくまでもソースの欠陥を検出することへ注力する。
そして欠陥を修正し、その結果を確認する。

ソースインスペクションを重視する理由は、そのプロセスが自ら最適化される仕組みがあるからだ、と「コードコンプリート」著者は言う。
つまり、標準的なチェックリストと標準的な役割によって体系化されるし、フィードバックを繰り返す過程でチェックリストが改善されるし、インスペクションの準備や修正の速さや効果度が監視されるので最適化される、と。

この表現は、CMMIのレベル3の標準的プロセスをイメージさせる。

つまり、インスペクションプロセスは、体系的(レベル3)で、繰り返し実行することが可能(レベル2)で、測定結果(レベル4)に基づいたフィードバックを使って自身を改善する(レベル5)。

このテクニックは他のプロセスにも応用できるし、「コードコンプリート」では「開発組織に当てはめたら、これらの考え方は組織に最高水準の品質と生産性をもたらすだろう」と言っている。

逆に、「コードコンプリート」ではウォークスルーは批判的だ。
効果が低いという測定結果も載せている。

「コードコンプリート」が否定的な観点を提示するのは、ソースインスペクションという焦点が曖昧で、公式なインスペクションに組織やメンバーが否定的な所ほどウォークスルーを使っているという経験談があるからだろう。

また、「コードコンプリート」では、「テストファーストプログラミングは過去10年間に登場したソフトウェアプラクティスの中で最も効果的なものの一つ」と言い切っている。

「コードコンプリート」では、XPを新しい分野の欠陥排除テクニックと呼び、その測定結果から、かなり効果的であると断じている。
実際、XPのプラクティスでは、ペアプロによるソースインスペクション、テスト駆動開発によるテスト重視、デイリービルドで回帰テストなど、意図的に複数のプロセスを組み合わせているからだ。

その意味では、XPを含めたアジャイル開発は、過去10年のソフトウェアの歴史で工学的に、あるいは経験で裏打ちされたプラクティスなのだ、とも言える。


「コードコンプリート」は上下2巻で1000ページ、1万円を越える大著だが、この本2冊で、プログラミング技術だけでなくソフトウェア工学の知識も殆どカバーする。
すごい本だと思う。

↓上巻はこちら


| | コメント (0) | トラックバック (0)

2008/01/12

【Ruby関西】自分のプログラミングスタイルを持とう

Ruby勉強会に行ってきた。
何故か今日も雨でした。
Ruby関西が開かれる日は雨が多い(^^♪

目玉はCuzicさん著作「Ruby on Windows」の基調講演。
講演は「Ruby on Windows」の内容紹介と思ったら、Cuzicさんが貯めてきたノウハウをメッセージとしてプログラマへ贈る内容だった。

1・プログラミングを始めたばかりの人へ
2・プログラミングに慣れてきて人へ
3・プロのプログラマへ

詳細はWikiを見てもらって、感想を書いてみる。

【1】プログラマの美徳は怠惰さ

手作業やルーチンはできるだけ自動化する。
そのためにプログラムがある。
「プログラマの美徳は怠惰さ」はPerlの偉い人の言葉、と彼は引用した。

 「Ruby on Windows」の目的も「RubyでCOM、RubyCLR、Rjbなどを使って、Windows/.NET/Javaを快適に操作しよう」というもの。
 Rubyistは基本的にUnixの世界で生きているが、Windowsの世界で生きている人も使えるし、強力なツールになりうる。

【2】自分の興味・情熱の方向を知ろう

初心者PGへの彼のアドバイスに「学習できない時にその理由を感じ取ろう」というものがあった。
できない言い訳にその人の本心や本質がある、と。
「時間がない」「どうすればよいのか分からない」などの代表的言い訳の裏には、意識化できない感情や衝動がある。
意識されない抵抗を馬鹿にせず、ありのままに感じ取り、自分の興味や情熱の方向を知っていこう、と。

このアドバイスは非常に参考になる。
心の風邪を引いた人は、やる気がない。
そこまでいかなくても、心がざわめいて、仕事に取り掛かれない時がある。
そんな時に、自分のやりたいこと、打ち込めるもののように、自分の方向性を知っておくことは、プログラミングだけでなく生きる上でも大事。

また、Cuzicさんは「すでに出来上がったものの仕組みを知ること」「文法の整合性を調査する」などが好きらしい。
多分僕も殆ど同じで「出来上がったものを使うこと」「仕様の整合性を考えること」も好きかな。
本当のハッカーは「新しいアイデアを考えること」「機能を組み合わせて作ること」が好きなのだろう。

【3】自分のモチベーション向上や集中できる環境を知ろう

中級PGへの彼のアドバイスに「感度が上がると、自分のプログラミング能力が低く感じるようになる。それが成長だ」というものがあった。
つまり、知識が増えて色々経験すると、自分が書いたプログラムが大した事がないように思えてくるが、その理由は、意識のレベルがプログラミングよりも上がったから、と。
それが、学習できない言い訳になる時がある、と。

上級PGへの彼のアドバイスに「どんな時にモチベーションが上がりますか?」というものがあった。
人によって、ハートが熱くなるツボは違う。
レベルが上がるほど、情熱的になれるツボを知って、自分の心をハンドルできるようになることが大事だ、と。

更に「集中するノウハウはありますか?」というものもあった。
理由は、プログラミングは集中力が大切だから。

Cuzicさんの場合、設計は集中できないがコーディングは集中できる、とのこと。
理由は、プログラムを書かないとアイデアが膨らまない、書いていくうちに分かってくる、とのことだった。

僕の場合は逆に、プログラムを書く前にフローやデータ構造を徹底的に考える方がプログラミングがスムーズだった。
プログラムを書くと、詳細に入りすぎて、何を実現したいのか忘れてしまう。
設計には十分時間をかけて、プログラムは一瞬に書き上げる方が僕は合う。

そういう各個人の特徴を知っておくことが大事。

【3】自分のプログラミングスタイルを持とう

彼のアドバイスに「人にコードを見られることを意識することそのものが進歩になる」があった。
プログラミングには癖があるので、他人の批評を受けることで洗練されていく。
Ruby関西の人たちはオープンソースに積極的なので、自分のソースをどんどん公開していく。
また、ライブコーディングといって、観客の目の前でお題を限られた時間でプログラミングするということまでやっている。
彼らは、他人に自分のプログラムを見せたい、という強烈な自己顕示欲があるのだと思う。

また、「サンプルプログラムは、問題を解決するプロセスそのもの」というアドバイスもあった。
実際、プログラムを書かないと分からないことは多い。
解きたい問題だけでなく、ライブラリの仕様や相性なども書いて初めて分かる。

「自分のデバッグ方法をノウハウを持っておこう」というものがあった。
 暗黙知として持っておくのが大事だ、と。
Cuzicさんの場合、pメソッドで変数出力するのが基本。

また、出力から逆算し、通った分岐を推測することもやる、と。
この手法は、バグの症状から逆に、こういうフローで出てきたのだろう、と推理していくこと。
インプットから書き始めるのがプログラミング。
バグ直しは、アウトプットから始める。

自分の興味や集中できるやり方を体を通じて知って、自分のプログラミングスタイルを身に付ければ、更にレベルアップできますよ、という彼のメッセージは非常に参考になった。

Ruby on Windows」もいい本なので是非読んでみて下さい。


| | コメント (0) | トラックバック (0)

2008/01/06

SWOTと因果関係図は相性がいい

成功する仕事術―プロジェクトマネージャー/リーダーのための参加者をリードする会議の進め方」を読み返して、気づいたことを書いてみる。

SWOTは、自社の強み・弱み・機会・脅威をマトリックスに書く。
アイデア発散の方が書きやすい。
でも、整合性を取る時や深く掘り下げる時に、この項目だけで十分か不安になる。

因果関係図は、プロジェクトの悪循環の現象などを原因と結果をつなげてシスティマティックに書く。
時系列で表現できる指標をつなげると書きやすい。
でも、項目が漏れていないか、何か物足りない時がある。

SWOTで出てくる項目を因果関係図でつなげると、発想が進む。
そもそも、長所と短所、機会と脅威は同じ現象の表裏一体であることが多い。
つまり、お互いが関連し合い、相互にエネルギーを補完する関係にあるときが多い。

例えば、品質と再利用は表裏のコイン。
品質が良いものは再利用したくなる。
再利用できるものは、色んな観点から使われているので品質が良い。
因果関係図で書くと下記になる。



SWOTと因果関係図はペアで考察した方が思考も進む気がする。

| | コメント (0) | トラックバック (0)

2008/01/05

量子革命がコンピュータ革命を引き起こした

埃を被った本棚から懐かしい本「サイエンス21」を見つけた。
21世紀の科学を予想する2000年に出た本。
当時、夢中で読んだ記憶がある。
その頃の感想を思い出しながら書いてみる。

【1】学習する機械は夢を見る

1980年代、物理学者ホップフィールドが、神経科学のニューラルネットワーク分野で、

脳の中にあるニューロンを格子の中の原子のように扱えるか?

という量子力学の発想を取り入れて革命を起こした。
その当時、人工知能の分野には系統だった組織原理がなく、バラバラの知識の集まりに過ぎなかった。

彼のアイデアでは、原子がエネルギーが最小になるように自らを配置するように、ニューラルネットワーク回路もそのエネルギーを最小にしなければならない。
つまり、「学習」は最も低いエネルギーを発見する過程なのだ、と。

脳内のニューロンネットをでこぼこの地形にボールを転がしている状況にたとえてみよう。

ボールはどこか一つの谷に落ちるように、絶えず最も低いエネルギーの状態(谷)を探している。
つまり、転がっているボールとは、複雑な学習過程の喩えになる。
このアイデアを発展させると、谷は「記憶」に相当する。

このモデルから、強迫観念とは、一つの谷が非常に大きくなって、近くの谷を全て飲み込んでしまった状態とも言える。

更に、このモデルが面白いのは、脳内のニューラルネットワークが夢を見始めるという発見。

ニューラルネットに多くの谷(記憶)を入れると、機能低下を起こす。
つまり、それぞれの記憶をスムーズに思い出せなく始める。

実際の記憶に相当しない好ましくないさざ波(擬似記憶、つまり夢)が地形の表面に出る。
この擬似記憶を取り除くために、故意に地形に小さな乱れを作ると、ボールは谷から投げ出されて再び転がり始める(眠りに相当する)。

眠ったり、夢見たりを何回か繰り返した後、ニューラルネットは機能低下が止まり、同じ速度で全ての記憶を思い出せるようになった(起きるに相当する)、と。

この発見の意味は、高度に発達したニューラルネットはその記憶を処理するために夢を見なければならない。
ニューラルネットに大きな負荷がかかりすぎると、夢と言う現実と異なる記憶が出てくる。
そんな夢を取り除くために眠る、と。

このアイデアは衝撃を受けたし、この発想をシステム開発で生かすとどうなるだろうか?
学習する組織、成長する開発者は、学習するにつれて、谷を増やしていく。
でも、いつかはその谷に飲み込まれてしまうことがあるだろうか?
そうならないように、夢を見るように、一度学習してできた谷を全てなくすようなプロセスが必要ではなかろうか?

そんなプロセスは、XPで言えば、週40時間労働なのかもしれない。
休息は必須なのだ、と。

【2】量子コンピュータこそ究極のコンピュータ

1980年代、ファインマンが、

コンピュータはどれくらいまで小さくなりえるか?

というアイデアで、量子コンピュータを考えた。
つまり、コンピュータを原子の大きさまで小さくした加算器と見なしてみよう、と。

例えば、沸騰した液体、二つの粒子の衝突といった事象という量子物理学の興味深い問題にチューリングマシンでは答えを出せない。
つまり、量子物理学で出てくる経路積分は無限大を計算する必要があるからだ。

彼の発想の根本は、量子の問題は量子コンピュータで計算させればいい、というもの。

量子コンピュータの理論は90年代の数学で聞いたことがある。
象徴的な結論は、量子コンピュータは全ての暗号を解くことができる、というもの。
すなわち、全ての素因数分解を解くことができることを意味している。
本当に実現されてしまうと、安全なクレジットカード決済などは全て意味がなくなってしまう。

今は量子コンピュータは、頭の中にある空想の産物に過ぎない。
でも、過去の歴史を見るように、いつかは実現されるだろう。

その時、P=NP問題なども量子コンピュータで全て解けてしまうのだろうか?

【3】量子力学がバイオテクノロジー、コンピュータ科学の思想を根本的に書き換えた

量子力学はコンピュータ、人工知能を完全に書き換えた。
更に、バイオでも同じ現象がある。

1944年、量子物理学者シュレディンガーが「生命とは何か?」で、

生物は原子の量子論で解明できる。
分子配列の中に閉じ込められた「遺伝暗号」(彼の造語)によって生命は支配されている。

と大胆に断言して革命を起こした。
そこから、DNAの2重らせん構造の発見、DNA塩基配列の調査が始まる。

#ちなみに、「生命とは何か?」は岩波新書で出版されていて、専門知識がなくても初心者でも読めるレベルです。
#でも古本しかないのか。。僕は図書館で借りて読んだ記憶しかない。。

これらの事象を振り返ると、20世紀前半に生まれた量子力学が全ての科学とその現象を根底から覆して、新しいモデルを作り出したことが分かる。

サイエンス21では「量子革命がコンピュータ革命、バイオ革命を引き起こした」と言い切っている。

更に、サイエンス21では、2020年、2050年の未来も予想しているけれど、当たっているような外れているような所もあり、結構面白い。

| | コメント (0) | トラックバック (0)

2008/01/03

【Facilitation】解けない問題を解ける問題へ変換する

ザ・ファシリテーター2―理屈じゃ、誰も動かない!」の本で「解けない問題を解ける問題へ変換する」という挿話がある。

ファシリテーションを得意とするコンサルタントが、ある病院にやってくる。
そこでは、医師と事務のお偉方が「前年度よりも20%手術件数を増やす」という課題について議論していた。
しかし、その会議では、医師は忙しいのだ、医師の数が足りないという堂々巡りの議論ばかり。

そこへコンサルタントがひょっこり入ってきて、状況を聞いた後、現在の医師の人数から、手術可能な件数を計算させてみると、あら不思議、かなり余裕がある。
コンサルタントが「医師の時間の使い方を調べて手術に使える時間を20%増やす」へ問題を置き換えると、医師も事務方も途端に積極的な意見が出始めた。

この挿話では、解けない問題を解ける問題へ変換すると、人は自然に解決する方向へ動き出す、というエピソードで括られていた。

この話をシステム開発に置き換えて考えてみる。

【1】課題解決のフレームワークは、目的→課題→アクション

プロジェクトを成功させる 現場リーダーの「技術」 」の本では、課題解決のフレームワークを「目的→課題→アクション」と言い切っていた。

実際、新規開発での要求の聞き出し、運用保守での課題管理では、このフレームワークが使える。
その時、チームのメンバーが実際に動けるレベルの課題まで落としているか、がポイントになる。

振り返ってみると、自分が所属するシステム開発のチームは、メンバーのスキルは高い。
だから、プロジェクトリーダーが課題をメンバーが作業できるレベルと範囲まで落とせば、少なくとも課題解決までもっていける。
むしろ、個々は小さくとも膨大な量の課題、手に負えないような幅広い課題を、いかに優先順位をつけて、スケジュール化していくか、というプロジェクトマネジメントの能力の方が問われている気がする。

【2】成熟した組織は、自身で問題を定義し、課題を解決する能力を持つ

組織の成熟度という話は、IT業界では、CMMIを連想させる。
CMMIでは下記の5段階が定義されている。

◆レベル1(初期段階)
 場当たり的な状態で、決まったプロセスがない
 
◆レベル2(反復可能な段階)
 初歩的管理は行われており、同じようなプロジェクトなら反復できるプロセスがある
 
◆レベル3(定義された段階)
 組織的に定義された標準プロセスがある
 
◆レベル4(管理された段階)
 プロセス・製品の精度、品質を管理し、定量的な分析が行われている状態
 
◆レベル5(最適化された段階)
 プロセス分析からのフィードバックにより、改善が継続的に行われている

「同じような問題(プロジェクト)は解く(管理する)ことができる」レベルは、CMMIレベル2と言える。
「解けない問題を解ける問題へ変換する」を「初めてのプロジェクトでも標準プロセスでコントロールできる」と置き換えるなら、CMMIレベル3と言えるのではなかろうか?

CMMIレベル4は、プロセスの計測可能な指標を組織自身が回収できていること。
つまり、プロセス改善に役立つメトリックス、即ち、プロセスを客観的に評価する基準があることを示す。
このレベルにあると、開発ポートフォリオやROIなど、開発プロセスが上手く行っているか、投資対効果があるか、などを客観的に議論できる。
これらは、ソフトウェア工学の研究対象そのもの。

CMMIレベル5になると、組織自身が自己学習できる状態にあることを示す。

CMMIファシリテーションを結びつけるとどうなるか?

ファシリテーターは、組織やメンバーの問題解決プロセスを支援するが、プロセスのコンテンツにも関わり、学習プロセスにも参加させる役割も担う。

少なくとも、CMMIレベル3以上の組織は、既にプロセスフレームワークが存在する。
そのような組織は、おそらくファシリテーターの役割を担う人は自然にいるはず。
「解けない問題を解ける問題へ変換する」能力は、チーム自身が持っているだろう。

ファシリテーションのゴールは、チーム自身が継続して学習できること、そして、メンバーが自ら問題を解ける課題まで落として、解決していく方向へもっていくことだと言える。

ザ・ファシリテーター2―理屈じゃ、誰も動かない!」では、「小学生を集めて、いくらファシリテートしても、高校生の問題は解けない。でも解きたいのは高校生の問題」というフレーズがあった。

そんなケースでは、ファシリテーションによって学習する組織へ成長させることはできるのか?

ザ・ファシリテーター2―理屈じゃ、誰も動かない!」にはその回答らしきものは書かれていたが、曖昧で納得しがたい所があった。

【3】ファシリテーションは、問題解決や課題解決の能力を高める

ザ・ファシリテーター2―理屈じゃ、誰も動かない!」では、MBAホルダーである深山が、開発ポートフォリオや要素技術マッピングなどのビジネスフレームワークを、彼が所属する研究所のテーマの評価ではなく、研究者と思考を共有化する道具として使って、より良いテーマを企画するファシリテーターに変身していた。

つまり、論理的フレームワークを使って組織の思考プロセスを見える化し共有することで、組織内の意見交換が活発になる方向へ持っていく。
この時、ファシリテーションは、他社とのインタラクティブな関係を補強することに使われている。

ファシリテーターはチームのプロセス管理者である」という意味は、組織の問題解決プロセスや学習プロセスを方向付ける人がファシリテーターであると言い直せる。


そんなことを考えると、ファシリテーションは会議術の一つだけでなく、チームを問題解決プロセスに巻き込む技術の一つと捉えた方が、その意図がよりはっきりするのではなかろうか?

| | コメント (0) | トラックバック (0)

課題管理とFRCPの法則

ザ・ファシリテーター2―理屈じゃ、誰も動かない!」の本に、FRCPの法則という概念が出てくる。

FRCPの法則とは、

機能(ファンクナリティ)F
→信頼性(リライアビリティ)R
→利便性(コンビニエンス)C
→価格(プライス)P

の順に消費者は満足する、ということ。
ザ・ファシリテーター2―理屈じゃ、誰も動かない!」では、日本の製造業が得意とするのは、R(信頼性)とC(利便性)の部分なのに、中国を意識してP(価格)で勝負しようとしているのは間違っている、という文脈で使われていた。

FRCPの法則を知って、すぐに思い浮かんだことはITシステムにおける課題管理。

課題管理は、顧客からあがった課題を分類し、優先順位をつけて、一つずつ進捗をトレースして、解決していくプロセスを指す。
例えば、新規システムを初めてカットオーバー後、顧客から山のように課題が上がってくる。
その時、課題の質をトレースすると、FRCPの法則が適用できる気がする。

つまり、下記の時系列で課題の質が変化する。

【カットオーバー直後】
予期しなかった業務フローがあったり、バグが判明したり、パフォーマンスが悪かったり、などの苦情が寄せられる。
この時の課題は、F(機能性)やR(信頼性)が多い。

特に、F(機能性)に分類された課題は、最優先課題と言える。
何故なら、機能が不足しているということは、システムがサポートする業務が滞るから。
本当はあってはならないのだが、納期に間に合わせるために、機能を削ることはままある。

また、R(信頼性)の課題は、システムの品質に関わるため、優先順位が高い。
ITシステムの品質特性は、信頼性以外にも性能や保守性などもあるが、品質が悪ければ、いつまで経ってもプロジェクトはデスマーチのままで、メンバーも疲弊する。

システム開発ではいつも、システムの品質をいかに保持するか、に悩まされる。

いずれにしても、F(機能性)とR(信頼性)の課題は最優先に解決すべきことに変わりない。

【バグも改善してシステムが落ち着く頃】

リリース前後の繁忙期を越えて、システムにマッチするように業務が回り始めると、C(利便性)の課題が寄せられてくる。
この時の課題は、苦情と言うよりも、こうしてくれると使いやすい、こうしてくれるともっとありがたいんだけど、などのような期待に近い課題になる。

顧客満足を高める観点から言えば、この種の課題を速やかに解決すると、顧客の信頼が高まる。
F(機能性)とR(信頼性)に比べると、優先順位は低いが、顧客と関係を長く保つ時は重要な課題になる。

特に、C(利便性)の課題から、次のプロジェクトにつながっていくことも多いから。

課題のステータスに、進捗やリリース日、優先順位だけでなく、FRCPの分類を入れてみてもいいかもしれない。

| | コメント (0) | トラックバック (0)

2008/01/01

ファシリテーションの成否はプロセス設計で決まる

ザ・ファシリテーター」の続編「ザ・ファシリテーター2―理屈じゃ、誰も動かない!」を読んだ。
参考になることが多かったので、感想を書いてみる。

【1】ファシリテーターとは、チームのプロセスを管理する人

続編では、リョウのビジネススクール時代の友人深山に頼まれて、深山が勤める大手電機メーカーで、リョウがファシリテーションのワークショップを開く。
その時のオープンクエスチョンで「ファシリテーターはどんな人?」という質問に対し、リョウは「ファシリテーターとは、チームのプロセスを管理する人」と答える。

この言葉は過去のPFP関西のワークショップで連想する時があった。

PFP関西でワークショップを行った後、なおまるさんが必ず各チームの状況をトレースして、第3者として客観的評価を話してくれる。
当事者は、議論とアウトプットを出すことに夢中で、プロセスの状態の変化まで眼が届かない。
だから、その評価が新鮮に感じる時があった。

また、同様のワークショップで、つちやさんが、僕のグループのタスクカードからバーンダーンチャートを書いて進捗を説明してくれた時があった。

つまり、タスクカードが、TODO(実行前)→DOING(実行中)→DONE(実行完了)の3つに区切られた模造紙に張られて、その移り変わりをバーンダーンチャートで説明してくれた。
その折れ線グラフがあまりにもジグザグだったので、あそこでは議論が収束しなかった、とか、あの時はあのアイデアがうまくいったね、みたいなふりかえりができた時があった。

ファシリテーターとは、コミュニケーション活性化だけでなく、チームのプロセスの状態を管理する役割も持っている。
だからこそ、プロジェクトリーダーはファシリテーターの役割も必要なのだ、と。

【2】ファシリテーションの目的は行動の変化

リョウは、更に「ファシリテーションの成否の2/3は、プロセス設計で決まる」とも言う。
つまり、会議や組織変革では、プロセス設計という前準備がすごく大事だということ。

このフレーズはすごく納得できる。
IT業界のプロジェクトリーダーは、開発プロセスを事前に設計しておかねばならない。
新規機能の開発プロセス、結合テスト以降の運用保守に至るまでの開発プロセスは、全く違う。
だからこそ、2個以上の開発プロセスをフェーズごとに切り替えて、チームを回していかねばならない。
例えば、新規開発はRUP、システムテスト移行はXPで回す、とか。

リョウは、また「ファシリテーションの目的は行動の変化」といも言い切る。
つまり、ファシリテーションを使って議論するだけでは意味が無い。
実際にメンバーの意識や行動に変化が起きなければならない、と。

このフレーズは、「マネージャの仕事はビフォーアフター志向」という言葉を思い出させる。
チームとメンバーが実際に変化すること、特にチームもメンバーも成長するという変化が大事なのだ。
実際、プロジェクトリーダーの評価には、メンバーへの教育やメンバーが成長したかという観点、というプロジェクト成功とは異なる評価基準も含まれることが少なくないからだ。


【3】プロセス制御の観点からファシリテーションを試してみる

ファシリテーションはコーチングと似たようなものという意識があったけれど、ビジネスの観点では「プロセスを設計する」あるいは「メンバーの行動に変化を与える」と言い直せる。
とすれば、このスキルはリーダーシップの一種とも言える。

深山の会社の研究所で起こった変化の一部が興味深かった。
彼の会社は、研究所で出した研究成果がなかなか事業につながらない。
そこには、お互いの専門分野を評価し合わないという濁った雰囲気があった。

そこで深山の上司である所長が、研究所の幹部に他事業部門の担当者という役割をつけて、クロスファンクショナルなチーム構成にした。
すると途端に、お互いの領空侵犯をするような鋭い質問から議論が白熱し、研究テーマの再構築と言う所まで話が進んでいく。

各人が事業部門の利益代表者という役割を与えられただけで、組織は活性化する時がある、と。

プロセスの設計で最初にやることは、アクターの洗い出しとアクターとプロセスの関連図、つまりユースケース図やアクティビティ図、プロセスマッピングを作ること。
そこからゴールツリーや組織体製図、SWOTなどで課題(What)を洗い出し、アクションプラン(How)まで落としていく。

このサイクルのリズムが大事なのだ、というリョウの言葉も印象に残った。

| | コメント (0) | トラックバック (0)

« 2007年12月 | トップページ | 2008年2月 »