現在すでに1.9億ページビュー/月を持つダイアリーサービスを中心に、順調に成長を続けるはてなの代表取締役、近藤淳也氏によるセッションです。すでにはてなを知っているという出席者が95%を超える中、「はてな」というコミュニティの概要と、コミュニティを醸成し熟成させるためにはてなが行ってきて、そして今も行っているさまざまな取り組みが紹介されました。

近藤氏が三重県の出身ということで、三重県四日市市との比較というユニークな視点で、はてなコミュニティと、コミュニティを運営する立場としてのスタッフの苦労や失敗談が率直に語られました。はてなの登録ユーザー数は現在およそ20万人、四日市市の人口は現在およそ30万人で、スタッフ（市職員とはてな株式会社）1人あたりの人口は四日市市では100人だが、はてなでは2万8,000人にのぼること（差がありすぎる！）、コミュニティの参加者（市民とはてなユーザー）の滞在時間を考慮すると、はてなのスタッフは大体四日市市職員の3倍程度の働きを必要とすることなど、急速なコミュニティの大規模化を感覚的に理解した上で、話はいかにコミュニティとはてなスタッフが助け合って、はてなコミュニティを維持発展させていくかという、コミュニティ・ビルディングの肝に進んでいきました。

今回のセッションでは、違反行為、新機能要望、不具合対策の3点で、コミュニティとはてなが行ってきた試行錯誤が解説されました。はてなが成長してきた過程で、当初は近藤氏を初めスタッフがコミュニティの動向をすべて把握できていた（そしてその作業だけに頼って運営されていた）時期から、やがて物理的にスタッフだけでは追いつけない量の違反行為（とその指摘）、即座に対処できない量の新機能要望、専門性があがり、すぐには見つけられない、対処できない不具合などが押し寄せてくる時期へとフェーズが進んだそうです。

トップダウンで、はてな単独で対処できないことが認識されたとき、コミュニティをさらに発展させる方法としてはてながとった戦略は、一言でいえば「オープンであること」に尽きるでしょう。はてなからコミュニティへというベクトルにおいて徹底的にオープンであることで、ときには相反する思惑を持って行動するコミュニティの参加者それぞれが、最低限共有できる基盤を提供する、つまり民主主義であること、それがはてなのコミュニティが支持される理由なのだと実感しました。であればこそ、コミュニティからはてなへというベクトルでさまざまな有形無形の支援が受けられるのでしょう。WWW上で提供されているサービスの多くが、大企業によるトップダウン的アプローチで提供される不要で押し付けがましい機能であふれている現状では、はてなが提供するサービスに多くのユーザーが集まってくるの当然のことなのです。

オープンであることは、「あしかシステム（はてなの社内プロジェクト管理システム）」やミーティング後のアンケート、そして社内ブログやWikiなどを通して、はてな社内にも浸透しているようです。はてなのオープンマインドは、決して事が起きてから後付けで設けられた規範ではなく、はてなというコミュニティとはてな株式会社が生まれながらにして持つDNAに組み込まれた情報であるようです。そして、そのような遺伝情報を持たないその他大勢のサービスプロバイダでは、資本以外の力ではてなに対抗することはどんどん難しくなっていくとすら思えました。

誰かの話を1時間も聞くと、聞き終わった後は飽きているか、または課題山積みになって押しつぶされているかのどちらかであることが多いのですが、今回は、聞き終わって何か爽快感のようなものが残るセッションでした。

1月の下旬に翔泳社から「Developers Summit」の案内が届いた。早速、サイトにアクセスしてみたところ魅力的な講座が盛りだくさんで、さらに無料であることから参加申し込みをすることに。

どの講座に申し込むか迷ったが、スケジュールとの兼ね合いもあり、２月３日午前中の「成功への動機づけに欠かせないプロジェクトマネジメント」（冨永章氏）と「ITSS時代のプロジェクト人材戦略」（加藤直樹氏）を選んだ。

冨永氏の講座を選んだのは、PMコミュニティ（JPMF）においてボランティア活動をしている私にとって、プロジェクトマネジメントの世界で著名な冨永氏の講座を直に聞いてみたいと思ったからである。

