プロマネに必要な技術とは？

　　以前読んでいた興味深い記事 ｢プロマネの鍵、貸します」 「プロマネに必要な三要素」を掘り出した。
　この記事の内容がようやく腑に落ちるレベルまで辿り着いたので、自分の数少ない経験を交えながら、プロマネに必要とされる技術について考察してみる。

【１】経験から得たリスク感覚～リスク管理

　管理職で働く人は、必ずリスク管理のスキルを持っている。必要条件といっていい。
　リーダーと呼ばれる人は、チームメンバーを見て、お客さんを見て、スケジュールを見て、コストを見て、リスクを嗅ぎ取るのがうまい。
　
　ＩＴ業界はリスク管理が甘いように思う。
　どのプロジェクトでも、初めての技術、初めての業務をシステム化する時がすごく多い。

　再利用できるライブラリやフレームワークがなく、いつも最初からスクラッチで作り始める。
　同じ業界の業務経験があっても会社が違えば業務は大きく異なるのが普通だから、いつも最初から要件のヒアリングから始める。
　いつも初めての技術を試したり、初めての会社の業務をシステム化するから、必ずどこかで問題が噴出し、スケジュールが遅延化し、状況をコントロールできなくなる。
　だから、計画段階やプロジェクト実行中にリスクをすぐに嗅ぎ取る能力があるかどうかは、プロジェクト成功に直結する。

　リスク分析は、リスクバリュー分析という手法が多分有名。
　リスクバリュー分析から眺めると、リスク管理とは、大問題が噴出さないように予防対策を立てて未然に防ぐことと、頻発する些細な問題は発生した時点で対処することの2種類になる。

　優秀なプロマネは、運用ルールを作るのが上手い。
　つまり、予防対策や発生時対策の手順を文書化してメンバーに浸透させて、チーム運営の中に埋め込む。
　開発現場で使われる運用ルールとして下記を使った経験がある。

・コーディングルールやソースインスペクションの観点をルール化したもの
・ＣＶＳへＣＩする手順（コメントに変更理由を書く、要件管理番号やバグ修正管理番号を書く）
・お客様や他チームからの問い合わせ内容を履歴として集めて、回答集を公開する
・ビルド作業
・リリース作業

　運用ルールが煩雑になると逆にメンバーの進捗が遅れてしまうけれど、若いメンバーや初めてのメンバーの作業品質を高めるのに非常に役立つ。
　作業品質はシステムの品質、作業進捗に直結するから。

【２】固有技術への理解～システムの仕様や技術を把握しきれるだけのスキルがあるか？

　お客様の方が自分の会社の業務に詳しいだろうが、システム屋はその業務をITシステムという物理的・論理的なモデルに落とし込むことが出来るか、という技術力が必要とされるし、期待されている。
　でも、実際は、SIerは技術レベルそのものが低いように思う。
　
　仕様面では、業務フローを矛盾なくＤＢ設計しきれるか。
　ポイントは、業務データがどの時点で作られて、更新されて、消えるか、というデータのCRUDに着目しながら、ＤＢ設計するのが鍵のように思う。
　その発想はオブジェクト指向設計と似ているし、日本では、オブジェクト指向設計をやっている人は過去にＤＯＡの経験があることが非常に多い。
　モデリング技術を持っているかどうかが、仕様化できるかを左右する。
　
　技術面では、いつも初めてのフレームワーク、初めてのライブラリを使う時がすごく多い。
　Webシステム構築の場合、WebフレームワークとDAOのフレームワークをどこまで自分の技術として身につけているか、が技術力を左右する。
　そこでいつも思うのが、再利用と品質をコントロールできていないこと。
　
　再利用できるモジュールやライブラリがあれば、少ないコストで品質が保証された機能を実現できる。
　だから、ソースインスペクションする場合、コンセントの抜き差しで簡単に変えられるように、複雑なロジックをレイヤー化して分割しているか、という観点で厳しくチェックしておく。
　そうすれば、仕様変更にすぐに対応できるし、状況の変化というリスクを引き受ける余裕が出てくる。

　僕がまだ理解しきれない感覚は「品質はプロセスで作りこむ」「品質はプロセスに宿る」ということ。
　プロセスと品質は密接に関係しているが、その関係性は具体的に何なのか？
　まだ分からない。

【３】管理技術～可視化すること

　「プロマネに必要な三要素」の記事では、「管理とは自分以外の他者の仕事内容・成果物を正確に把握すること」「可視化する技術が管理技術」と言い切っている。
　XPやプロジェクトファシリテーションでは管理技術を意識化させて、色んなツールで「見える化」するのが上手い。

