プロジェクトファシリテーション

2016/06/21

組織行動で知られている罠

世界で最もイノベーティブな組織の作り方」を読みながら、組織行動で知られている罠についてメモ。
主張は特に無し。

【1】有能性の罠(competency trap)

起業家・経営者ファイトクラブ [まぐまぐ!]

BBIQモーニングビジネススクール

コンピテンシー・トラップとは? : 現場を活かす企業経営

「満足水準を超えた利潤を得て、不満がない状況では、あえて現在よりも優れた戦略や方法を探索する動機づけが失われる」
「当面の事業が成功すればするほど、知の探索をおこたちがりになり、結果として中長期的なイノベーションが停滞するというリスクが企業組織には本質的に内在している」

従来のやり方で成功し続けると、そのやり方に固執して、現在よりも優れた方法を探索しなくなる。
特に、保守的な大企業ほど、創業以来のやり方に固執してしまいがち。

【2】訓練された無能(官僚制の逆機能)

官僚制とは | ビジネススクールならグロービス・マネジメント・スクール

官僚制の意味 - MBA経営辞書 - goo辞書

2/4 官僚制理論と官僚制批判理論その基礎 [社会ニュース] All About

ユニゾンのENSEMBlog : 訓練された無能

「「訓練された無能」とは、あまりに規則などに固執することによって、変化した状況に対応できなくなってしまうことです」
「おかれた状況が変化しているのにもかかわらず、同じ行動パターンを繰り返してしまう 」

保守的な大企業に長くいる人ほど、周囲の環境が変化して以前の常識が通用しなくなっているのに、同じような行動パターンを踏んでいるケースを見かける時がある。

【3】グループシンク(集団浅慮)

集団思考 - Wikipedia

グループ・シンクとは | ビジネススクールならグロービス・マネジメント・スクール

Educate.co.jp | グループシンク(集団浅慮)

なぜこんなに発言しにくい? -集団浅慮 | GLOBIS 知見録 - 読む

「集団の圧力により、その集団で考えていることが適切かどうかの判断能力が損なわれる状況です」
「特に、集団の凝集性が高い場合や、外部と隔絶している場合、支配的なリーダーが存在する場合などに起きやすい」

特に日本人の一部の集団のように、集団の凝集性が高く、個人の異論を受け入れないような集団では、集団での意思決定が個人の意思決定よりも浅はかになってしまうリスクがある。

【4】リスキーシフト(集団極性化)

リスキーシフト - Wikipedia

基礎演習

意思決定の集団極性化の社会心理学|経済界

集団極性化:心理学用語集 サイコタム

集団思考のワナ ー リスキーシフト|レイデル の「心のエラー」と「脳のトラップ」

「組織での意思決定は極端な方向に振れやすい」
「集団極性化現象(グループ・ポーラライゼーション)とも呼ばれる」
「集団浅慮(グループシンク)の結末として、往々にしてリスキーシフトと呼ばれる現象が起こります。これは、グループでの意思決定は、極端な方向に振れやすいという現象です。」
「リスキーシフトは、集団で決めたことが、個人で考えるよりも危険性の高い決定になることをいいます。」

大規模な組織ほど、実は、リスクのある意思決定が行いやすい時がある。
個人の意思決定よりも集団の意思決定の方が極端にぶれやすい。

【5】コーシャスシフト

集団意思決定

集団思考のワナ2 ー コーシャスシフト|レイデル の「心のエラー」と「脳のトラップ」

いじめ、暴行・・・集団心理が危険な結果を招くわけ [ストレス] All About

2/2 「いじめ」にかかわる集団極性化と傍観者効果
 いじめ、暴行・・・集団心理が危険な結果を招くわけ [ストレス] All About

「リスキーシフトとは真逆で、集団の意思決定が保守的で消極的な方向へ向かうものを言います」
「コーシャスシフトは、集団で決めた決定が、個人で決めるよりも、慎重でより安全志向になることをいいます」
「こうした集団心理の特性をよく理解し、小さな事件が大きな問題へとエスカレートする前に、今起こっている現象をよく検討する必要があります」

コンセンサスに重きをおくほど、ラディカルな企画や意見は、角が取れて、最終的な結論は何も言っていないに等しくなる場合がある。

日本の学校にけるいじめは、集団極性化現象そのものと同じだと思う。
個人では良い人なのに、集団になると、排除する力が大きくなりがち。

【6】バイアスの罠

番外その14 「バイアス」の罠~人間の判断にはバイアスがかかっている~

選択バイアスの罠

意思決定のバイアス|おりばーのブログ

「人間の意思決定は気づかないうちにさまざまなバイアスを帯びている」

バイアスの罠を意識しておかないと、他人の意見に左右されやすく、意思決定がぶれやすくなると思う。

【7】我々は、学校、会社、コミュニティという集団に必ず属している。
過去の日本の歴史をたどれば、官僚的な組織になるほど、上記の罠にハマったケースが見受けられるだろう。

また、自分が所属する組織において、「有能性の罠」「訓練された無能」「グループシンク」「リスキーシフト」「コーシャスシフト」の現象なのかな、と思う時もある。
そういう概念を知っているだけでも、落とし穴を避ける事もできるはず。

| | コメント (0)

2015/10/02

「価値ある製品を生み出すためのアジャイル実践ポイント」の資料が公開されました

8/22に行われたSEA関西イベントの資料「価値ある製品を生み出すためのアジャイル実践ポイント」が公開されたのでメモ。

【参考】
第63回 SEA関西プロセス分科会-SEA関西 価値ある製品を生み出すためのアジャイル実践ポイント

これからアジャイル開発を実践したいという初心者向けに、アジャイル開発のマインドや実践ポイントを解説した資料。
特に、ターゲットは、製造業向けのソフトウェア開発者をイメージしているみたい。
135ページと長いが、「わかりやすいアジャイル開発の教科書」をベースにしているので、内容はとても分かりやすい。

当日の勉強会では、初めて、レゴスプリントをワークショップで経験した。
レゴスプリントでは、ブロックを使って、Scrum風のプロセスで製品をチームで作っていく。
結構面白かった。

なお、レゴスプリントとレゴスクラムは全く違うモノらしい。
それも一つ勉強した。

| | コメント (0)

2015/01/26

プロジェクトマネージャへのお勧めの本

プロジェクトマネージャへのお勧めの本の記事があったのでメモ。
内容はすごく同意する。

PM(プロジェクトマネージャー)になったら絶対に読むべきおすすめの本6選(転載) | Books&Apps

僕も読んだことがある本が多いのですごく同感する。
下記の本は読んだ。

【1】「ソフトウェア見積り」は、「アジャイルな見積りと計画づくり」と合わせて読んだ。
見積りの各種技法が網羅的に分かりやすく書かれているのがいい。

僕は、統計に基づくスケジュールの基本公式は

スケジュール(月)=3.0×人月^1/3

ではなく、

スケジュール(月)=2.5×人月^1/3

を採用している。

例えば、見積り工数が20人月以上なら、上記の公式で工期を一旦はじき出し、要員計画を立てるやり方をよく採用する。
見積り工数が40人月くらいなら、工期は約6~7ヶ月くらいになるので、経験的にも妥当かな。
あくまでも参考値だが、システム提案という限られた時間でシステム計画を立てる時に役立つ。