150名は入ると思われる会場は、ほぼ満席盛況であった。冨永氏の講座は、プロジェクトマネジメントの基本を改めて再認識する講座として有意義であった。また、ＥＶＭ（アーンドバリュー）に対する「やってみれば、思ったほど大変ではない」というコメントには力を得た。そして、まずプロジェクトマネジメントは個人レベルで実践してみるべきだという意見と、冨永氏が実践された具体例（ロボット製作）に感心した。

続いて聴講した加藤氏の講座を選択したのは、勤務先でITSSを活用した人事システムを導入を担当している私にとって有益な情報が得られるのではないかという期待からである。

「プロジェクトマネージャはスーパーマンであることを求められており、それが失敗に一因になっている。今後はチーム全体としてサポートする体制が必要であり、その育成や評価にITSSが活用できるのでないか」という加藤氏の意見は、大変参考になった。

今後もこのような有益なセミナーが継続的に開催されることを願うものである。

【はじめに】
受講に臨んでは「天下の」ITアーキテクト、榊原氏の崇高な講演を聞いて明日からの仕事の活力に！という個人的な思いを持っていた。演壇の榊原氏はカジュアルな服装（ちょっと意外）で、滑り出しはやや緊張気味なように見受けられた。冒頭「翔泳社さんから、ご自身をさらけ出してくださいと言われて…」と仰って、自分ネタで笑いをとりながらの講演。気付けばあっという間に時間だった。決して肩肘張ったような、あるいは学術的な話ではなかったが、深遠な知識を少し垣間見ることができたような印象深い講演だった。

【ITアーキテクトとアーキテクチャ】
ITアーキテクトの仕事について（5名！のアンケートを踏まえて）「もちろんアーキテクチャを作る人」と解説された上で「開発リーダーを務めることも多いしPM的な仕事もそりゃあ。モデリングも当然します。スゴイ技術が必要になることはあまりないけど。アーキテクチャを作らなければアーキテクトじゃないでしょう」と解説された。以前何かで、ITアーキテトとPMやITスペシャリストとの違いは、その知識領域が広く深いということだ、と読んだのを思い出した。更にITスキル標準を図示されての「To Beモデルを構築し、ソリューションの枠組みを決め、ITのアーキテクチャに落とし込む」という「橋渡し」論が、ITアーキテクトのミッションをよく言い表しているように思う。

そのアーキテクチャについては、まずは「私のエンジニア人生」と題して（恋の遍歴？を交えて）語っていただき、技術者エンジニア冥利に尽きるというリポジトリ開発で、「アーキテクチャ = 構造の定義なんだ」と気付かれたとのこと。また、IEEE Std.1471-2000からは organization, components, principles をキーワードとしてピックアップされ「分け方とつなぎ方」→「全体をどう切り分け、部分をどのように関係づけるか」ということだと定義された。

【ファンクショナル・アスペクトとオペレーショナル・アスペクト】
最近、講演や雑誌等で、ソフトウェア要求について機能要求（Functional Requirements）と非機能要求（Non-Functional Requirements）の側面から整理しているのを目にするが、榊原氏はこれを一歩進めた「要求を満たすためのアーキテクチャの側面」まで解説された。一つはFunctional Aspect（機能的側面）としてのコンポーネントベースでの分析・設計、もう一つはOperational Aspect（運用基盤的側面）としてインフラ設計の抽象化であるが、後者については、ロケーションやゾーンなど現在のUMLにない要素が必要であると指摘された。また、モデルの表現の必要性については、マンハッタン島の地図によって、目的ごとに抽象表現の方法が異なることをわかりやすく説明された。

【アーキテクチャ設計−非機能要求の実現の考慮】
ファンクショナルとオペレーショナルの接点として、コンポーネントをどのノード（ロケーション）にどのように配置するかについては、システム・トポロジーへの配置のマッピングを、ユースケースの検証については、システム・トポロジーへのシナリオのマッピングを提起された。これらについては、具体的にオペレーショナル・アスペクトのためのモデル表記例、オペレーショナル・アスペクトにおける動的検証モデルを示されて、インフラの方でも、概念モデル、詳細モデル、物理モデルと段階的に詳細化されてゆくべきだと解説された。（この辺りで頭が真っ白になってきたが、キャパシティ・プランのミスとしてクレーン車転倒写真が！　絶妙のタイミングで救われました。）

