GanttProjectは使える？

　進捗管理のために、MSProjectよりも線表を簡単に使えそうなツールを探してみたら、GanttProjectが見つかった。

　下記の特徴あり。

・ガントチャートを作成編集できるJavaアプリ
・PDF、HTML、CSV出力可能
・WebDAVを利用して情報を共有できる
・mm2ganスクリプトを使うと、FreeMindと連携できる

　プロジェクト管理者にとって、線表作成は作業の一番のネックであると思う。
　まず、線表作成は工数が結構かかる。Excelで作った場合、タスクの日付をずらすと全てのタスクの日付を修正しなくてはならない。しかも、作成中はPGは作業できないから、何とかお手軽に早く作りたい。
　更に、線表は頻繁に更新されるので、開発者に更新版を早く見て欲しい。そのために公開できる環境が必要なのだが、そこまで手が回らない。

　GanttProjectなら、手軽に作れそうだし、PDF出力すれば綺麗に印刷できそう。
　WebDAVを設定すれば、Wikiのように開発者がいつでも最新の線表を閲覧可能になりそう。

　今度試してみよう。

パンダは可愛い

　昨夜遅くに、NHK裏番組でパンダのルポを見た。
　母パンダが生後4ヶ月の子パンダを抱えている仕草が可愛いー。
　パンダは生後半年は眼も見えず、まともに歩けないので、母親の母乳だけで生きているらしい。
　しかし、母パンダが子供を放置して、半日も竹の笹を食べている行動は解せない。子供を抱きながら食べればいいだろ！と怒ってみたりする。

　しばらくして「地球大進化--全球凍結」も見た。
　マイナス50度の超氷河期が1000万年以上続いたという仮説は恐ろしすぎ。
　そんな地球で生命は絶滅しなかったのか？
　下記のように、はぶさんも感動して観ていたと、Blogで読んで、何故か安心。

昨日の灼熱世界、全海洋蒸発から一転して全球凍結のお話です。火山が出す二酸化炭素での温室効果によって、全球凍結が終わったのだそうで。ここからハイパーハリケーンを経て微生物が大型化していくくだりはかなり燃えます。正に因果という感じです。

　「因果」からSystem Thinkingの因果ループ図を連想する僕は異常だろうか？　おそらく、因果ループ図とすれば、「成功には成功を」パターンに相当するのか、と考える僕は変だろうか？

　最近、恐竜のニュースを何故かチェックしまくり。
　お金やビジネスの話よりもサイエンスの話の方が、何故か心が和らぐ気がする。

日本のIT産業は国際競争力がない

　「日本のソフトウェア産業は競争力がない」という記事を読んで、自分がいる日本のIT業界の現実を改めて思い知らされた。

　貿易収支をみれば一目瞭然なのだが、「2000年のソフトウェアに関する日本の輸出額はわずかに90億円であり、9189億円もある輸入額の１％弱しかない」。2004年でもそう変わらないだろう。　
　この事実は、日本のIT産業は海外勢と競争できるだけの財力も体力も知力も欠けていることを示している。

　中国やインドから発注されたシステムを日本で開発しているのか？
　日本で作ったソフトウェアをアメリカへ輸出しているのか？

　いずれも答えはNoで、現状は正反対。
　日本から発注されたシステムを主に中国で開発しているのが普通。
　アメリカで作られたハードとソフトを日本が輸入しまくっているのが普通。

　冷静に考えると、日本のIT業界の将来はやばそう。
　青色ダイオード発明者の中村修二さんは「今後の日本が生き残る道は、アメリカのような独創性ではなく、中国やインドのようなコストの安い製造体制でもなく、短期間に試作品を作り上げる所にある」とどこかの本で主張していたが、日本のIT業界にそのような道はまだ残されているのだろうか？

ウォーターフォール型開発は日本の業界構造と表裏一体

　「ソフトウェア開発におけるパラダイムシフト」の記事を読んで、日本でウォーターフォール型開発プロセスが幅を利かせているのは、大手SIerにとって土建業界のように階層化された業界構造が好都合な開発モデルだから、という一節にすごく納得した。