【2】「曖昧性とのたたかい―体験的プロジェクトマネジメント論」は、典型的な受託開発案件で、WF型開発を行うノウハウが書かれている。
日本人向けのイメージ。

【3】個人的には「アート・オブ・プロジェクトマネジメント ―マイクロソフトで培われた実践手法 (THEORY/IN/PRACTICE)」が好き。
過去に感想をたくさん書いた。

アート・オブ・プロジェクトマネジメント: プログラマの思索

アート・オブ・プロジェクトマネジメントを読み直してTiDDを補強する: プログラマの思索

Velocity駆動のイテレーション計画の作り方とは: プログラマの思索

【4】他に、「アドレナリンジャンキー プロジェクトの現在と未来を映す86パターン」も好き。
プロジェクト管理のアンチパターン集なのだが、読んでいて、思わず笑ってしまう。

「アドレナリンジャンキー」「死んだ魚」「レミングサイクル」「残業に見る予兆」「永遠の議論」「ポーカーの夕べ」「明日には日が昇る」「ほったらかしの成果物」「変更の季節」の言葉を聞くだけで、そうだよ、なるほど!と思ってしまう。

プロジェクト管理のアンチパターン集~アドレナリンジャンキー: プログラマの思索

ぽんぽんぺいんなう\(^O^)/ | 「アドレナリンジャンキー プロジェクトの現在と未来を映す86パターン」トム・デマルコ他

書評『アドレナリンジャンキー』 | ライフハッカー[日本版]

| | コメント (0)

2014/11/29

「フレームワークで人は動く」の感想~論理フレームワークだけではく人を動かすフレームワークも大事

フレームワークで人は動く」の感想をメモ。
「論理フレームワークだけではく人を動かすフレームワークも大事」というメッセージが印象に残った。
ラフなメモ書きなので、論理は飛んでいる。

【元ネタ】
【新刊のお知らせ】 『フレームワークで人は動く』 : タフ&エレガントな日々Ⅱ

人を動かすのにも「フレームワーク」がある?コンサルタント直伝のノウハウとは。 (ビジネスブックマラソン) - Yahoo!ニュース BUSINESS

読んだら書く! フレームワークで人は動く

akipiiさんはTwitterを使っています: "夏目漱石の『草枕』の冒頭。智に働けば角が立つ。情に棹させば流される。意地を通せば窮屈だ。兎角に人の世は住みにくい。そこで智(コト系)と情(ヒト系)で使い分けか。【新刊のお知らせ】『フレームワークで人は動く』: タフ&エレガントな日々Ⅱ http://t.co/2o2VJIGLGZ"

【1】ビジネスで用いるフレームワークには2種類ある。

それは、コト系フレームワークとヒト系フレームワーク。
コト系フレームワークは、物事を整理して分析するのに役立つ。
ヒト系フレームワークは、ヒトを巻き込んでチームを運営するのに役立つ。

【2】既存のビジネスで使われるフレームワークは、普通は、コト系フレームワークを指す。
例えば、ロジカルシンキング、SWOT分析、3C、ファイブフォース、BSC、マインドマップ、など、概念や問題を整理して深掘りしたり、アイデアを創出する。

しかし、実際の現場では、「組織が感情を持っている」。
いくら論理的に主張を構築しても、周囲の人が理解して納得して、行動してもらえなければ、いくら変革のメッセージを言っても、何も変わらない。

ヒト系フレームワークはそんな時に役立つ。
例えば、タックマンモデル、ハーマンモデル、ジョハリの窓、経験学習モデルなどがある。
それらフレームワークを使って、寄せ集めのメンバーから成るチームを有機的にさせて、チームの能力を飛躍的に向上させる。
あるいは、懐疑的な利害関係者を説得し、納得してもらい、逆に、変革の行動を起こしてもらうようにする。

僕のイメージでは、ヒト系フレームワークは、プロジェクトファシリテーションの一種に含まれるかなと思う。

この辺りのビジネスフレームワークの一覧をざっくり見たい時は、「ビジネス・フレームワーク (日経文庫ビジュアル)」がお勧め。
戦略立案、マーケティング、問題解決、マネジメント、組織開発のフレームワークが一通り紹介されている。
例えば、コト系フレームワークは、戦略立案、マーケティング、問題解決、ヒト系フレームワークは、マネジメント、組織開発に相当するだろう。

【3】新しいことを実行しようとすると、たくさんの利害関係者のベクトルを合わせるという「調整」が必要になってくる。
フレームワークで人は動く」には、ステークホルダータイプとして、「アイコン」「インフルエンサー」「ネットワーカー」の3種類を上げている。

アイコンとは、その組織や仕事の価値観を体現している人。
例えば、カリスマと呼ばれる人、高度な技術を持つエンジニアなどが相当するだろう。
アイコンのような象徴的な人物が変革に同意するかどうか、という言動や意見を見て、周囲の人も追随してしまいがちだから。
だから、アイコンを巻き込んで味方に引き寄せる時もあれば、アイコンを引き寄せられなければ更迭して周囲に変革のメッセージを伝える場合もある。

インフルエンサーとは、組織や集団の熱気ややる気を変えられる人。
例えば、ムードメーカーやチームリーダーが相当するだろう。
変革プロジェクトでは、インフルエンサーにエバンジェリスト(伝道師)になってもらい、組織に変革のメッセージを伝達する役割を担わせることが大切。
プロセス改善なら、プロセスチャンピオンかな。

ネットワーカーとは、組織や集団内で事情通で、皆がどう考えているかを把握できる人。
例えば、お局様、事務の女性、事務局の人が相当するだろう。
変革者は、ネットワーカーに変革の評判や評価を随時ヒヤリングして、ステークホルダーの動向や周囲の評判を収集する。

【4】「フレームワークで人は動く」は物語風に変革プロジェクトでコト系・ヒト系フレームワークを使ったストーリーがはさまれていて、読みやすい。

システム開発の案件では、システムの導入の目的の一つが業務の変革だったりする。
ERP導入による業務の効率化、ERP導入によるBPRは、単なるシステム導入ではなく、ユーザ企業の現場の人たちも巻き込んで、業務そのものを変えてしまう威力がある。
だから、プロジェクトリーダーは、技術だけでなく、利害関係者を巻き込んで、彼らを説得し、納得してもらい、システムが長く使われるように調整しなければならない。

その時に、単に技術だけでなく、ヒト系フレームワークやプロジェクトファシリテーションのスキルがあれば、無駄な政治闘争に注力することも減り、プロジェクトをコントロールできるようになるだろう。

この辺りの内容も、自分の経験も含めて整理してみたい。

| | コメント (0)

2014/09/02

エンタープライズアジャイルは袋小路に陥っているのではないか

最近のアジャイル開発の事情を書いた記事があったのでメモ。
ラフなメモ書き。

【元ネタ】
Agile2014に参加してみて分かった昨今の世界のアジャイル事情 - THE HIRO Says

もはやウォーターフォールだけでは通用しない:エンタープライズアジャイルが難しい理由と、実践の「現実解」 - @IT

動き出した エンタープライズアジャイル - 導入効果を「最大化」する5箇条:ITpro

(引用開始)
一方で今年参加してみて、下記の図にあるような傾向が見えるようになってきました。

