The Myths of Innovation 『イノベーションの神話』秒で発注

私の中では昨年度の最重要本だった、「アート・オブ・プロジェクトマネジメント ―マイクロソフトで培われた実践手法」の著書、Scott Berkunさんの新作邦訳が出るそうです。(via YAMDAS現更新履歴)

というわけで、秒でAmazon予約注文しました。楽しみ！

イノベーションの神話

posted with amazlet on 07.10.19

Scott Berkun 村上 雅章
オライリー・ジャパン (2007/10/29)
売り上げランキング: 10101

Amazon.co.jp で詳細を見る

アート・オブ・プロジェクトマネジメント ―マイクロソフトで培われた実践手法 (THEORY/IN/PRACTICE)

posted with amazlet on 07.10.19

Scott Berkun 村上 雅章
オライリー・ジャパン (2006/09/07)
売り上げランキング: 10812

Amazon.co.jp で詳細を見る

システム開発は製造系じゃなくて創造系じゃないか

妄想ですが考えている事を書いてみるエントリです。

システム開発プロジェクトは「設計」や「製造(コーディング)」をし、「テスト」をします。これはモノ作りの現場、例えば自動車メーカーなどの製造業に例えられます。というわけで一般的にはシステム開発はモノ作りの一種と認識され、運用されています。プロジェクトの規模にもよりますが、全体のQCD(コスト、品質、スケジュール)をプロジェクトマネージャが管理し、全体設計をITアーキテクトと呼ばれる設計リーダーが担当する。その下に、設計者や製造者(プログラマ)、テスターがぶら下って一つのチームでシステム開発を行うのが一般的なイメージ。

しかし、モノ作りではこれらの「人」に加えて「材料」や「工具」が必要ですが、システム開発プロジェクトではほとんど「人」だけで作業を行っています。そして最終製品も開発が終了するまでは曖昧であり、途中で最終形を確認することはできませんし、プロジェクトの途中で最終形がまったく違ったものに変化する事もあります。つまり、モノ作りとしては非常にコントロールがしにくい。

このコントロールしにくい、不定形なプロジェクトをモノ作りと同様に管理するのは限界があるのではないかと考えています。

例えば、映画や演劇、オーケストラのような創造系のプロジェクトのようにはマネジメントできないか。
これらのプロジェクトはほとんど「人」主体で進む点と、「結果があいまいで評価しにくい」という意味で、システム開発プロジェクトに似ていないでしょうか。

創造系のプロジェクト体制は例えば次のような形になるでしょう。

■作家／脚本家／音楽家
プロジェクトの骨格となるストーリーを考えます。共感できる背景や思想を持って、プロジェクトが成功するためのストーリーを考える役割です。出来上がるシステムの骨格(使われ方や重要なポイント)などを観客(ユーザ)から見て考える役割です。

■演出家／指揮者
脚本や楽譜を元に、メンバーをひとつにまとめてシステムの肉付けを行います。単なるマネジメントではなく、メンバーの能力を最大限に引き出し、かつ自分なりの解釈でシステムの肉付をしなければいけません。もちろん仕上がりの品質への責任もあります。もちろん全ての作業工程を知っている必要があります(楽譜が読めなかったり、楽器の出来ない指揮者はいませんよね)

■プロデューサー
プロジェクトを外部から守り、維持します。資金を調達したり、メンバーを集めスケジュール調整もします。外部から見てプロジェクトの最高権限者ですが、内部から見ると守護者となります。

■舞台監督
メンバーの能力を最大限に生かし、脚本を活かす為の舞台を作る人です。システム開発で言えばアーキテクトと呼ばれる立場に近いかもしれません。

■メンバー
プロジェクトの主役です。役柄については主演・助演などの序列はあるかもしれませんが、全員が舞台上で活躍するという意味では等しく重要です。自分だけが目立つのではプロジェクトは成功しませんので、お互いの相互関係に強く留意する必要があります。