　元請から下請まで5層もの階層構造にするから、元請は上流工程と称して、要件定義しかやらない。しかし、詳細設計で初めて、仕様漏れが見つかるのが普通。結局、仕様漏れが積み重なってデスマーチ・プロジェクトに陥るのではなかろうか？
　最近は、最下層の下請は中国へ流す。だから、言語のコミュニケーションギャップも加わり、より問題が複雑になっているように思う。
　
　「アジャイル開発は元々日本的なものだ」という上記記事の主張は、なるほどと思わせる。完璧な計画を作って進めるスタイルは、どう見ても西洋式。トップダウンで物事を進めるよりも、ボトムアップのプロセスの方がはるかに日本的。
　そうならない理由は、結局、ウォーターフォール型開発プロセスが大手SIerのビジネス構造に組み込まれているからだろう。

　アジャイル開発の方が利益に直結するように、自分たちのビジネス構造を変えていかなくては。

失敗はプロジェクトマネージャーにとって経験にならない

　「プロジェクトマネージャー養成塾」のメルマガで、

「IBMでは、一度、失敗したプロジェクトマネージャーは失敗を繰り返す傾向がある」
「失敗はプロジェクトマネージャーにとって経験にならない」

というショッキングな意見が述べられている。

プロジェクトマネジメントＯＳ本舗－戦略ノート５５

　理由は、プロジェクトには不確実性があり、マニュアル通りに解決できるものではなく、プロジェクト遂行中の様々な局面の判断が重要であるから、と。
　だから、失敗したプロジェクトマネージャーは、どのような判断ややり方がまずかったのかではなく、判断や行動のベースになっているその人の「プロジェクト観」を是正する必要がある、と結論付けている。

　上記の意見はショッキングだけれど、経験上納得せざるを得ないように思う。
　現場で、プロジェクトを火だるまにさせてしまうPMはいつも同じ。例えば、いつも会議を長引かせてしまうPMは、いつになっても会議をコントロールできないように思う。（対人交渉術はそう簡単に身に付かない）
　現場で、何度も失敗するPMは、どのプロジェクトに行っても失敗する。例えば、今まで国内で開発していたプロジェクトを中国へ持って行ったが、同じように失敗。（当たり前か(^^)）

　プロジェクトの失敗経験が役立たないのは、同じプロジェクトはそもそも存在しないため、失敗に対する対策が次のプロジェクトに生かされないからだろう。
　その意味では、製造業の品質管理とは違うマネジメント能力が問われているのだろう。
　僕の勝手な思いとしては、スコープ管理がプロジェクト成功の鍵を握る気がする。
　スコープマネジメントを軸にして、リソース管理やスケジュール管理、ステークホルダーの利害調整を行うのが、プロジェクトマネジメントの王道ではなかろうか？
　スコープマネジメントには、プロジェクトの現状を客観的に把握する能力と、プロジェクトの現状を打破するだけの政治能力が必要なため、意識を高く持たないと、スキルを身に付けにくいのではなかろうか？

ユースケース図でスコープを可視化する

　「スコープを可視化する」記事で、ユースケース図はPMにとって強力なツールだと書かれている。
　以前、開発している時、ユースケース図なんて何の存在意義があるのか？と疑問を持っていたが、実際、自分がプロジェクト管理者の立場になって、初めてユースケース図の重要性を認識した。
　ユースケース図は、システムの仕様のスコープを整理するために使える。かなり有効に使えそうな予感がする。

　自分がプロジェクト管理者になって、設計者に内部仕様書を書かせているが、曖昧な要件定義から作らせているので、ユーザに外部仕様を確認して調整する場合が必ずある。
　その時、設計者に下記のように質問している自分に自然に気付いた。

未確定な仕様は、何が分かれば確定するのか？
未確定な仕様以外の部分は正しいか？
未確定な仕様の影響範囲はどれくらいか？
未確定な仕様をブラックボックスにして、作業を続けられるのか？
未確定な仕様が決まったら、工数はどれだけかかるか？