Agile/Scrum/Lean/XP 自体は既に当たり前になっており、それらをどうよりうまく活用するかに焦点が移ってきている。
アメリカのコンサルを中心に「Enterprise Agile」が流行っているが、一方でこれに嫌悪感を持つ勢力も増えつつある。
BDD/ATDD を中心に、Testing のセッションに改善がみられる。
Metrics のセッションが増えてきた。
(引用終了)

(引用開始)
1. Enterprise Agile
「Enterprise Agile」とは、簡潔に言うと、企業全体レベルでのアジャイルを実現しようという考え方・方法論のことです。
(一部で「大規模アジャイル」と表記されていることもありますが、この表現だと「大規模プロジェクトでのアジャイル」だと誤解されやすい/そのような意味で使う人もいるので、「企業全体レベルでのアジャイル」とした方が妥当だと私は考えています。)

なのですが…技術面などの実現基盤については一切語らず、「メンバー全員が幸せになれるモチベーションを作るべきだ」のように空虚な「精神論」だけを言っている人が非常に多いのが気になりました。
こういうことを言う人は、アメリカでコンサルをやっている人に多かったです。
こうした発表は、アメリカ人参加者には非常に受けが良いのですが、他の国の人(カナダ含む)はしらけていました。
弊社のアメリカ人の多くが「アジャイル」と耳にすると「いい加減なこといいやがって!」と反応するのが不思議だったのですが、今年カンファレンスに参加してようやく理解できました。

例えば、コチラの動画を観ていただきたいです。ダンスをして楽しくなっても、良いプロダクトは作れないと思うのですよ。

そうした一方で、昨年一部で物議を醸していたSAFe(Scaled Agile Framework) が着々と勢力を広げつつあり、特に今年は SAFe をテーマにしたセッションが5つほどありました。
(引用終了)

エンタープライズアジャイルの定義は色々あるだろうが、僕は「企業向けの基幹系業務システム開発にアジャイル開発を取り入れた手法」と理解している。
日本のSIでも、B2Bの業務システムの受託開発案件が非常に多いだろう。

しかしながら、上記の記事では、エンタープライズアジャイルを標榜する人達が、技術面の話よりもチーム運営や精神論に走っているという指摘をしているが、非常に興味深い。

僕もアジャイル開発に興味を持った理由は、従来にない技術を持っていたことや、スピーディな開発を支える技術を揃えて開発プロセスをIT化する点だったから、この手の話はイマイチのりにくい。

基幹系業務システム開発にアジャイル開発を取り入れた場合、我々がよく知っているアジャイル開発プロセスは実現しづらいと思う。
基幹システムだから大規模にならざるを得ず、最初に開発スコープのブレを抑えつけないと、その後の開発が迷走しがち。
だから、仕様凍結に近い手法を取らざるを得ず、ウォータースクラムフォールまたはハイブリッドアジャイル開発のように、下流工程のみアジャイル開発のような手法を取らざるをえない。

また、業務システム開発の場合、CIOの観点では、システムを開発するだけでなく、システムをいかに利用してもらうか、という点の方が重要だ。
情報システム部門の役割は社内にシステムを導入して、利用者を増やして、業務を効率化することにあるので、いかに社員を巻き込むか、という点が重要になる。

つまり、「プロフェッショナルCIOの教科書」に書かれた内容のように、社員の意識改革に注力するようになる。
すると、オペマミやら運用ガイドラインなど、たくさんのドキュメントを作らざるを得ず、アジャイル開発の良さである「動くソース重視主義」が取りづらい。
また、情報システム部門のメンバーは、プログラミングよりも、利用部門にシステムの良さやシステムの使い方を説明する方に力を注ぐから、技術一辺倒とはなりにくい。

「プロフェッショナルCIOの教科書」の感想~調整型CIOは必ず失敗する: プログラマの思索

そういう観点があるから、プログラミング技術一辺倒よりも、利用部門の人達を巻き込むためのファシリテーション力や業務改革を推進するエバンジェリストのような能力の方が重要視されるだろうと思う。

したがって、アジャイル開発が生み出した「開発プロセスを支える技術」を深く掘り下げるよりも、人を巻き込むためのファシリテーションやリーダーシップ、エバンジェリストなどの能力が必要とされる。
それは最終的には、社内政治のようなスキルに近いだろう。

そんなことを思うと、エンタープライズアジャイルは袋小路に入っていると思う。

| | コメント (0)

2014/04/27

【公開】XP祭り関西2014講演資料「KPTによるプロセス改善~あなたはPDCAを回したことがありますか?」 #xpjugkansai

XP祭り関西2014が無事に終わりました。
参加者やスタッフの皆さん、お疲れ様でした。

私の講演資料を公開します。

【参考】
XP祭り関西2014 - XPJUG関西wiki

【1】今回の講演では、KPTによるプロセス改善の経験談を中心に話しました。
私の立場として、最近はRedmineエバンジェリストと思われる時が多く、プロジェクト支援を依頼される時が多い。
なので、各プロジェクトを横断して、PMOの立場で、プロジェクトリーダーの管理を支援する場合が多いです。

そんな立場でプロジェクトを見ていると、うまく回っていないプロジェクトには幾つかの共通点がある。
真っ先に分かるのは、このプロジェクトリーダーは、PDCAサイクルを回した経験を持っていないから、チーム運営をコントロールできていないな、という点。

【1-1】PGあがりのPLには幾つかの落とし穴がある。
1点目は、何らかの計画書を作った経験がないこと。
例えば、WBSを作ったことがないので、目的や方法を知らない。
すると、行き当たりばったりで作業していることになる。

普通は部課長レベルになれば、彼らの仕事の殆どは、プロジェクト計画、部課の予算計画などひたすら計画書を作るのがお仕事。
マネージャレベルならば、このレベルはクリアしている。

【1-2】2点目は、作業指示ができないこと。
人は指示するだけで動くわけではない。
プログラマあがりのPLにありがちなのが、指示は出すけど、指示の目的や意図や期待する結果を伝えていないために、担当者のアウトプットが想定と違ってしまうこと。
そんなことが続くと、自分でやった方が早いから、PLが作業を抱え込んで破綻するケースが多い。

【1-3】3点目は、予実管理できてないこと。
マネジメントでは、当初の予定と実績を比較して、その差異をみつけて、変化に合わせて状況をコントロールしていく。
しかし、臨機応変に対応できてない。
この部分は、Redmineによるチケット駆動開発など、ツールでカバーできる部分がある。

【1-4】そして4点目は、「カイゼン」の経験がないこと。
ここで「カイゼン」は継続的に改善するという意味で、カタカナで表現している。
実は、部課長レベルでも、カイゼンの経験がない人は以外に多い。
その人達がよく言うのは、「これだけお膳立てしているのに、なぜ皆は変わらないんだ?」というフレーズ。
現場の状況に合わせて改善して効果を上げるのは、それなりのテクニックを必要とする。

【1-5】「これだけ! KPT」に書かれているように、改善サイクルを1年ないし3ヶ月のような長期スパンで回すのは至難の業だ。
むしろ、1週間~4週間のように短い期間で、どんどんPDCAサイクルを回して改善して行く方がやりやすい。
この点は、アジャイル開発をやっているチームの方がカイゼンにすごく向いている。

