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

2020/04/01

オンラインのリーダーシップとは何だろうか

リモートワークの推進によって、リーダーシップの振る舞い方も変わってきているように思う。
オンラインのリーダーシップの概念が必要になっているように思う。
ラフなメモ書き。

【1】リモートワークのノウハウについては、倉貫さんの会社が日本で一番持っているのではないだろうか。

[議論]新型コロナでリモートワーク急拡大、でも少し変じゃない?:日経ビジネス電子版

相手に「伝わる」ビデオ会議、14の鉄則。全社員リモートワークのソニックガーデンに聞く | iXキャリアコンパス

リモートワークで生産性を上げる仕組みやノウハウが非常に細かく書かれていて参考になる。
そんな記事を読んでいると、いくつか疑問が出てくる。

今までは会社、学校というオフラインの場所で、仕事や教育を行ってきたし、その仕組みに特化するように、洗練されていた。
しかし、昨今のコロナウイルス流行の影響でオフラインの場所を確保できない状況になり、一時的であっても、オンラインで仕事や教育を実施する必要性が出てきた。
すると、感染症が終わって正常の世界に戻った場合、既にリモートワークで生産性が上がっているならば、以前のオフラインの世界に戻る必要はない。
その意味では、現在の感染症は、オフラインの仕組みに依存してきたビジネスモデルそのものも劇的に変更されるだろう。
もはや会社や学校という物理的な場所はなくてもビジネスも教育が回るからだ。
感染症が終わった後の世界では、会社も学校も大きな環境変化が生じているだろう、と推測する。

【2】では、オンラインとオフラインの環境の本質的な違いとは一体何だろうか?

オンラインの作業についての問題点もいくつか出ている。
その問題点は、技術的課題と適応的課題の2つに分けられるだろう。

技術的課題は、オンラインのツールに慣れない、普及しない、環境が揃っていない、など、技術を克服すれば解決できるもの。
たとえば、「強い者や賢い者よりも変化に速い者が生き残る」という言葉は、まさに、オンラインの環境にいち早く適用した人ほどその利益を得やすい事実を示唆していると思う。

一方、適応的課題は、そういうツールや環境が揃ってきた上で、コミュニケーションや意思疎通をより深く太くしていく為には何が必要なのか、それぞれの現場や人、組織に依存したもの。
これらは、コンテキストに依存している場合が多いだろうから、出てきた課題を一つずつ皆で解決しながら、課題のレベルを上げていくしかない。

上記の記事を読んだ後、いかに一人ぼっちにさせないか、という仕組みが非常に重要になっているような気がした。
オンラインのリモートワークの環境になると、身近に物理的に人がいないので、困った時に声掛けできない。
そのために、Twitterのタイムラインのようなデータを流したり、顔を常時写したり、いろんな工夫がされている。

【3】僕が一番興味を持つのは、オンライン環境ではリーダーはどのようなリーダーシップを振る舞う動作が必要なのか、という問いだ。
あるいは、オンライン上のチームビルディングでは何が必要なのか、という問いだ。

倉貫さんの下記の意見に非常に興味を引いた。

(引用開始)
倉貫氏:改めて考えてみると、これまではなんて牧歌的な時代だったんだろうと驚きますね。チームビルディングを「同じ場所に集まる」という偶発的なものだけに頼って、ほとんど何もやらずにさぼってきたのかと、自分の反省も含めて思います。
(引用終了)

従来のチームビルディングの手法は、オフラインの環境に依存しすぎていないだろうか?
従来の手法をそのままオンライン環境に持っていっても、チームビルディングが上手く行かないのは明らかだろう。

【4】会社、役所、NPO法人、コミュニティなどの集団は、必ず何らかのトップとなる人がいて、彼らがその組織文化を生み出す責任を持っている。

組織文化はトップが作り出すものであり、その逆ではない、と僕は習った。
実際、どんな集団も共通目的があり、その目的に賛同した人たちが結集して、集団の目標を実現しようとする。
そういう集団を最初に作る創始者が組織文化を生み出し、メンバーとの化学反応を起こして集団をより進化させていく。

以前ならば、オフラインの空間では、実際に人が集まってトップの話をうやうやしく聞いたり、あるいは、実際にトップが自ら動いて汗をかく場面を見て、メンバーの貢献意欲が刺激されて、一致団結していく、などの事例があった。
しかし、オンラインでは、トップの行動も話も声もPCの画面を見なければ伝わらない。
TV演説に近い部分もあるかもしれない。
以前のオフラインのリーダーシップの発揮方法とは本質的に異なっている気がする。

特に、昔ながらのリーダーシップの発揮方法である「制度的リーダーシップ」は、オンライン環境では非常に難しくなっていると思う。
つまり、役職を前提としたリーダーシップは、オンライン環境ではその権力を影響させにくい。
オンライン環境では、社員が真面目に働いているのか、を管理職が逐一監視するのは難しいからだ。

制度的リーダーシップの考え方が何となくしっくりきた: プログラマの思索

最近では、トランプ大統領がツイッターでどんどん発言することで影響力を増しているように、オンラインのリーダーシップの発揮方法はいくつかのやり方があるように思う。
一方、オープンソースの開発のように、最終的に意思決定するリーダーがいたとしても、世界中に散らばった開発者の技術力を結集して、優れた成果物を作っていくやり方もある。

いずれにしても、まだ僕の中ではスッキリした答えは持っていない。
でも、世界を見渡せば、オンライン環境でもリーダーシップを発揮して、メンバーをあるべきゴールへ導くようにメンバーの意欲を向上させることができているリーダーもいる。
彼らはどんなやり方を使っているのか、そのやり方の本質的な特性は何なのか、考えてみる。


| | コメント (0)

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)

より以前の記事一覧