　上記の質問をしている理由は、未確定な仕様を仕様書から切り離して、設計者の作業を続行させ、その間に未確定な仕様をユーザと調整したいからだ。
　自分としては、仕様を機能単位に分割し、未確定仕様のスコープをできるだけ小さくしたい、という動機がある。
　すなわち、ユースケースを洗い出し、ユースケース図の外枠を狭めているのと同じ。

　ユースケース図の外枠がスコープに相当する。枠内には、システムで実現する機能(ユースケース)がある。だから、このユースケースはシステム内部でやるのか、あるいは、システムの外部でやるのかがハッキリする。
　上記記事でも書いてあるが、スコープを意識する時、ユースケースの詳細度はあまり関係ない。
　理由は、プロジェクトスコープはWBSのおかげではっきりしているので、ユースケースが大きすぎて工数が大きくなる場合は、スコープを基準にしてユースケースを分割できないか考えるようにしているから。

　ユースケースとスコープを意識し始めて、幾つか気になることはある。
　ユースケースの詳細度は、プロジェクト管理者と設計者で異なるように感じる。当然、設計者の方が細かい。プロジェクト管理者にとって、ユースケースとWBSはNearlyEqual。
　又、アクターが単なるユーザだけではなく、外部システム(うちならHost)が自然に出てくる。システムを実現するために、データの主体を実行者にしてしまうことがよくある。

　残りの問題は、ユースケースの種類とWBSに関係はあるか？とか、ユースケース図とスコープの関連をもっと研究してみる、とか。
　「ユースケース実践ガイド―効果的なユースケースの書き方」を最近になって、もう一度読み始めている。
　以前はさっぱり理解できなかったけれど、本の中にも「スコープ」のことが書かれている！
　後でまとめよう。

スコープを公開する重要性

　プロジェクトはスコープを管理しているだけでうまくいくのではないか？
　そのためにも、プロジェクトスコープを可視化して、チームメンバーに常時公開することが重要ではなかろうか？

　普通、プロジェクトスコープはWBSのおかげで案外はっきりしている。
　しかし、だからといって、プロジェクトがスムーズに進むとは限らない。メンバーがスコープを意識して、進捗を滞りなくこなすことへつなげなくてはならない。

　プロジェクトマネージャーは自らWBSを作るので、プロジェクトスコープの詳細まで知り尽くしているが、メンバーは線表から自分のタスクしか見ないから、自分のタスクがプロジェクト全体でどれだけのウェートを占めているのか、分かっていない場合が多い。
　だから、スコープをメンバーに公開して、メンバーが自身の現状をいつも把握できるようするのは大事。

　最近平鍋さんが「進捗管理でバーンダウンチャートが有効」と言っている。「バーンダウンチャート」とは、縦軸が完成させるべきソフトウェアの要求、横軸が時間のチャートのこと。予定と実績を書き込めば、どれだけ進捗が遅れているか一目で分かってしまう。つまり、進捗をビジュアルにマネジメントするツールのことだ。
　バーンダウンチャートを公開すれば、メンバーが自身の現状をいつも把握できる。
　でも個人的な経験では、バーンダウンチャートは嫌い。予定から実績が遅れてしまうと、マネージャーから、「いつまでに取り戻せますか？」という質問が来て、「月曜までに徹夜で仕上げます」と返事せざるを得なくなった時があった。メンバーには諸刃の剣なのかもしれない。

　スコープや進捗を公開するためのツールはあるだろうか？
　以前、XPlannerを使ったことがあったが、機能不足でイマイチだった。でも、最新版ではかなり使いやすくなっているらしい。
　他のオープンソースのツールも今度探してみよう。

ステークホルダー同士のスコープのずれ

　スコープ管理が難しい理由は、ステークホルダー同士の頭にあるスコープが大きくずれているからではないか。