逆に、WF型開発に囚われすぎているチームは、カイゼンがとてもやりにくい。
KPTを実施するタイミングがプロジェクト完了時しか取れないので、せっかくチームの一体感が生まれてもチームは解散してしまう。
KPTで得られた知見をチームの成長に使えない弱点がある。

KPTのアンチパターン~XP祭り関西2014のプレ資料 #xpjugkansai: プログラマの思索

【公開】第10回 RxTstudy/第57回 SEA関西プロセス分科会「チケット駆動開発とメトリクス」の感想 #RxTstudy: プログラマの思索

【2】今回の講演では、僕の実体験「チケット駆動開発を始めた頃」「炎上プロジェクトに火消しPLで支援」「炎上プロジェクトにPMOで支援」について、KPTを実施して得た知見を話した。

ポイントはいくつかある。
資料に詳しく書いたので、読んで下さい。

・KPTはCAPDで回す
・SECIモデルで暗黙知を表出・内面化
・KPTは経験学習モデルに似ている
・KPTの良い兆候
・【反例】ベクトルがバラバラのチーム
・【反例】1回だけのKPT
・意見を出すためのフレームワーク
・【反例】コンフリクト
・タックマンモデルでコンフリクト解決
・【反例】残り続けるProblem
・フォースフィールド分析でProblemを考える
・【反例】期待過剰
・Will-Skillモデルでチームの成熟度診断

まとめると、こんな感じ。

【2-1】KPTでPDCAサイクルを回そう
・「チームに変化を起こす」ことを心がける
・「暗黙知にする」流れを意識しよう(SECIモデル)
・チームの経験からプラクティスを編み出す流れを意識しよう (経験学習モデル)

【2-2】KPTでチーム内の力学が分かる
・コンフリクトはチームビルディングのチャンス(タックマンモデル)
・推進力を強め、抑止力を弱める(フォースフィールド分析)
・成熟したメンバーは動機付けor委任で回る(Will-Skillモデル)

Twitter / Uemmra3: あきぴーさんの経験から、組織をうまくまとめるのには潜在的な衝突を早めに出してあげて、つまらない障害を早く乗り越えてチームをまとめる。タックマンモデルというらしい。 #xpjugkansai

【2-3】KPTは日本人のチームに向いている
・ほとんどの日本人は、自分の意見を表明する行為に慣れていない
・意見表明に慣れていない人からKPTで本音を引き出す

【2-4】KPTのタイミングに注意しよう
・WF型開発はふりかえりするタイミングが取りにくい

【3】懇親会で感想を聞いたら、プロジェクトリーダーや管理職以上の方には、気づきが多かったらしく、参考になったという意見をもらえて嬉しかった。
ただし、チーム運営の経験がない開発者には、遠い世界の話に聞こえたらしく、その点は反省点かもしれない。

| | コメント (0)

2014/04/23

KPTのアンチパターン~XP祭り関西2014のプレ資料 #xpjugkansai

XP祭り関西2014で「KPTによるプロセス改善~あなたはPDCAを回したことがありますか?」を講演する予定ですが、一部の資料が余ってしまったので、プレ資料として公開します。

【参考】
XP祭り関西2014 ~やってみよう!XP~ - 日本XPユーザーグループ関西 | Doorkeeper

XP祭り関西2014 - XPJUG関西wiki

XPやScrumなどのアジャイル開発をやった経験がある人なら、KPTと言えばすぐに分かるだろう。
そして、ふりかえりも実際に経験したこともあるだろう。

僕も、プロジェクトファシリテーションの流れから、KPTとふりかえりを実際に試してみた経験がある。
その経験から、PDCAサイクルとはこういうプロセスなのだな、という感覚がつかめたように思う。

そして、周囲のプロジェクトリーダーや部課長などを見ていると、この人はPDCAサイクルを回した経験が無いんだな、と思う時もあった。
そんな人は、チームを動かしたり、もっと大きな組織を動かしたという経験がないのだろうな、と思う。

作業を指示したからといって、人は動くわけではない。
エンジニアのように、技術の専門家に対して、部課長が上から指示を出して、それでシステムが完成するわけではない。

また、そんな人に限って、計画をきちんと作ったとしても、その計画を現場に当てはめて、微調整しながらコントロールしたことがない。
無理やり、チームや組織に当てはめようとするから、現場の人はサボタージュしたり、服従背面の行動をとったりする。

そんな現場では、いわゆる継続的な改善というプロセスが存在しない。
だから、いつまで経っても、チームも組織も成長しない。
同じような失敗を何度も繰り返す。

これだけ! KPT」にも書かれているが、PDCAサイクルを回すのは至難の業だ。
1ヶ月や3ヶ月という長いスパンでPDCAサイクルを回すのは、たとえ少人数のチームでも、結構難しい。
PDCAサイクルを回した経験がないプロジェクトリーダーや課長が上に立っていたら、もっと最悪だ。
毎日がデスマーチ。

KPTの良さは、PDCAサイクルを自然に回す仕組みが整っていること。
プログラマ上がりで、マネジメントの経験が短い人でも、KPTでチームを回すことは可能だし、簡単にできるのがいい。

但し、KPTには結構コツがある。
そのコツをKPTのアンチパターンとしてまとめみた。

詳細を聞きたい場合、XP祭り関西2014 - XPJUG関西wikiにぜひ聞きに来てくだい。

| | コメント (0)

2014/03/22

「アジャイルに効く アイデアを組織に広めるための48のパターン」の感想~エバンジェリストが自分のアイデアを組織に導入する時に役立つパターン集

アジャイルに効く アイデアを組織に広めるための48のパターン」を読んだ感想をラフなメモ書き。

【参考】
Fearless Change アジャイルに効く アイデアを組織に広めるための48のパターン一覧: プログラマの思索

「Fearless Change アジャイルに効く アイデアを組織に広めるための48のパターン」予約開始 - Yasuo's Notebook

『Fearless Change アジャイルに効く アイデアを組織に広めるための48のパターン』 - delirious thoughts

Fearless Changeアジャイルに効く アイデアを組織に広めるための48のパターンを熟読中 - 未来のいつか/hyoshiokの日記


【1】背景、動機

自分が新しいツール、新しいプロセスを導入したい時、うまくいく場合とうまくいかない場合がある。
例えば、Redmineによるチケット駆動開発を導入したい時、あるいは、アジャイル開発を導入したい時、その結果は、やり方に応じて失敗する時もある。

僕はRedmineのエバンジェリストと思われる時が多く、Redmineの導入によってプロジェクト支援を期待される役割が多い。
僕は過去の経験から、アジャイル開発へ発展させるパターン・アンチパターンを貯めてきたので、どのプロジェクトもそれなりに成功してきたと思っている。
でも、他の人が同様に成功するとは限らないだろう。

2000年代前半、XPユーザグループでは、XPを通じたアジャイル開発をいかに現場に導入するか、という事例とノウハウの議論がたくさん行われた。
実情は、アジャイル開発は日本のSIに導入しづらい、という苦労話ばかりで、たくさんの失敗例ばかりだった。
でも、Scrumが世界で普及し始めた後を追うように、日本でもScrumをベースにしたアジャイル開発の成功事例が少しずつ増えてきているように思う。