次に非機能要求（Non-Functional Requirements）の特性毎に「関心事を切り出す」ビューとして整理された一覧を例示され（使えそう）、これをチェックリスト的に活用して、関心事の合成、運用ビューへの波及をモデルに加えて、全てのビューの合成までを解説された。このように「関心事を切り出す」ビューによって漏れを未然に防ぐことが「モデリングの効果」であり、たぶんこれこそが「ITアーキテクトの醍醐味」ではないでしょうか？

【もう一度、アーキテクト論】
ITスキル標準を再掲示されて「ソリューション アーキテクチャの設計」はソフトウェアをどう組むかではなく、インフラ面で関心事を切替えながらモデリングすることだと整理された。個人的には（PMなので）、それに続く「PMの心もわからなくちゃダメ」というのがすごく気に入ってしまった。同じ事をとらえてもPMとアーキテクトは発想が違うことを認識しようと題して「PMの脳内」でのPlan, Manage, Scope, …が「アーキテクトの脳内」ではEstimate, Measure, Domain, …である、という具合にそれぞれ6つほど挙げられていた。そんな言葉遊びを知ったからどうなの？と言われそうだが、ただ単に妙にはまってしまった。

最後に「優れた遺産は優れたアーキテクチャと共に」「自分の子供に何を残すのか」として「技術の陳腐化が問題なのではなく、アーキテクチャをより洗練させていくことが重要 → 資産の連続性」という言葉で締めらた。正直、ちょっとピンと来なかったのだが、「RAS（Reusable Asset Specification）」を念頭に置いてのことだったのだろうか。

【終わりに】
冨永氏と榊原氏のセッションが初日の一コマめにぶつかるとは、なんとも勿体無い。どちらのセッションを受講するかは最後まで悩みました。翔泳社さん、来年はぶつけないでください。

【はじめに】
個人的には、PMBOKは学んでみたが「見積」と「スケジュール」は未だ心もとない。「銀の弾丸」がないことは承知で、受講によって復習をし、少しでも自分なりに整理できればという思いで臨んだ。復習という意味での所期の目的は達成したが、講演に目新しい内容はなく、あくまで教科書に忠実な講演だった。

【見積と計画】
「プロジェクトマネジメントへの取り組みの方針」として3つ挙げられたが、特に「『問題処理型』から『計画重視型』プロジェクトマネジメントへ」ということを強調された。確かに「プロジェクトX」のように、トラブルが起こって、これを英知と必至の努力で何とか収束させたファイヤーマンは高く評価されがちだが、むしろ、粛々と「予定どおり」完了したプロジェクトの評価がもっと高くてもよいように思う。またベースラインについてはPMBOKの復習になるが、コストとスケジュールのベースラインを変えていいのは、�@実態とかけ離れすぎてコントロールできない時�Aスコープが変わった時の２つだけである点も強調された。

【成果物スコープと規模見積】
「開発規模はプロダクトのスコープを数値化したものであり、スコープのベースラインになる」。一方で、ベースラインとするからには、計測ルールが確立していて、ユーザーとベンダーのお互いが測れるものである必要があり、それがIFPUG法、CPMである。ファンクションポイント法の計測手順については省略するが、ファンクションの抽出はユーザの視点に立っており、使う人によって左右されることがない、と指摘された。また見積時の留意点を6つあげられたが、特に「見積技法は見積タイミングと見積プロセスを意識して選択」、「精度を向上させるために複数技法で見積った値を比較し検証」、「見積の検討過程を記録しておく」は、今後心がけてゆきたいと考える。

【プロジェクトスコープとWBS】
WBSとワークパッケージに作業分担の欄が用意されているが、これについては必ずSingle Responsibility であるべきと注意された。スコープ定義書については、「発注側／受託側、両者にとって最大のリスク回避策」と定義され、必ず発注側の印鑑をいただいているそうだが、10年くらい唱えてようやく定着してきたそうである。

【スケジュールの作成】
スケジュールの作成手順としては、作業順序の設定 → 作業期間の見積 → スケジュールの作成 → スケジュールの調整 と目新しくないが、繰り返しながら作成してゆくというところはなかなか実践できていない。