こういう構成のプロジェクトであれば、素晴らしい成果が出せると思うのですがどうでしょうか？
(ちなみに、書いているうちにIDEOのことを思い出しました)

PFP関東WS#8に行ってきました

10/3にPFP関東WS#8に行ってきました。プロジェクトファシリテーションに関するワークショップです。参加者は20名くらい。メインは「プロジェクトファシリテーション入門　ＰＦＰ関西合宿濃縮還元版」でしたが、それ以外にもいろいろと盛りだくさんで、たくさんの「気づき」を貰える内容でした。というわけで、後で自分で読みかえす目的もありますが、内容をレポートしたいと思います。

■ファシリテーションの重要性

今回はPFP関東としては初めて、豆蔵さんの会議室を借りたということで、最初に豆蔵の羽生田会長にお話いただきました。10分程度ですが、非常に濃い話で個人的には非常に感動。

• これまではエンジニアリングの観点で、S/W技術やPMを中心に活動していた。これは、ProductからPorcessまでの実現に関わる領域である。
• しかし、顧客の要請(関心)は「問題やビジネス課題そのものの解決」に移ってきている。また、多種多様な「ステークホルダの合意プロセス」なども視野に入ってきている。これはS/W技術やPMのような実現技術ではなく、企画の領域である。
• この4象限を繋ぐキーワードが「見える化(モデリング)」と「ファシリテーション」ではないか？

というような内容を、ホワイトボードを使ってサラサラと説明いただきました。この内容は個人的な自分の現在の興味とビシッとハマってしまい、感動です。いろいろと普段から悩みがあるのですが、勇気を持って、ビジネスモデリングとファシリテーションの学習を続けていきたいと考えています。
なお、羽生田さんのプレゼンテーションそのものも、とても参考になりました。内容だけでなく発表の構造も含めて、短時間でためになるセッションでした。

■TOCに興味が出てきた

次は、アジャイルプロセス評議会 TOCワーキンググループにも参加されている進藤さんの事例紹介です。JudeやTRICHORDなどのおなじみツールの紹介もありましたが、やはり興味深いのはTOC関連の思考フレームワークでした。特に興味深かったのはODSCです。