アジャイルに効く アイデアを組織に広めるための48のパターン」は、新しいアイデアを持ち、そのアイデアに熱意を持っているエバンジェリストが、そのアイデアを組織へ導入するためのノウハウ集だ。
この本の内容をもっと以前に知っていたら、僕もこのテクニックを使って、もっと容易にRedmineを導入できただろうと思った。

アジャイル開発を実際の現場に導入したいと思う人がいるなら、まずは「アジャイルに効く アイデアを組織に広めるための48のパターン」を読んで、どのように組織へ展開すべきか、構想を巡らすと成功率が高まるだろう。

【2】「アジャイルに効く アイデアを組織に広めるための48のパターン」を適用できる状況

アジャイルに効く アイデアを組織に広めるための48のパターン」のアイデアは、新しいアイデアを持ち、そのアイデアに熱意を持っているエバンジェリストだけでなく、次の人達にも使えると思う。

(1)PMOや品質管理部(SEPG)の立場で、個別プロジェクトや組織を支援する人達

PMOやSEPGは、普通は火消し役でプロジェクトを支援する立場が多い。
すると、火を噴いているプロジェクトで既に作業しているメンバーやリーダーが、実は抵抗勢力になってしまう場合もある。
現場の問題点を把握せずに、頭ごなしの命令や作業指示をいきなり実施すると、反発されてしまうのだ。

(2)プロジェクトリーダーとして、新しいツールや新しいプロセスを導入したいと考える人達

新しもの好きなアーリーアダプター、イノベーターの精神を持つプロジェクトリーダーは、新しい案件で新しいツールやプロセスを試したくなる場合がある。
新しい技術を試して、新しいノウハウを得たいのだ。
でも、メンバーが新しい技術に付いていけなかったり、上司が予算やコストを理由に圧力をかけてくる時もある。

(3)業務改善のためのシステム提案、要件定義を行う人達

SIがシステムを提案する場合、ユーザ企業にシステムを導入するだけでなく、ユーザ企業の業務プロセスも変わってしまうことも合わせて提案する時が多い。
業務のIT化とは本来、今まで労働集約的だった作業を自動化して、人減らしに使う一つの手法だから。
すると、ユーザ企業の組織構造も変わる事になり、従来の仕事を持つ人達は役割が変わるだけでなく、権限が廃止される場合もあるので、抵抗勢力になってしまう時がある。

【3】プラクティスをパターンとしてまとめる意義

アジャイルに効く アイデアを組織に広めるための48のパターン」が優れている点の一つは、エバンジェリストが使えるような道具として、パターン形式でまとめていることだ。
パターン形式なので、どんな状況でどんな問題に対してどんな解決策を実施すればよいか、が明確に理解しやすい。
また、パターンの概念はパターン名で名前付けられているので、会話の中でパターン名を呼ぶだけで、その背景や問題意識、パターンを適用した効果についても、他人と共有できる利点がある。

欧米人が日本人よりも優れている点は、PMBOKやCMMIのように、既に知られている経験知を知識体系として抽象的に普遍的な概念としてまとめる能力がある点だと思う。
関西IT勉強会でも、谷島さんが同じようにことを指摘されていた。

過去から今までの日本人も、プロジェクト管理や開発プロセスについて、たくさんの経験を持っているし、たくさんの書籍も出している。
しかし、それらの知識はバラバラであり、他人が使えるような知識や概念になっていない。
そもそも、それらの概念に名前が付けられていないので、他人との会話で流通できるような普遍性を持っていない時が多い。

パターンの良い点は、BOKのような知識体系よりも、帰納的であり、たくさんの経験を元に普遍化されているので、理解しやすい点にあるだろう。

僕は、パターン言語というアイデアが好きだ。
パターン形式で自分の体験に基づくプラクティスを作り出せるし、そのパターンを他人に広めやすくしてくれる。

パターン、Wiki、XPは良書: プログラマの思索

パターン言語のアイデア: プログラマの思索

パターン言語の構造と事例集: プログラマの思索

アジャイルに効く アイデアを組織に広めるための48のパターン」でパターンに関する興味深い指摘がある。
P.16の「パターンの利用方法」に「初めてパターンを読んだ人は、情報が多すぎると感じるかもしれない」という指摘がある。
つまり、パターン形式には、状況・問題・解決策の3つで十分で、フォースや結果状況、使用例は不要ではないか、ということだ。

しかし、実際にグループでパターン化する議論をしていると、すぐに暗礁に乗りかかった。
ある解決策を用いた時に、副作用として発生する問題はどこに描くのか?
パターンの前提条件となる制約条件はどこに書くのか?
という質問がどんどん出てきた。

ほどなくして、結局、フォースや結果状況などの全てのパターン項目が追加された。
「問題解決に向けて議論していくと、いずれ全てのパターン項目が必要になることを、まさに目の当たりにした」という。

この逸話はとても重要な内容を示唆していると思う。
つまり、アレグザンダーのパターン項目は、単なる思いつきで作られたパラメータではなく、パターンを語る時に必然的に出てくるパラメータなのだ、ということだ。

そして、パターン項目のうち「フォース」がかなり重要であると、最近思うようになった。
以下にもその理由が書かれている。

パターンとフォースとぎゃー! - 反言子

(引用開始)
8. フォースが問題を定義する
形式上、問題がまず初めに来るので、作者は時折、解法を書く前に問題を記述する。
だが、これもまた問題を含んでいる。
解法をよく理解しないままに、問題を衝動的に記述する。
しかし、作者が解法について詳細に考え抜かない限り、そのような問題の記述はあいまいで、非常に大雑把なもになりがちだ。

問題と解決の結びつきが重要であることはわかっている。
僕はこの手の話が好きなので「問題こそ重要である」という考え方にはなじんでいる。
しかし問題を定義することは難しい。
なるほど、解法がわからない、衝動的に考えられた問題なのだ。

ゆえに問題を記述するためにフォース、そして問題とフォースの関係を考え抜くことが重要になる。
パターンが単なるマニュアルでない理由としてフォースの存在が語れることにも納得がいった。
(引用終了)

【4】各パターンのメモ

アジャイルに効く アイデアを組織に広めるための48のパターン」の各パターンを読むと、ああそういう意味だったのだな、と経験が整理される気がする。
以下、本の文章を踏まえて、自分の理解と体験を踏まえてメモしてみる。

◆全体に関わるパターン

(1)Evangelist : エバンジェリスト(1)
新しいアイデアを持ち、熱意を持って普及させたいと思う人。

(2)Small Successes : 小さな成功(2)
チームに小さな成功を植えつけて、意気を上げる。
チケット駆動開発なら、完了したチケットが必ず記録されるので、後から自分の実績をふりかえれば自信になる。

(3)Step by Step : ステップバイステップ(3)
トップダウンで一気にやらない。
ボトムアップで少しずつ広めていく。
お試し期間(47)や便乗(21)を使う。

Redmineによるチケット駆動開発は、ステップバイステップで実行しやすい。
運用しながら、ワークフローを修正したり、チケットの項目を追加したり、運用ルールを変えていくことは柔軟に可能。

(4)Test the Waters : 予備調査(4)
あなたは新しいアイデアに興奮して、エバンジェリストになりたいが、新しいアイデアが組織に合うかどうかまだ分からない時に使う。

(5)Time for Reflection : ふりかえりの時間(5)
定期的に評価し、フィードバックを得る。