WBS、スケジュール作成時の留意点として、以下の3つを挙げられていた。
�@WBS、スケジュールは遅くともキックオフミーティングまでに作成
�AWBS、ワークパッケージをもとに予算、スケジュールを作成
�B不確定度合いを表現するために見積に幅を持たせる

最後の�Bについては、三点見積による近似正規分布を求めるとあるが、むしろPMBOK2004でも取り込んだクリティカル・チェーンによるバッファコントロールが現実的なように考える。

【終わりに】
最後に、PMO設置後の時系列に沿って、プロジェクト採算結果のグラフを示された。それによると2年目あたりから、ほとんど赤字プロジェクトが撲滅されており、劇的な効果があったことがはっきりとわかる。付録の参考図書として、「あまりないWBSの良い本」を紹介されていた。ただし、邦訳がないのが残念だが。

Gregory T.Haugan, “Effective Work Breakdown Structures”, MANAGEMENT CONCEPTS(2002)

【はじめに】
前日に引き続き「見積」関係のセッションを受講した。本音を言うと、雑誌等での馬場氏の印象は理論派からは程遠く、SEへの叱責ばかりであったためにあまり多くを期待してはいなかった。しかし講演を聴講してなるほどと頷く箇所が多く、今までの自分がやっていたことの整理がついた。講演には、○×手法や開発方法論の「従わねばならぬ」といった強迫観念や優等生的な理論はなく、まさに現場で培われた「経験則」であり、非常に興味深く聞くことができた。

【1. 見積りは売るために行うもの】
17項目の箇条書きのうち、馬場氏は以下の項目をマークアップされていた。
・「売れて利益が出ないと意味がない」
・「販売活動の時から見積りは始まっている」
・「販売活動を行うSEは、成約の後そのシステムを開発するプロジェクトマネージャかリーダーが行うこと」

講演では「お客様はSEが考えているほど強くはない！」ということを強調されて、以下のような論旨を展開された。正確なヒアリングは、聞くのではなく聞き出すこと。言い間違い・言い漏れ・勘違いはつきものと考えるべきで、こういったことが日本のSEはできていない。これを知らないとファンクションポイント法も何もあったものではない。見積りはアカデミックではない。一方のユーザー（＝情報システム部）については、欧米と比較しても1/10の人数でカバーしようとしているなど、構造的な問題から見積り能力を持っていない。

そして、見積りは販売活動の時から始まっており、考えて会話しながら“読む、決める”ものである。経験則として、この時点で約1/3はプロジェクトの成否が決まる。逆に言うと、売りと開発が別のプロジェクトマネージャ、リーダーであれば、それまでに積み重ねたヒアリングが全部パーになってしまう。それでうまくゆくわけがない。

更に「ユーザーには『膨れ上がる』という言葉はない、それは聞き出せていないだけだ」という言葉には、ハッとさせられた。最近、「要求定義」に対して「要求開発」という言葉を目にするが、まさにユーザーが自身の「要求」を知っているというのは幻想であり、ユーザーとベンダーが共に「要求」を開発すべきだと感じていた。

【2. 提案システムが開発できなければ意味がない】
11項目の箇条書きのうち、馬場氏は以下の項目をマークアップされていた。
・「まず提案システムが開発できるかどうか考える」
・「次にプロジェクトマネージャ、サブリーダーなどキーとなるSEを決める」

講演では「どれぐらいでやるかは能力のあるSEの腕次第」ということを強調されて、以下のような論旨を展開された。

「アプリケーションプロジェクトはアプリケーションが分かるSEがアサインされるべきであり、そうでなければユーザーはたまったものではない。ユーザーに対して失礼だ。このときの視点は『このメンバーなら責任を持って何とかなる』というメンバーだ。しかしこの手法の分岐点は約300人月であり、これを超えると頑張って何とかなる限界を超えた『未知の世界』だ」

必然的に「人月見積りよりキーとなるSEが先、決して逆ではない」という主張だが、これはPMBOKの常識に真っ向から「反逆」していることになるが、大いに頷けた。

【3. SEの誰がどんな仕事のやり方を行うかで生産性が異なる】
15項目の箇条書きのうち、馬場氏は以下の項目をマークアップされていた。
・「プロジェクトというものは、キーとなるSEのスキルや仕事のやり方で生産性が異なる」
・「特に、SEの能力差が小規模プロジェクトほど生産性に大きく影響する」
・「類似システムだと1回目より2回目、2回目より3回目の方が生産性が高い」