　PMBOKを解説しているHPを見たら、スコープには、「成果物スコープ」と「プロジェクトスコープ」の２つがあるらしい。
　成果物スコープとは、プロジェクトの成果物を定義するもの。例えば、納品のためのプログラムや仕様書。
　プロジェクトスコープとは、成果物を作り出すために行う作業の分担を表すもの。例えば、要件定義、設計、テスト、データ移行、ユーザー教育など。

　普通は、成果物スコープからプロジェクトスコープを作っていく。つまり、WBSを作るのと同じ。
　だから、WBSがしっかりしていれば、プロジェクトスコープが曖昧になることはないはず。

　しかし、WBSが曖昧な場合もある。初めてのユーザ、初めての技術を使ってプロジェクトを始める場合、成果物に対するステークホルダーの認識が一致していても、成果物を作り出す作業が見えないため、WBSに漏れ抜けが発生することが多い気がする。すると、ユーザは、たったこれだけの成果物を作り出すのに、何故こんなに工数がかかるのか、とSIerに問い詰める事態になったりする。
　だから、ステークホルダー同士のスコープに対する思惑は、WBSがしっかりと固まるまで違いが顕在化しないと思う。

　更に、ステークホルダーが多ければ多いほど、スコープのずれが大きくなる可能性がある。そして、全てのステークホルダーが認識するスコープをすり合わせる手間もかかる。
　プロジェクトが発足した後で、ステークホルダーは増えることはあっても減ることは、現実では殆どありえないのではないか？

　XPなら、WBSを作る作業は計画ゲームに相当する。しかも、1人日で収まるタスクまで詳細化するし、チームへ顧客を巻き込んでいるから、ステークホルダーの認識のずれは小さいと言える。
　
　何故、プロジェクトでスコープ管理が大事なのか？
　理由は、スコープがステークホルダー同士の利害関係に直接依存しているからだろう。
　プロジェクトマネージャーがスコープ管理をするということは、ステークホルダー同士の利害関係を解きほぐすだけの政治能力があるという意味も含まれていると思う。
　プロジェクトマネージャーの仕事は難しい(m_m)

P.S.「スコープ管理はプロジェクト計画書から始まる」の内容と似ているよな(m_m)

インターネットは高速道路、そして大渋滞 part2

　別の記事「インターネットの普及がもたらした学習の高速道路と大渋滞」を読んで、僕がかつて生きてきた時代と現在が全く違う環境であることを再認識した。
　記事では、「この10年のITの進化とインターネットの普及によって将棋の世界の何がいちばん変わったか」という問いに対し、羽生名人の下記の話が載っている。

「将棋が強くなるための高速道路が一気に敷かれたということだと思います。でも、その高速道路を走り切ったところで大渋滞が起きています」

　つまり、「ノウハウの共有と迅速な公開」と「インターネットを介して強敵との対局機会を常に持つことができる」環境が突然できあがったことにより、状況は下記のように変わった。

「将棋の駒の動かし方すら知らない小学校高学年生が5年くらいでプロ棋士にまで駆け上がる」ということが将棋界では起きているそうなのだが、そのことは、天才・羽生善治をもってしても、
「自分たちの世代の感覚からすると、全く信じられないスピードなんです」
ということになる。

　では、大渋滞の意味を問われて、羽生名人は下記のように答えている。

「確かにそのレベルまでは一気に強くなれるのだが、そこまで到達した者たち同士の競争となると、勝ったり負けたりの状態になってしまい、そこから抜け出るのは難しい。一方、後ろからも高速道路を駆け抜けてくる連中が皆どんどん追いついてくるから、自然と大渋滞が起きる。最も効率のよい勉強の仕方、しかし同質の勉強の仕方で、皆が、高速道路をひた走ってくる。結果として、その一群は、確かに一つ前の世代の並のプロは追い抜いてしまう勢いなのだが、そうやって皆で到達したところで直面する大渋滞を抜け出すには、どうも全く別の要素が必要なようである」