　「見える化」の目的は、下記の2種類があるように思う。
　一つは、トレースしたいこと。
　ある要件からどんな機能が出てきて、どのプログラムで実装されたのか。
　テストで判明したバグは、いつ修正されて、いつ検証されて、解決されたのか。

　もう一つは、成果物を受け渡しながらプロセスを連鎖させること。
　中間成果物を受け渡ししながら、プロセスのInputとOutputを決めて、つなげていって、最後は、要件からシステムが作り出される。
　そのプロセス連鎖を確実に具現化しきれるか。

　いつも思うのが、進捗スケジュールは作成するコストの割りに、使われないことが多い。
　作ったスケジュールはすぐに実態とずれて、2週間後には全く使い物にならなくなる。
　
　その原因は、日本のシステム開発が、要員ありきから始まっているからだと思う。
　タスクを洗い出し、作ったスケジュールに合わせて要員をアサインするのではなく、限られた予算で限られた要員をやり繰りする。
　何かおかしい。

【４】3要素のスキルが一定レベル以上であることが必要条件

　そして、プロマネには上記の3要素とも一定レベル以上を要求される。
　リソース管理のできないマネージャは、的確な指示や命令が出来ていない人。
　リスク管理できないマネージャは、いつも行き当たりばったり。
　技術力のないマネージャは、進捗スケジュールを書くだけで、メンバーをサポートすら出来ない。

　そんなことを考えると、プロマネのハードルは高い。
　プロマネになる人は、どのようにして育成されて完成されるのだろうか？

　鍵は、プログラミング力やモデリング力にあるように直感する。
　リスク管理、技術力、管理技術はいずれも、現状を全て論理的整合性を保ちながら一つのモデルに落とせるかどうかにかかっているように思う。

【Rails関西】軽量の人は繊細な人を兼ねる～JavaからRubyへ

　今日のRails関西に行ってきた。
　artonさんという大物有名人の講演も聞けて、ワクワクする勉強会だった。
　その感想を書いてみる。

【１】Javaはクールな言語だった

　artonさんは「Javaも好きです」と言っていた。
　Javaは元々こんな特徴があって、10年前はクールな言語と言われていた。
　つまり、Javaはインターネットを意識した初めてのプログラミング言語だった。

・仮想マシン(JVM)の上で動く
・バイトコードで読める
・ガベージコレクションがある
・移動コード(セキュリティ機構)を持つ
　つまり、リモートホストからローカルホストへ転送され実行される機構を持つ

【２】Javaは現代のCobol～業務アプリは繊細な作り

　でも、実際の現場では、Javaで業務アプリを作っても、やっぱり業務アプリは壊れやすい。
　そして、広範囲に膨大に使われて、Javaが全てを解決したとはとても言えない現状がある。
　最近は、軽量の言語の方がいいのでは、という傾向もある。

・業務アプリケーションに最も使われている
・型があるから安全でしょう(本当？)
・コンパイルするからバグが見つかる(本当？)
・Eclipseという統合開発環境があるから初心者でも簡単
・オブジェクト指向言語だが、今時そうでないプログラミング言語を見つけるのが難しい
・private、interfaceなどの言語仕様があるけれど、今はどの言語でも持っている

【３】それでもJavaには利点がある

　にもかかわらず、Javaにはうまい仕掛けがある。
　これらをうまく使えば、何かできないか？

・Reflection
・Annotation
・Bytecode Modification
・Java Native Interface

【４】軽量の人は繊細な人を兼ねる～軽量なRubyが繊細な業務アプリへ進出してきた

　「軽量の人は繊細な人を兼ねる」という言葉をartonさんから初めて聞き、心揺り動かされた。
　つまり、「軽量なRubyが繊細な業務アプリへ進出してきた」ということ。

　実際、一部のSIerが、WebアプリをJavaからRubyへシフトしつつある。
　このあたりの事情は、倉貫さん(XPユーザーグループ代表)のBlog『JavaからRubyへ―マネージャのための実践移行ガイド』でも取り上げられている。
　この傾向の意味は、RubyがITビジネスとして使えるという安心感を示している。

【５】だからRjb(Ruby Java Bridge)

　そこで、RubyからJavaライブラリを再利用するするために、Rjb(Ruby Java Bridge)を作ったとの事。
　Javaのライブラリはそこら中に転がっているのだから、そのライブラリを再利用すればいいじゃないか、と。
　この発想は、PerlのPluggerをRubyからコールして再利用しようという以前の講演のモチベーションと全く同じ。
　
　その仕掛けの詳細はサンプルデモなどを読んでもらえればいいが、講演では、スレッドやスタック回りの開発部分の話がすごく面白かったけれど、時間切れで、もう少し聞きたかった。