「なぜ、ふりかえりが必須なのか、自明ではないかもしれない」。
しかし「走りながら考えればいい、経験からの学びは無意識のうちに積み重ねられていく」という考え方は、現実にはうまくいかない。
定期的に活動を評価し、学びの機会を作らなければ、同じような間違いを何度も繰り返す。

◆序盤の活動に関わるパターン

(6)Ask for Help : 協力を求める(6)

(7)Brown Bag : ブラウンバッグ・ミーティング(7)
ランチミーティングのこと。
日本なら、ノミニュケーションに相当するだろうか。

(8)Connector : コネクター(8)
(9)Do Food : 何か食べながら(9)
(10)e-Forum : 電子フォーラム(10)

(11)Early Adopter : アーリーアダプター(11)
新しいアイデアのオピニオンリーダーになりうる人々。

(12)External Validation : 外部のお墨付き(12)

(13)Group Identity : グループのアイデンティティ(13)
チームや活動に名前をつけること。
例えば、@daipresentsさんは自分のチームに「特攻野郎Aチーム」という名前をつけていたのを思い出す。
また、スティーブ・ジョブズも、Macチームに海賊の旗を掲げていた。

(14)Guru on Your Side : 達人を味方に(14)
組織のメンバーに尊敬されているシニアレベルの人々を味方にする。

(15)In Your Space : 空間を演出する(15)
「見える化」のこと。

(16)Innovator : イノベーター(16)
新しもの好きの同僚。
新しいというだけで好奇心をそそられ、興奮する人々。

(17)Just Do It : やってみる(17)
新しいアイデアの利点や限界は、自分自身の経験から情報を集める。
自分が今やっている仕事にそのアイデアを試して、評価してみる。

(18)Just Say Thanks : 感謝を伝える(18)
協力してくれた人々に感謝の気持を伝える。

僕が過去にKPTによるふりかえりを実施した時、女性SEや女性PGから、Keep欄に、他メンバーに感謝の気持を伝えるPostItが貼られた時がある。
感謝された人はさぞかし嬉しかっただろうと思う。
そんな表現だけでも、チームは和むし、一体感が高まる。

(19)Next Steps : 次のアクション(19)
アイデアをToDoリストに落とすこと。

(20)Personal Touch : 個人的な接触(20)
新しいアイデアの価値を伝えるために、技術的な利点よりも、個人や組織のニーズを理解する。

(21)Piggyback : 便乗(21)
自分のアイデアを既存の慣習に追加機能として載せることで、コストやリソースを減らす。
新しい取り組みよりも、改善として導入する。

Redmineによるチケット駆動開発では、普通、現場の作業ルールをそのままワークフローに当てはめて、運用を開始する。
つまり、AsIsのワークフローから開始して、少しずつ改修しながら、あるべき姿(ToBe)のワークフローへ変えていく。

(22)Plant the Seeds : 種をまく(22)
勝間和代氏が提唱している「Giveの5乗」と同じ。

(23)The Right Time : 適切な時期(23)
イベントの時期や助けを求める時は、タイミングを考慮する。

アジャイル開発では、イテレーションごとに、ふりかえりでフィードバックを得たり、次のアクションを考えるタイミングが取りやすい。
しかし、WF型開発は、実際は、ふりかえりや改善実施のタイミングが取りにくい。
なぜなら、工程単位に前工程のふりかえりやそれをうけた対策を考えたいが、普通は仕様変更や五月雨式のWF開発が多いので、メンバーが常に忙しく、まとまった時間を取るのが非常に難しいから。
結局、プロジェクト完了時の1回だけしか、ふりかえりが行われず、チームが解散するために、せっかく得られた知見や改善案も生かされない。

(24)Stay in Touch : 定期的な連絡(24)
(25)Study Group : 勉強会(25)


(26)Tailor Made : テイラーメイド(26)
新しいアイデアを採用する時、組織のプロセスとゴールを事前調査して、イノベーションが解決できるニーズや問題に適用する。

(27)Big Jolt : 著名人を招く(27)
今なら、アジャイル開発の有名人やアジャイルコーチを呼んで、組織変革を支援してもらうようにする。

◆中盤以降の活動に関わるパターン

(28)Corporate Angel : 経営層の支持者(28)

(29)Dedicated Champion : 正式な推進担当者(29)
組織で認められて、予算と権限を与えられたエバンジェリスト。
新しいアイデアの組織導入を効果的に進めたいなら、ボランティア活動だけでは身が重い。

(30)Early Majority : アーリーマジョリティ(30)
組織内に強力な足場を構築してくれる「より慎重なマジョリティ」。
門番(ゲートキーパー)であるイノベーターやアーリーアダプターだけでは、組織変革は不十分。

(31)Guru Review : 達人のレビュー(31)
組織のメンバーに尊敬されているシニアレベルの人々によるレビューチームを作り、新しいアイデアを評価してもらい、他の聴衆に影響させる。

(32)Hometown Story : 体験談の共有(32)
新しいアイデアの有用性を体験談で共有し、形式知として表出化する。
体験談という暗黙知の共有。
SECIモデルの一例。

僕の現場では、KPTによるふりかえりで、成功や失敗の体験談を共有する場合が多い。

(33)Involve Everyone : みんなを巻き込む(33)
イノベーションが一人の人や小さい集団のためだけではなく、組織全体のためにある。
より多くの人に新しいアイデアを「自分ごと」として認識してもらう。
それによって、心から取り組んでくれるだけでなく、貢献したいという力強い感情を生み出し、組織と個人のつながりも強化する。

(34)Just Enough : ちょうど十分(34)
新しいアイデアを学んでもらうには、学習曲線を考慮する。
段階を経て正しく理解してもらう。

Redmineによるチケット駆動開発では、運用ルールを1回説明すれば、その後は細かい説明は不要で運用できる利点がある。

(35)Local Sponsor : 身近な支援者(35)
現場のマネージャに協力を求める。
経営層や下々の人々よりも、中間層のマネジメント職の支援があってこそ、新しいアイデアは現場での仕事のやり方として正式に認められる。
パトロンに近い。
実は、プロジェクトリーダーやプロジェクトマネージャが、組織変革の抵抗勢力になってしまう場合が多い。

(36)Location, Location, Location : 場所重要(36)
半日以上かかるイベントは、仕事の現場を離れて、別の場所で開催する。

(37)Mentor : メンター(37)
新しいアイデアを理解して、チームを手助けできる人。
守護者、ファイアーウォールに近い。

(38)Royal Audience : 謁見(38)
(39)Shoulder to Cry On : 相談できる同志(39)

(40)Smell of Success : 成功の匂い(40)
新しいアイデアが成功し始めると、新参者がイノベーションについてエバンジェリストに尋ねてくるようになる。
そんなときは、教えるタイミングとして捉えよう。

(41)Sustained Momentum : 勢いの持続(41)

(42)Token : トークン(42)
名札のこと。
新しいアイデアを思い出させる小さな名札。
例えば、マグネット、ボタン、カップ、鉛筆、リングノート、クイックリファレンス、記事のコピーなど。
他にも、アバター、ツールのロゴ、ニコニコカレンダーなどが挙げられるだろう。