　この記事には、時代とか生き方について考えさせられた。
　自分が過ごした80年代は、根性論真っ盛り。授業中に先生が生徒を殴るのは当たり前だったし、運動中（特に野球）に水分補給は厳禁だった。（今じゃ考えられない(@_@)）
　でも今では、受験勉強やスポーツのノウハウなんて、インターネットでいくらでも探せるし、掲示板やMLの対話で得られる。
　将棋だけでなく、10代の勉強も同じ状況が起きているのではないか？

　その果てが、高校生・大学生の就職難だったり、オーバードクターだったり、公認会計士試験に受かったのに就職できない合格浪人だったりする。
　いずれも、前の時代に「良い」と言われていた生き方に従った真面目な人たちが、突然、生き方のルールが変わった現状に翻弄されている印象を受ける。
　現在の生き方が変わってしまったという事実に気づかない人たち、そして古い時代の生き方に忠実な人に教わっている人たちが一番苦労しているのかもしれない。

　結局、インターネットという高速道路で取得しやすい技術や知識、資格よりも、マネジメント等のようなメタな知識が求められているのかもしれない。
　インターネットという高速道路を使って追いかけてくる人たちとの競争と大渋滞を避ける生き方は何か？が問われている気がする。

インターネットは高速道路 part1

　「インターネットは高速道路」を読んで、インターネットの環境があれば技術力を伸ばせる可能性がある事を改めて痛感した。

　その記事では、「(人の成長に影響を与えるものとしての)インターネットは、高速道路だ」という一節がある。
　例として、Perlのハッカーが、昔は力技満載のスパゲッティ・プログラムしか書けなかったのに、インターネット上にある優れたソースコードを参考にしてどんどんプログラミング・スキルを伸ばしていったという話が載っている。
　他方、20年間のキャリアを持ったあるベテランプログラマがC言語で書いた最近のソースは、20年のキャリアを感じさせない力技ごり押しのソースコードだったという。
　記事では、二つの例を下記のようにまとめている。

片や数年で誰もが参考にするコードを書くハッカーに育ったかと思えば、20年経っても当時のままというプログラマもいる、彼らの決定的な違いは何だろう?
個人のセンス、能力?
いえ、それは成長の過程のなかにインターネットというメディアが存在していたか否かが決定的なのでした。

　プログラマにとって、プログラムを書くのと同じくらい、プログラムを読むことは大事だと特に最近思う。
　Javaの場合、フレームワークやライブラリを駆使したサンプルソースがいくらでもあるし、デザインパターンやリファクタリングでソースの構造を見通しよくする技術紹介がインターネット上にいくらでもある。DIコンテナやアスペクト指向等の最新の技術動向にもすぐに触れられる。
　だから、Javaプログラマは若い人ほど成長するスピードが速いように感じる。インターネットさえあれば、10年前のJava黎明期からやっている人と対等に話せるレベルまで駆け足で登り詰めることはできるから。

　でもC#やCの場合はどうなのだろう？Web系ではなく組み込み系はどうなのだろう？
　Java/PHP/Perl等のWeb系システムは、安いハードにオープンソースのフレームワークを組み合わせる技術力さえ磨けば、誰でも実現できる。でも、組み込み系の場合、高価なハード（例：大企業の家電製品）と密接に絡んでいると、いくら書いても動作確認できない。Javaよりも状況が異なるのかもしれない。

　IT業界に入ってJava一筋だけど、技術はまだまだ面白い。

Aspect思考

　「asatoの技術的な内容の日記」はAspect指向のBlog。内容がすごく興味深い。

　「アスペクト思考」の記事では下記の記述がある。

特定の機能（上の例では、時間の測定）の存在を意識しなくてもすむ、というのは、プログラムの理解の点からは、やや優しさを感じる。
つまり、特定のアスペクトを使って機能を分離することにより、プログラミングする上での思考の軽減になると感じている。
これは、オブジェクト指向（思考）での、ポリモーフィズムなどにも通じる現象かもしれない。
ある部分を気にせずにすることにより、コードを読む上での精神的な負担が減ると思う。この負担の削減は、思っていたよりも、効果的に感じる。