【６】時代はJavaからRubyへ？（.NETじゃないよ）

　artonさんは、何もRailsじゃなくてもASP.NETだって同じようにすぐに出来るよ、とサンプルデモを講演してくれた。
　色んな言語での比較は面白い。
　
　僕の少ない業界経験では、MS系のツール(Visual Studio)をフルに使いこなす技術者の生産性はJavaよりも高い。

　にも関わらず、やっぱりJavaは面白い。
　理由は、.NET系は自動生成したソースコードを解析するのはブラックボックスを触るような感覚で非常に難しいが、Javaなら自分で最初から組まないと動かないので、機構がすごく良く分かる。
　同じように、RubyOnRailsも、ソースを最初から最後まで追いかけられるので、機構がすごく良く分かる。

　元々、オブジェクト指向という発想はネットワークと相性がいい。
　サーバーはオブジェクトに似ている。
　だからインターネットを意識した言語、あるいはインターネットのキラーアプリが時代を変えるのだろうと思う。
　
　そんな講演を聞きながら、そして一部のSIerがRubyで実際にシステム構築していく事例を見聞きすると、今と言う時代の技術が変化しつつあるのを感じる。

朝会を実践してみて

　朝会をチームでやることになり、下記のＨＰを参考にした。

・朝会のパターン：立ってるだけじゃないよ

・プロジェクトファシリテーション実践編：朝会ガイド

　そこで自分なりにアレンジしてみて、下記のルールで朝会をやってみた。

１・話す内容は、昨日やったタスク、今日やるタスク、最後に一言(抱負、連絡事項)の３つだけ。
２・一人が話す持ち時間は3分以内。
３・全員で立ったまま話す。

　そして1ヶ月間、朝会をチームで実践してみて、新しい発見が結構あった。
　その体験から「朝会の目的はそもそも何だろう？」という思いが上がってきた。
　そこで、朝会について再考察してみる。

【１】自らの役割を自覚する～コミットメントの共有

　過去の経験からして、失敗プロジェクトでは各メンバーの役割が曖昧で、誰が何をしているか、今の自分の仕事がプロジェクトのどのプロセスに相当しているか、を開発者だけでなく、リーダー自身も知らないことが多い。
　そんなチームは、無気力の塊のようなメンバーばかりになっている。

　だから、僕は、朝会のそもそもの目的は「1日の初めに各自の仕事と役割を確認すること」だと思っている。
　特に、今日の自分の仕事を皆に告知させることで、自分がその仕事をコミットする、という意識付けを行わせるようにした。

　そうなると、朝会は自然に進捗ＭＴの一つになる。
　僕はそれでいいと思っている。

　又メンバーは、朝会で、他メンバーの仕事やその進捗も意外とよく聞いている。
　チームにいる開発者に、朝会の感想を聞いたら、こんな答えが来た。

「毎朝、同じ実績を報告していたら、自分一人だけが進んでいないように思えて恥ずかしくなる。だから、必ず1日で何らかの実績を残して、少しでも進んでいると発表できるようにしようとしました」

「他の人の話を聞いて、他の人が今何をしてるのか、よく分かるようになりました」

「だから、忙しい人の力になろう、とか、今日は先にこれをやろう、とか思うようになりました」

　朝会は、他の業界では普通にやっている事が多い。
　例えば、高校の先生ならば、朝会で生活指導や行事のスケジュールを再確認している。
　営業マンならば、朝会で、このお客さんには誰がカバーリングするか、とか、横の繋がりが頻繁にある。

　なのに、ＩＴ業界は、メンバー同士のコミュニケーションが存在すらしない職場が多く、風通しがすごく悪い。
　隣の人が何をしているか、を全く知らずに仕事する時が多い。
　そうなると、その人だけでなく、チームや部全体、会社全体の雰囲気もどんよりと重くなってしまう。

　朝会のもう一つの隠れた目的は、コミュニケーションの活性化もある。

【２】隠れ作業をなくす～問題やリスクを嗅ぎ取る

　プロジェクトリーダーとしては、朝会でメンバーの現状を知ることも朝会の目的の一つになっている。
　特に気になるのが、割り込みの作業や隠れ作業をしているメンバー。