• ODSCとは
• Objectives（目的）
• Deliverables (成果物）
• SuccessCriteria （成功要件）
• プロジェクトやタスクを定義する際に、上記ODSCを明記して作業を行う。
• 成功要件を定義するので、作業中の意思決定をするときの判断がしやすい印象があります。また、わかりやすいのですぐにでも使える気がします。

PFP関東WSでは毎回必ず事例発表があるのですが、ホンで読んだ理論や技法も実際に活用されている人の言葉で聞くと、とてもわかりやすく、また実践のヒントになります。

■プロジェクトファシリテーション入門 PFP関西合宿濃縮還元版
最後は串田さんファシリテートによるワークショップです。発表資料はWikiに公開されているので興味のある方はどうぞ。というわけで、ここではワークショップの中身についてレポートします。

今回のお題は「どうすればプロジェクトが成功するか」についてグランドルール(問題vsわたしたち、見える化、カイゼン、笑顔)を守って議論を行うというもの。対象のプロジェクトも自分達で選ぶことができます。

• くじ引き
• まず最初にカラーペンを全員に配り、4分間で1対1の自己紹介を行い、共通のキーワードが見つかったらペンを交換するという方法でアイスブレーク＆シャッフル。
• 「わたしはSIerでPMやってます」「私も組込み系のPMです」⇒成立！交換！
• 「血液型はA型」｢O型」⇒不成立！
• 「結婚して8年目です」「私も1999年に結婚した！」⇒成立！交換！
• 時間が短くて、むしろ燃えました。
• 同じ色のペンを持つ人で１グループ。今回は5人×4グループにわかれます。
• あとは自由(これが難しい)
• 真っ白な模造紙が配られます。あとはペンと付箋。さあ開始！(げげっ)
• ゴール決定
• とりあえず全員で1分間考えて発表し、その中で楽しそうなプロジェクトを選ぶことにしました。私のいたグループで出てきた案は次の通り
• 世界征服
• 定時に帰る
• 1週間休みをとる
• 全ての国に行く ⇒ これを採用！
• 発表をうまくやる
• 検討
• われわれのグループでは、さきほどの事例発表にあったODSCを使ってまずゴールと成果物、成功条件を分析してみました。
• ゴール(O)…全ての国に行く ⇒ さらに明確に「一人で国連加盟国(または何らかの本/Wikipediaに掲載されている)に行く」
• 成果物(D)…パスポートのVISA・スタンプ、日記、写真などのキロク
• 成功条件(SC)…できるだけ短時間で実施し、ギネスブックに申請する
• このODSCを意識しながら、プロセスをブレークダウンしていきます。
• ゴール(終端)からプロセスを追っていく
• あとは皆でアイデアや意見を出していくのですが、TOCの思考プロセスを活用して後工程から順に追っていきました。具体的にはこんな順番です。
• 帰国してギネスブックに申請する
  ↑
  <ループ終端(全ての国を巡るまで)>
  入国する
  ↑
  出発する
  <ループ始端(全ての国を巡るまで)>
  ↑
  準備する

• それぞれのプロセスについてのアイデアや問題を付箋に書き込み、プロセスのまわりに貼っていきます。例えば、
• 資金はどうするか？ → 各地で働いて稼ぐ？(大道芸？) → 成功条件(できるだけ短期に)に違反 → 事前に資金準備が必要！
• 入国できない(トラブル、不許可)時はどうする？ → 途上で計画を変更する必要あり
• ケガや病気の発生には → 国によっては対応困難 → ある程度の医療知識を事前に習得必要
• 特によかった点としては、最初につくったODSCによって、各種課題やアイデアの取捨選択がすぐにできたこと。資金調達などは、短期間で行動する成功条件を満たす為には旅行中に行うべきではなく、事前に十分な資金調達をしておく事が重要、というような判断がつきやすかった
• 発表
• 最後に各チームで発表を行い終了。最後にKPTを参加者全員で考えて終わりました。

ここまででちょうど2時間。非常に密度の濃い時間の過ごし方でした。

■書籍紹介
今回はどのセッションでも書籍紹介がありました。発表時に「お気に入りの本や参考書」を持ってきて、回覧するのは良いアイデアだと思います。これはいつかやってみよう！

羽生田会長ご推薦


進藤さんご推薦




■ファシリテーションの練習のためのPFP WS
個人的には、PFPの場を「ファシリテーション的行動の練習の場」として捉えています。ワークショップには、PF初参加の方もいれば、よくわかっている人もいます。会社でいきなりPFを実践するのは勇気がいりますが、PFPの集まりの中では気兼ねなく実践してみることができます。

今回も、たくさんの「気づき」を持ち帰ることができました。
ぜひまた参加したいと思います。スタッフの皆様に感謝です。

日経SYSTEMS10月号

先月号から、日経SYSTEMSの毎号感想を書いています。
なんと、書き溜めているうちに11月号が家に届いてしまいましたが、10月号の感想です。

記事	感想
特集1 目指せ！残業ゼロの現場 時間を取り戻す4つのポイント	とても大事な事。残業を引き起こしてしまっている原因を「手戻り」「気のゆるみ」「無駄な作業」「偏り」に分けて対策を書いているのが好感度。しかし、事例紹介が中心なので、ただちに適用できるものではないなぁ。
特集2【保存版】ユーザー・マニュアル作成術	テクニカルコミュニケーター協会というのを知りませんでした。でも、「紙のマニュアル」を前提にしているところがちょっと違和感あり。エコ的に考えて、紙のマニュアルを脱する議論をもっとしても良いのではないかと。
特集3 のぞいてみよう「組み込み開発」の現場	ちょっと業務から遠いのでパス。
検証ラボ データセンターのセキュリティ検証実験 IDS/IPS設置して再びチェック、すべての脆弱性はつぶせず	2部構成の後編。前編は防御側(IDC)視点で語られていて面白かったのだけど、今回は攻撃側視点でちょっと楽しめず。しかし、勉強になりました。こういったセキュリティ関連チェックを自力でやるのは非現実的だなぁというのが感想。
プロダクト賢者の選択 構成・変更管理ツール 分散拠点からのつなぎ方に違い、カスタマイズのしやすさを重視	有償のワークフロー付き構成管理ツールの説明。結局IDEと統合されていないと使い物にならない気がします。Subversion+Tracまたは JIRAというのが現実的。あとはASPサービス利用がいいと思ってます。後者はセキュリティ上なかなか取れない選択肢ですが。
絵で見るテクノロジ 文字コード　文字集合と符号化方式の組み、いくつもの規格が乱立	Vistaの問題(http://itpro.nikkeibp.co.jp/99/vista/index.html)と絡めればもっと読める記事になったのに……
事例に見る問題解決の軌跡 CASE24 ネクスト フレームワーク「Maple」を導入、改修案件の工数が従来の半分に	PHPでもDIなのかー。しかしPHPは扱っていないので、響きませんでした。やってみたいんですけどね。
SOAきほんのき［第1回］SOAを取り入れるメリット／柔軟性と再利用性が向上、Webサービスが普及を後押し	SOAのメリットを「ビジネス環境の変化にあわせて、迅速にシステムを開発し、プロセスの変更にも柔軟に対応できること」としているが、SOA以前の方法論ではなぜダメなのかが説明されていない点がちょっともったいない感あり。
教えて！実装&テスト工程［第1回］下流工程の準備／ツールやフレームワークは、選定間違うと「負の資産」に	IDE、Wiki、バグ管理システム以外にモデリングツールやプロファイリングツールの準備を推奨しているんだけど、いまいち活用イメージが湧かなかった。うーむ。
図解でもっと磨くプロマネ技術［第1回］プロジェクト完了報告書／思い出のアルバムからは、ノウハウも教訓も見えてこない	仰るとおり。しかし、まず完了報告を書くこと、読むことがら始めなければいけない世の悲しさよ。
コミュニケーション・スキル再入門プロジェクト編［第1回］初対面の緊張を和らげる／うまくやろうとすると逆効果、沈默を恐れず相手の言葉を待つ	初対面は苦手じゃないので飛ばし読み～
永井昭弘のすごい現場 建築設計事務所で見た巨匠のすごいレビュー	建築設計事務所っていうのは、システム開発の非常にお手本になると思っています。NHKの「プロフェッショナル 仕事の流儀」でも何回か建築家が登場していたけど、かなり刺激をうけました。
濱本常義のここが危ない！ 若手成長の踏台になる喜び 夏の恒例行事で実感	セキュリティキャンプの話ですが、こういうエリート育成活動ってどうなのかなという感覚もあります。ボトムアップのほうが急務なんじゃないかなぁ。
鈴木雄介のITアーキテクトの視点 バグの原因は何か？「環境を見る」と見えてくる	環境は重要。デマルコの本を思い出します。
ココロとカラダの相談室 抜けないだるさは万病のもと 気のせいにせず病院へ	ノーコメント
ITエンジニア現代図鑑 第7回「オレ様SE」実力過信しユーザー軽視 自分勝手にシステムを作る	ヒトゴトではなくて、テクノロジ先行のプロジェクトでは「オレ様SE」だけでなく「オレ様SI」もあるなー
数字で答えるIT現場の疑問 1000人月プロジェクトの工期はどれくらい？	COCOMOの紹介ですね。イマサラ感はありますが、この規模になると誤差の影響も多いのでこういった統計値の確認は重要です。でも、日本型システム開発がその通りに当てはまるか、というと、ちょっと微妙な印象あり。