Redmineにもアバタープラグインがある。
担当者のアバターがあるだけでも、ツールへの関わり方は違ってくる。

◆抵抗と付き合うためのパターン

(43)Bridge-Builder : 橋渡し役(43)
新しいアイデアを受け入れた人を、まだ受け入れてない人に引きあわせて、イノベーションの有用性を受け入れてもらう。

(44)Champion Skeptic : 懐疑派代表(44)
エバンジェリストのアイデアに懐疑的なオピニオンリーダーに、公式な懐疑派の役割を演じさせる。
新しいアイデアの問題点を指摘するように促し、その問題に対処する。
但し、結果状況が悪くならないように注意が必要。

(45)Corridor Politics : 根回し(45)
重要な決議の前に、影響のある意思決定者に非公式に接触して、承認へのストーリーを作る。
文字通り、根回し、腹芸のこと。

(46)Fear Less : 怖れは無用(46)
抵抗勢力を新しいアイデアの強みに変える。

(47)Trial Run : お試し期間(47)
新しいアイデアのトライアル期間。
新しいアイデアを検証する。

(48)Whisper in the General’s Ear : 将軍の耳元でささやく(48)
集団の前でマネージャを説得できない時、非公式な場所でマネージャに懸念点を教えてもらう。

【5】「アジャイルに効く アイデアを組織に広めるための48のパターン」で面白いのは、エバンジェリストをサポートする人々の役割にたくさんのパターン名が付けられていること。

エバンジェリスト(1)、正式な推進担当者(29)がこのパターン言語の主役。
組織内には、コネクター(8)、アーリーアダプター(11)、達人、イノベーター(16)、経営層の支持者(28)、アーリーマジョリティ(30)がいて、彼らに働きかける。

エバンジェリストの味方には、著名人、身近な支援者(35)、メンター(37)、相談できる同志(39)、橋渡し役(43)がいる。
抵抗勢力には、懐疑派代表(44)がいる。

それら役割に相当する人は組織内の誰なのか、をマッピングしておけば、組織変革のどの時点ではキーマンは誰か、を考えるきっかけになりうる。

役割に相当するパターン名を調べてみると、非常によく考えられているなあ、と思う。
他にも色々考えてみる。

| | コメント (0)

2014/03/08

【告知】XP祭り関西2014で「KPTによるプロセス改善~あなたはPDCAを回したことがありますか?」を講演します #xpjugkansai

4/26(土)に開催されるXP祭り関西2014で「KPTによるプロセス改善~あなたはPDCAを回したことがありますか?」を講演します。

【参考】
XP祭り関西2014 - XPJUG関西wiki

XP祭り関西2014 ~やってみよう!XP~ - 日本XPユーザーグループ関西 | Doorkeeper

【内容】
--- * --- * --- * --- * --- * --- * --- * --- * --- * --- * --- * ---

・タイトル : 「XP祭り関西2014 ~やってみよう!XP~」

・開催日時 : 2014年4月26日(土) 10:45~17:00 (受付開始10:00)

・開催場所 : 大阪市鶴見区民センター

・定員   : 200名

・参加費  : 無料です。カンパ(書籍 または ワンコイン500円)受け付け中。
  是非よろしくお願いします。
  ※ 懇親会は有料。

・懇親会  : お一人様4,500円
  (素敵な景品が当たるかも!?「大ジャンケン大会」開催!)

--- * --- * --- * --- * --- * --- * --- * --- * --- * --- * --- * ---

■メイン会場 - 定員200名

【オープニングセッション (タイトル未定)】

 ・前川 直也氏
 ・西河 誠氏
 ・細谷 泰夫氏

昨年出版されました、「わかりやすいアジャイル開発の教科書」の著者のお3名に
ご登壇頂きます。

当日、皆様からのご質問にお答えする時間を設けますので、アンケートに書籍の
内容や、アジャイルに関するご質問、お悩み、課題など、ご記入願います。

【講演1 今日から始めようXP】

 ・稲田 信平氏

  開発の現場でどのようにXPに取り組んだかとこれから始める方、
  再チャレンジされる方へのメッセージ

【講演2 ビジネスモデル・キャンバス入門】

 ・山中 美智子氏

  翔泳社刊「ビジネスモデル・ジェネレーション」をベースに組織や
  個人のビジネスモデルを見える化し、共有・分析する「ビジネスモデル
  ・キャンバス」についてお話します。
  ちょっと毛色の違うセッションですが、ビジネスアイディアを持っている方も、
  独立を考えている方も、何かを企んでいる方も、そうでない方も、時代の
  「変化ヲ抱擁」するために。必聴です!

【講演3 XP入門と導入の壁についての話】

 ・平田 大作氏

  ウォーターフォールをダシに、XPがどんな問題をどんな考え方で解決
  しようとしているか、という見方でもってXPの入門的な話をします。
  また仕事で導入する際の壁について、これまでの経験からいくつか話を
  したいと思います。

【講演4 KPTによるプロセス改善~あなたはPDCAを回したことがありますか?】

 ・あきぴー氏

  プログラマから現場のプロジェクトリーダーへ役割が変わった時、チームを
  スムーズに運営できないタイプの人がいます。
  第三者から眺めてみると、その原因は、プロジェクトリーダーがチームで
  プロセス改善を実施した経験が1回もないパターンが多いように見受けられました。
  本講演では、PDCAによるプロセス改善にKPTというシンプルなフレームワークが
  大変有効であること、さらに、メンバーの自発的行動を促進する効果とその仕組み
  についてお話します。

【ライトニング・トークス】(3名)

 *募集中

 *ライトニング・トーク希望者はLT応募ページから応募してください。
 (※先着順とさせて頂きます)

■アジャイル和室

【アジャイル和室】 - 常時開催

 ・世界初「アジャイルかるた」開催。
 ・皆様からカンパ頂きました書籍の閲覧コーナーを設置します。
 ・ピアソンを偲ぶ会
 ・UST中継(実施予定)
  など。
--- * --- * --- * --- * --- * --- * --- * --- * --- * --- * --- * ---

| | コメント (0)

2014/02/28

TOCの思考プロセスの使い道~プロマネの説明責任に応用する

ゴールドラット博士の論理思考プロセス―TOCで最強の会社を創り出せ!」を読んで、TOCの思考プロセスをプロマネの説明責任に適用できそうな気がした。
ラフなメモ書き。

【1】背景
【1-1】プロジェクトマネージャの仕事のほとんどは、利害関係者の間で発生する課題の解決、ないし利害関係者への調整だ。

例えば、顧客は、システムのこの要件は納期までにリリースされないと困る。
しかし、開発チームは、その要件は実現可能性が難しく、納期までに間に合わない、と言って、対立が生じる。

あるいは、テスト工程で一挙に問題が噴出し、要件漏れ、設計漏れ、単体テスト漏れなどの障害が多発し、何が問題なのか、という構造も見えなくなる時もある。

プロジェクトにまつわる色んな問題は、どんな構造を持っているのか?
利害関係者同士で対立が発生した時、どのように解決するのか? あるいは調整するのか?

【1-2】自分自身の体験としてはPMOのような役割でプロジェクト支援に入った時に、いつも気になることがある。
それは、利害関係者ごとに問題の観点が違うので、それを解きほぐし、本来の問題とゴールを導いて、納得してもらうのに、ものすごくパワーがかかること。