　システム保守のフェーズでAspectを導入するのはリスクが大きいのではないか、という考えから離れられなかったが、ポリモルフィズムのようにAspectを使うことで「コードを読む上での精神的な負担が減る」という意見は深く考えさせられる。
　今の軽量コンテナや脱EJBのように、普通のPOJOをAPサーバーでロードしたら勝手にトランザクション管理やログ出力の機能が追加されるような仕掛けを作りたいという流れがある。その流れに進むと、今までのプログラミング構造の考え方と違うやり方が出てくる気がする。
　実際、「asatoの技術的な内容の日記」に出てくるサンプルソースを読むと、オブジェクト思考とは違うように思う。

　「Aspect思考」は今後も要チェック！

体制上のレイヤーが多いと開発は失敗しやすい

　PM見習いの読書日記にこんな記事が書かれていた。

上記に関連して最近強く思うのは、開発のときに体制上のレイヤーが多いと開発は失敗するだろうということ。やっぱりレイヤーが多いと、身動きは遅くなるし、情報はどんどん欠落していくし、責任はあいまいになっていくし。「ユーザ」と「開発者」だけがいればいいと思う。

　自分の経験と合致する部分が多い。
　IT業界っていくら格好よく言っても、土建業界と同じゼネコン体質で、建築プロセスよりもはるかにプロセスの完成度は低いし、プロジェクト管理のスキルも低い。
　レイヤーが多いと無駄なドキュメントが多くなる。外注を使うと、彼らとコミュニケーションを取り、管理するコストが余分に増える。そもそも、同じチームの開発者を管理できないのに、海を隔てた中国の開発者を管理できるのか？

仕様の決定を遅らせる

　PM見習いの読書日記にこんな記事が書かれていた。

仕様の決定を出来る限りディレイさせよう、というのと、スコープを定義しない、というのは別だと思う。

　「リーンソフトウエア開発～アジャイル開発を実践する22の方法～」でも同じ言い回しが載っている。
　要件定義から仕様を制御しようとすると、必ず確定できない仕様が出てくる。スコープを定めようとしても、スコープ内に入れられない仕様が必ず出てくる。だから、区別して優先順位を付けるのが大事なのだろう。

　自分の少ない開発経験では、確定できない仕様は、テストケース漏れや設計漏れから出てくる時が多い。
　例えば、新たな機能追加で今までとは異なる画面遷移や制御ロジックが付け加わるとか、実は他のサブシステム(特にHOST！)とデータ連携していたとか、設計時には分からず、テストやレビューで判明する時が多い。
　だから、仕様はこうだ！と勝手に決めて進めてしまうと、後で途方もない手戻り作業が待ち受けている。
　
　アジャイルプロセスから学ぶべきノウハウはまだまだ多い気がする。

ペルソナ/シナリオ法はサービス洗い出しに使える

　とある勉強会で「ペルソナ/シナリオ法」を使って、あるビジネスのサービスとユースケースの洗い出しをやってみたら、議論が弾んで面白かった。かなり使えそう感触。

　「ペルソナ/シナリオ法」は、ペルソナという仮想ユーザーからシナリオを作ってみるという手法。元々ソフトウェアの「ユーザビリティ」のお話で良く出てくる。例えば、パソコン初心者とか、オペレーターとか、プログラマ等の仮想ユーザからアプリケーションの使い勝手を検証するのに使うらしい。
　下記記事が詳しい。

ユーザビリティの時代──ペルソナ／シナリオ法 理論編

　ペルソナを規定するコツは具体的な人をイメージするのがいいらしい。年齢・性別・年収だけでなく、性格まで決めた方が、行動特性が出てくるので、シナリオの信憑性が高まるから。だから、名前まで付けてしまう方がイメージしやすい。
　シナリオは、ペルソナがどのように行動するかという物語そのもの。RPGのキャラクターの行動に似ている。