　本来はプロジェクトリーダーが作ったスケジュール通りにメンバーは仕事をこなせばいいが、実際は、他チームの問い合わせにヘルプ対応したり、お客から突然の問い合わせでトラブル対応して、実績が出せないメンバーがいる。
　そのようなメンバーは、丁度、野球やサッカーのユーティリティプレーヤーのように、システムのクリティカルな部分を知っていたり、開発環境のセットアップや運用に強い人が多く、チームにとっても不可欠な存在な人が多い。
　結果として、そのメンバーの実績が滞ると、チーム全体の進捗もはかどらなくなる。

　だからこそ、プロジェクトリーダーは、その人の負荷を減らすように、他メンバーに作業を分散させたり、他チームやお客と交渉して、割り込みの依頼が来る場合はリーダー経由で連絡させるなどの処置をすることが多い。

　大体、隠れ作業をやっている人がいると、そこから問題が噴き出す。
　何故なら、隠れ作業とは実は、システムで最も難しい部分を開発していたり、色んなモジュールを組み合わせて試さないと開発できない部分だったりするので、早めに対処しないと、制御できなくなってしまう。

　問題やリスクを嗅ぎ取ることも朝会の目的の一つになる。

【３】目標はチームの自己組織化～ハッピーサインアップ

　朝会でチームの風通しは良くなってきているが、本来の理想である「自己組織化」まで至っていない。
　メンバー全員がスケジュールを意識して、各プロセスの役割を把握して、融通し合えること。
　つまり、自ら手を挙げて役割を引き受けて、アウトプットを出すこと。

　こんなアサインをXP(eXtreme programming)では、ハッピーサインアップと言っていた。
　
　理想は、チームの各メンバーがObjectになって、自分自身の役割とＨｏｗは知っており、各Object間でメッセージパッシングし合いながら、チームが有機的な構成体になること。
　そもそも人間は部品ではなく、生物（なまもの）。
　本来は人間は皆Objectのはず。

　いつか試したいことは「円陣を組む」こと。
　高校野球でやっているけれど、ああいう青春臭いことをやってみたい。
　円陣を組んで一体感を醸し出し、皆でカバーリングし合えたらいいな、と。
　人間の集団で規律を保つには、ルール以外にも、儀式が必要な気がしている。

　朝会のレベルを上げるために、まだ他の有用なツールがあるように思える。
　色々試してみたい。

Ruby関西と仏大統領選

　4/28に開かれたRuby関西へ行ってきた。
　詳細なログは、本家サイトを参照して下さい。
　楽しかったことをメモ。

【１】Ruby関西フランス支部と実況生中継＼(^o^)／

　フランスに移住(？)したかずひこさんへ、WebカメラやSkype(?)を使いながら、Ruby関西の勉強会の講演をやり取りした。
　かずひこさんの音声はリアルタイムにはっきり聞き取れたし、最後の10分間、プロジェクタのスクリーンにちょっとぼやけた動画でかずひこさんが映った。
　最近の技術はすごいね～。

　かずひこさんも講演を聞いた後に質問したり、コメントしたりしながら、
「フランスから、微妙に寂しさを感じながら講演を聞いてます」
という発言があって面白かった。

　コウザイさんからは
「音声だけですけど、皆質問しているのが聞こえて、お家にいながらＲｕｂｙ勉強会にいる感じです」
「お茶の間留学みたいです～」
の発言があり、聴衆皆で大笑い(^_^;)

　準備されたスタッフの皆さん、また朝5時からスタンバイしたかずひこさん、コウザイさん、お疲れ様でした。

【２】仏大統領選とRubyの関係

　かずひこさんから、フランスの近況の話があり興味深かった。
　丁度今、フランスは大統領選の真っ只中。
　そんな中、フランスのオープンソース団体が大統領候補へオープンソースの力になってくれるか、質問状を送ったらしい。
　返ってきた反応は、殆どの候補がオープンソースに好意的だったらしい。
　しかし、最有力候補であるサルコジさんは、「私はオープンソースの人が期待している答えは出せない」という返事が返ってきたとのこと。
　かずひこさんによると、サルコジさんは「金持ちLove(ハートマーク)」な人だそうで、移民な私はどうなるんだろうかと思います、と言っていた。

　こんな所で、ITと政治が絡んでいるとはね。
　日本だったら、どうだろう？
　日本はRuby発祥の地だから、政治的に応援されやすいだろうが、実際はそこまで国や地方の支援がないのが実情なのかもしれない。

　コミュニティに関わっている者としては、公共団体の援助は当てにせず、コミュニティに集まった人たちだけで、自由な雰囲気をつくり、しかも社会へ刺激を与えられるように、プログラマ自身が力を身に付ける方が大切だと思っている。