例えば、部課長であれば、プロジェクトが黒字になるように仕事してくれ。
プロジェクトリーダーならば、納期までに無事にリリースしたい。
新しい技術が好きなプログラマならば、新しい技術を試したり、自分の華麗なコーディングを見せつけたい。
新人プログラマならば、先輩のように、自分も早くアウトプットを出して、能力があるのを見せたい。
皆の立場で、プロジェクトに対する意識は全く違う。

最近、TOCの論理思考プロセスの対立解消図でこんな一節があった。
「対立は現実には存在しない。認識の中にだけ存在する」

まさにそうで、利害関係者の頭にある現実が衝突しているだけ。
彼らの頭にある前提条件を崩せば、対立は消える。
そのために、いかに彼らを説得し、世界観を変えてもらうか、にすごくパワーが要る。

説明のロジックとして、対立解消図が使えないか、色々探っている。

【2】TOCの思考プロセスには、5つのツールがある。

【2-1】現状分析ツリー

現状分析ツリーは、現状の問題点から原因をツリー構造で深掘りしていく手法。
原因と結果のロジックを突き詰めて深掘りしていく。
個人的印象としては、ロジカルシンキングで問題を深掘りしていくのに似ている。

以下の記事が詳しい。

要求工学 第27回:論理思考プロセスと現状分析ツリー(要求工学:Requirements Engineering)

思考プロセス入門(3) 現状問題構造ツリーの作成方法 | TOC | 飯塚革新コンサルティング

問題認識の手法4―現状分析2: サラヒン ~ サラリーマンによるサラリーマンのための仕事のヒント

問題解決の7ステップ1: サラヒン ~ サラリーマンによるサラリーマンのための仕事のヒント

現状分析ツリーで面白い点は「問題は2つの原因を持っている」という特有の考え方があるらしい。


(引用開始)
この思考プロセスで目からウロコが落ちたのは、

 ・問題は単独では発生しない
 ・問題は2つの原因を持っている

というところ。
これからすっかりTOCの信者になりました。
(引用終了)

(引用開始)
このTOCを学ぶ前までは、すごく単純に

 原因 → 問題

のような図式で考えてました。つまり、ある問題にはたった一つの原因がある。
(中略)
ところが、多くの業務をする上でのプロセスというのは、非常に複雑なので、このプログラムのような単純な要因になるものではありません。その時に、

 ある事象とある行為が重なると問題が起きる
 ある行為とある行為が重なると問題が起きる

という考え方が、TOCにはあります。
(引用終了)

現状分析ツリーでは、問題を引き起こす原因が2つ以上あった場合、OR条件、AND条件、増幅条件の3つで表現する。
OR条件は、原因がそれぞれ独立している。
AND条件は、複数の原因が同時に発生して、初めて問題が現れることを意味する。
増幅条件は、複数の原因が加算されて増幅されることを意味する。

これらの原因には微妙な違いがあるので注意。

現状分析ツリーでは、「もし~(原因)~ならば~(問題)~になる」と読む。
その内容で、なにかおかしいと感じたら、論理に破綻が生じているので直す。

現状分析ツリーの使い道は、問題の症状と原因の構造を明確にすること。
それは、問題が起きている現状のスナップショット。
根本原因を突き止めることで、問題を引き起こす制約条件を見つけることができる。

普通は、悪循環の構造を持つ問題が発生したら、その構造を壊すような変化を与えることが解決の糸口。
つまり、故意に変化を起こすことが解決方法の一つ。

問題の構造を壊さなければ、現状は何も変わらないから。
その時に、制約条件を突き止めることが出来れば、その部分をいじることで、変化を起こすことができる。

【2-2】クラウド(対立解消図)

例えば、対立している状況では、2つの選択肢のどちらかを選ばなくてはいけないが、どちらの選択肢も全ての利害関係者を納得させられない。
あるいは、対立が隠れており、そのために現場が停滞している状況もある。
後者は、問題が認識されているにもかかわらず、どうやっても解決できず、無力感が漂う状況などがある。

普通は、対立した状況では、妥協ないし、どちらかの選択肢を選択してWin-Loseの関係にする場合が多い。

このような対立の状況から、Win-Winの解決策を可能にするのがクラウド。

クラウドの別名は対立解消図。
ある目的(ゴール)に対し、利害関係者が相反する要求を出し、対立を起こしている構造を明確にする。

クラウドでは、ゴール←2つの要件←2つの前提条件 という構造で表し、2つの前提条件が対立しているように表示する。

クラウドによる解決方法は、どちらか又は両方の前提条件を崩し、別の解決方法(インジェクション)で要求を満たすようにする。

対立の解消は、プロマネの調整技法としてとても重要だ。
利害関係者との調整とは、妥協とトレードオフが一般的で、誰かに不満を残す。
クラウドを使えば、相手の前提条件を崩し、新たな解決策を提示して、Win-Winの関係を実現する事が可能。
プロジェクトマネジメント手法として、クラウドは重要な技法の一つ。

【2-3】未来現実ツリー

未来実現ツリーは、リスク対策に使う。

未来実現ツリーは、実施したい変革方法に対し、その影響結果をツリー構造で書いていく。
すると、良い影響もあれば、予期しない結果や、好ましくない結果が出てくる時もある。
つまり、今から実施する対策のシミュレーションとして使える。

【2-4】前提条件ツリー

前提条件ツリーは、PERT図そのものだ。

前提条件ツリーは、目標(ゴール)に対して、中間目標をツリー構造でブレイクダウンしていく。
すると、目標を実現するためのネットワーク図になる。
これがPERT図に相当する。

【2-5】移行ツリー

移行ツリーは、前提条件ツリーで図示したPERT図を具体的な作業手順のツリーへ詳細化したもの。

【3】TOCの思考プロセスが使える状況

上記の思考プロセスを使う状況は下記があげられるだろう。

・「現状分析ツリー」で、問題の構造を把握する or 問題の構造を説明する
・「クラウド(対立解消図)」で、利害関係者の対立を解消し、別の案を提示する
・「未来実現ツリー」をリスク対策の検証に使う
・「前提条件ツリー」「移行ツリー」でプロジェクトの概要スケジュールを作る

つまり、プロマネがやるべき仕事において、これらのツールはとても有効だ。
顧客や上司、開発チームのメンバーに対し、以下のような説明をする時が多い。

現状の問題の構造はこういうものだ。だから、この構造の背後にあるこの制約条件を壊してみよう。

2つの意見の対立は実はこういう構造を持っているが、実は、この前提条件は正しくなくて、このように考えれば、こんなアイデアで解決できる。

この対策を実施すると、こういう好ましい効果が得られるが、副作用として、このような不都合な結果も出てくるから、注意しよう。

この目標に対して、中間目標(マイルストーン)はこれこれであり、それぞれはいつまでに終わらせないといけないのが分かるよ、と。

こういう説明を論理的に行い、理解してもらうことで、人は初めて動く。
特に、IT業界のように能力の高い専門家集団の場合は、威圧的に一方的に指示を出せばメンバーが動くわけではない。
むしろ、論理的に説明して納得してもらって、メンバーの能力を引き出せるのだ。

まだ実際の経験が足りないので、以上のアイデアを試してみる。

| | コメント (0)

より以前の記事一覧