　とある勉強会では、3人のペルソナを出してみた。
　一人目は27歳の独身男性サラリーマン。このペルソナは世の中にいくらでもいるので簡単。
　二人目は45歳の既婚男性の外資系証券部長。マスコミに出てくるイメージそのままに「自分で仕切りたがる」「自信過剰で説教口調が多い」と提案したら、紋切りすぎと皆から突っ込まれた(^^)
　三人目は23歳の独身女性で保育園教諭。インターネットに出てくるイメージそのままに「ショッピングが好き」「ファッションにお金をかける」「可愛い物が好き」等と提案したら、あまりにもステレオタイプだと皆から突っ込まれた(^^)
　ここまでペルソナの性格が定まると行動にも特徴が出てくるので、あるビジネスサービスを各ペルソナがどこでお金を使うのか、というシナリオがくっきりと出てくる。
　上記記事にもアドバイスが載っているが、2人以上でペルソナとシナリオを作っていく方が色んなアイデアが出てきやすい。実際、勉強会でも思わぬシナリオが出てきて、ペルソナが違うとここまでサービスが違うのか、と考えさせられた。RPGをやってるみたいで議論も白熱して楽しいしね。

　感想としては、新規ビジネスモデルを構築する時、トップダウン式にユースケースと概念モデルを作っていくと、それらのモデルが果たして現実に即しているのか、という不安があるけれど、「ペルソナ/シナリオ法」を使えば、特定の顧客層に対してはこのサービスが有効だからこのモデルが必要、と言える。
　もう少し、利点と弱点をはっきりさせてみたい気がする。

　但し、人をステレオタイプに見るのは女の子から嫌われるから気をつけなくては(^^)

弱い絆が価値観を増大させるという事実

　「弱い絆が価値観を増大させるという事実」という記事を読んで、今自分が感じていることと一致していることに共感した。
　記事に下記の一節がある。

「社会的絆によって形成される社会ネットワークにおいては、古くからの友人といった、自分にとって強い絆で結ばれている人物よりも、ちょっとした知り合いのような弱い絆で結ばれた人物のほうが、自分に与える影響が大きい」というものです。

　関西にいるので、IT業界有志の勉強会は東京よりも格段に少ないけれど、あちこち顔を出すうちに、彼らの仕事ぶりや価値観に刺激を受けて、自分が少しずつ変化しているのが分かる。
　仕事が終わった平日の夜や週末の昼から夜の宴会まで、議論してお互いの価値観をぶつけ合うのが好きな人たちは、一般人よりもはるかに向上心が高い。週末なんて彼女とデートや友達と遊ぶのが普通なのに、プライベートよりも勉強会を優先している人も多い。

　但し、関西の勉強会に参加して感じることは、「20代前半と30代前半の人が多く、20代後半の人が少ない」「メーカーや中小ソフトハウスのSEやPMが多く、大手SIerは少ない」という事実。
　20代前半の人は経験は乏しいけど、すごくアグレッシブ。30代の僕よりもはるかに潜在力を感じる。30代の人は、一通りの仕事を覚えた後現実に何か疑問を感じている人が多い。彼らの経験談は非常に刺激的。
　なのに20代後半というキャリアが最も充実した世代がオープンな勉強会に顔を出さないのは何故だろう？

　メーカー出身のSEやPMは勉強会の運営が上手い。勉強会のお題目を作り、議論となる資料をPowerPointで作り、発表会で成果を公開するプロセスをきちんと制御している。彼らは生産管理を勉強しているのだろうから、勉強会のようなオープンなチームでもマネジメントが上手いと思う。勉強会を運営し続けるのは、アジャイル開発に似ている部分がある気がする。メンバーの士気を高めて、メンバーに能力相応の役割を分担し、成果をまとめ上げるには、CMMのような管理プロセスよりも、アジャイルプロセスの方がふさわしい。
　僕のような中小ソフトハウスSEは知的好奇心に飢えている。彼らはプログラミング技術は優れているが、プロジェクト管理やモデリングのスキルは不足している。だから、メーカーSEやPMと議論し合うのはすごく刺激的。
　なのに、大手SIerのSEは殆ど見かけない。彼らは一体何をしているのだろう？

　12月は時間が空く限り、全ての忘年会に出るつもり(^^)