講演では、日本IBMの冨永氏がまとめたグラフ「開発規模による開発負荷の増加」を引用して、小規模プロジェクトこそ誰がやるかという個人差が大きい、ということを強調された。こういうことを知らずに（あるいは無視して）算数的に見積もっていては合うはずがない。特に3000万円以下は、ファンクションポイント法でやったら絶対に合わない、と主張されていた。
では、具体的にどのような「仕事のやり方」がベストかというと「先手を打てる」、「顧客の部課長と進捗管理」、「今日の打合せは明日確認」などの具体例を示され、大変参考になった。

【4．見積り手法に王道はない】
10項目の箇条書きのうち、馬場氏は以下の項目をマークアップされていた。
・「要件定義成果物をベースに、複数の見積り手法で見積る」
・「社内や雑誌などでの事例データを日頃集め、メモをとっておくと便利」
・「ボトムアップのWBSなどでは経験則3を加味する。スキル不足ケースはスキルアップ計画なども加味」

講演では、PMリサーチの岡村氏がまとめられた「トップダウン見積りとボトムアップ見積り」を図示されながら複数の手法で見積るべきだとし、その上でどこが違うのかを明らかにすべきだと主張された。更に「分割見積り」として、要件定義・外部設計・内部設計までと、開発実施以降に分けて考察され、前者は変動幅が大きいと解説された。

【5. 最後は「エイヤー」で決めるしかない】
16項目の箇条書きのうち、馬場氏は以下の項目をマークアップされていた。
・「各種手法で見積もった見積り値を並べその差異を考える」
・「そして「△△人月で行こう」と実質任月を決める。だが、理論値はあくまで理論値」
・「それにリスク度を加える（10%、30%、50%などなど）」
・「その結果を出来るだけ他の人にも相談する（勘違いや思い込みの防止）」
・「社内原価、外注費、利益を勘案して提示額を決める」
・「SE単価は出来るだけ定時しない、フェーズごとの金額提示などにする」

講演では、「自分自身の見積り誤差を知っておく」ことの重要性を主張された。しかしながら、リスクバッファについては少し乱暴すぎるように感じた。確かに緻密にリスクを定義していったとしても結果的には同値かもしれないが、その後のリスク監視までを考えると、やはりこの時点でリスクを緻密に精査して、その一つひとつの判断を記録しておくべきだと考える。

【（馬場氏の）終わりに】
15項目の箇条書きのうち、馬場氏は以下の項目をマークアップされていた。
・「SIビジネスの見積りは決してアカデミックではない、泥臭いもの」
・「見積りは『こんなに計算すればよい』と言う普遍的手法はありえない」
・「アプリケーションに弱いSEでは見積れない」
・「見積りはSEマネージャかプロジェクトマネージャが見積る」
・「日本の多くのユーザは自分たちでは見積れない」
・「信頼されているSEをお客様は信じるもの、そんなSEがビジネスを伸ばす」

講演では、自分が見積ったものには「責任を持つ」、予算内に「絞り込む」のがプロジェクトマネージャやSEの腕であり、これは見積った人の方がやり易い、と強調されていた。

【（レポーターの）終わりに】
所感だが「見積りは決してアカデミックではない、泥臭いもの」という言葉が、馬場氏の講演を端的に表現しており、アンチPMBOK、反ファンクションポイント法の主張はとても新鮮だった。自身が携わっている比較的小規模なプロジェクトは、まさにPMBOKのような教科書的な手法は、身の丈にあっていないのかもしれない。

現在は、猫も杓子もPMBOKで、それ以外はプロジェクトマネジメントではない、と言われかねないほどだ。確かに50人、100人をコントロールするにはPMBOKのような考え方が有効だと理解できるが、実際に10名ほどのメンバが回している現場には、これと違った手法、方法論があってもよいと思う。例えば、そういった規模の限界点が存在しそうなものとして、アジャイル開発、クリティカル・チェーン、セル方式の組織形態などが出てきている（クリティカル・チェーンはPMBOK2004にも取り入れられているが）。今回の馬場氏の「見積経験則」の講演も、これらと同様に規模の限界点を設けた小規模ITプロジェクトのベストプラクティスではないだろうか。