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

2020/05/17

オンライン勉強会のノウハウのリンク

最近の勉強会は、オンライン配信する時が多い。
友人からオンライン勉強会のノウハウを聞いたので、リンクをメモ。

【参考】
Zoomを活用してOSC2020 Online/Springを開催しました - 宮原徹の日々雑感

Zoomで開くオンラインイベント入門

アットホームな感じの オンラインイベントの配信を意識してみた

20200326 meetup video shooting meetup vol2 kitazaki いつも持ち歩ける ワンオペ配信機材

なぜ Infra Study Meetup運営は配信トラブルを引き起こしてしまったのか - Forkwell Press

オンライン勉強会に参加したり、自分たちが主催になった立場で経験してみると、いくつか気づきはある。

良かった点は、2つある。
一つは、東京など遠方の勉強会であっても、参加しやすくなったこと。
今まで行きたかったのに東京だから無理だ、という障害がなくなった。
また、参加者は全国が対象になったので、多数の参加者を集めることも可能になった。
さらに、会場費用も不要なので、勉強会のコストはせいぜい、Zoom管理費用をサブスクリプションで払うぐらい。

もう一つは、コロナ感染防止による自粛で外出できなくなっても、毎日どこかでオンライン勉強会が開催されているので、参加すれば、孤独感を感じることはなくなった。
むしろ、以前よりも頻繁に勉強会に参加しやすくなったし、以前と同じ交流ができた。
休日ならば、1日間に3回もオンライン勉強会をハシゴすることも可能だ。
実際経験してみたら、朝から晩までノートPCにしがみついているので疲れた。

他方、課題や留意点はいくつか感じる。

1つ目は、それなりの機材や環境は必要であること。
通信速度は100M以上は欲しい。
回線が細いと、ビデオも音声も途切れがちになり、お互いのコミュニケーションがやりにくくなる。

ノートPCにカメラは付属しているけれど、音声はヘッドセットが別途あった方がいい。
ハウリングしたり、自宅のノイズを拾ってしまうから。
片耳にかけて会話も出きるBluetooth ワイヤレスヘッドセットがあると便利。

2つ目は、Zoomなどのツールを使いこなすこと。
Zoomの管理機能はまだよく分からないが、部屋を作って参加者を分けたり、とか、割と機能が豊富みたい。
他にも、GoogleHangoutやSkype for businessなどある。
それらのツールでどこまで使いこなすのか、まだ理解している途中。

また、ビデオで会話するだけでなく、チャット機能やチャットツールも欲しくなる。
だが、オンライン勉強会を主催する立場になると、Zoomのようなビデオツール、参加者とやり取りするためにslide.ioやTwitterなどのチャットツール、スタッフ同士で裏でやり取りするMessengerやSlackなどが必要になってくる。

すると、Zoom、slide.io、Messengerの3つのチャネルを随時見ないといけないので、ノートPC以外にタブレットやスマホなども総動員して、3つ以上の通信機器を机に広げることになる。
つまり、割と大変なのだ。

3つ目は、オンライン打合せのファシリテーションスキルが必要になっていること。
対面の打合せでもファシリテーションは必要だが、オンラインになると、どうしても一方通行になりがち。
いかに参加者から活発な発言を促して発散させるか、そしてその議論を収束させていくか、オンライン特有のファシリテーション技術が必要な気がしている。

対面のファシリテーションでは、ホワイトボードやPostItが有効だったが、オンラインではそれらツールが使えない。
エディタやGoogleスプレッドシートを画面共有したり、マインドマップをツールで書いたりする。

オンライン・ホワイトボードは下記のツールがいいよ、と、坂根さんから教えてもらった。

便利なオンラインホワイトボードサービスmiro(ミロ)の使い方の基本

ファシリテーションでは、人間的なスキルだけでなく、こういうツールを使いこなす技術も必要なのだ、と気づいた。

たぶん、こういうツールや課題は、今はまさに発展途上な状態。
来年になれば、当たり前になっているかもしれないし、まだ先のノウハウも生まれているだろう。
いろいろ試してみたい。


| | コメント (0)

2020/05/04

Redmineとチャットツールはどのように使い分けるべきなのか

「Redmineとチャットツールはどのように使い分けるべきなのか」という疑問についてラフなメモ。

akipiiさんはTwitterを使っています 「第18回勉強会 - https://t.co/i2sJFMEe2v の議題は、やはり、テレワークにRedmineをどのように有効活用して運用できるか、という点と思います。多分Redmineを普段運用していればスムーズに移行できたはず。今回の緊急事態宣言によってRedmineのメリットが明確になったはず。 https://t.co/XHELA5jGsZ」 / Twitter

akipiiさんはTwitterを使っています 「Redmineを利用する一方、チャットツールを皆さんは何を使っているのか、も気にしてます。チケットに書くほどでないコミュニケーションはChatツールを使うならばRedmineとチャットツールを使い分ける基準は何か? チャットが重視されるとRedmineのチケット起票が重く感じられる為。」 / Twitter

y503Unavailable@Redmine Kindle本出版unofficialcookingさんはTwitterを使っています 「@akipii 先月からTeamsですが、チャットはフローでありストックではないことを明確にしています。 相談程度はチャットで軽く進め、途中経緯をRedmineにコピペし蓄積。 チケット起票しないと設定しない程度の運用を確立していれば回ると思います。」 / Twitter

齋藤さんはTwitterを使っています 「@y503Unavailable @akipii Teams には、内容のコピペとかコピーとかの配慮があまりなくて、長くなると面倒なんですよね。是非、そこは強化して欲しい。」 / Twitter

門屋浩文@redmineエバンジェリストの会1号さんはTwitterを使っています 「@akipii ストックとフローの話はどこかでやりましょう コミュニケーション設計からコストを下げるような」 / Twitter

たけちゃんさんはTwitterを使っています 「@akipii @MadoWindahead chatはTeamsを使ってますが、コミュニケーションとタスク管理で用途を分けているつもりが、プロジェクト毎に線引きが異なって来ました。Teamsもシェアポイントでのファイル共有ができるので、ちょっとしたファイルはこっちでやり取りしちゃう人も出てきます。」 / Twitter

akipiiさんはTwitterを使っています 「@ta_ke_chan_ @MadoWindahead そう、よく分かります。GSuiteを使ってると、Google Chat, HangoutMeetを使ううちにGoogleスプレッドシートなどで課題管理やタスク管理し始めてしまったり。ツールの利用シーンはどうしても組織文化が出てくる」 / Twitter

門屋浩文@redmineエバンジェリストの会1号さんはTwitterを使っています 「@akipii @ta_ke_chan_ そう、GSUITE派なのでどうしても二次元管理が横行してます 二次元で大丈夫なものはそれでもいいと判断したいので、redmineがいいパターンを出したい あと、chatやSNS系(salesforceなど)の長所短所もまとめればいいのかな? たけちゃんはhttps://t.co/EeqCzfWvkz参加ですね よろしくお願いします」 / Twitter

neta @ redmine.tokyo 5/23(土)オンラインやりますさんはTwitterを使っています 「@MadoWindahead @akipii @ta_ke_chan_ ウチは G Suite 『Google ( Hangout ) Chat』なので、まずは Redmine の通知を連携することからはじめたいと思ってる」 / Twitter

テレワーク中のシロくまさんはTwitterを使っています 「テレワークができる環境づくりに役立ったもの ペーパーレス⇒プロジェクト管理(Redmine) コミュニケーション⇒チャット(Microsoft Teams 秋から会社方針でGoogle Meets) 固定電話⇒クラウドPBX(Dialpad) 次は仮想オフィスツールがねらい目でしょうか。」 / Twitter

吉澤さんはTwitterを使っています 「パン工場じゃ無理だけど、WBS書いて、redmineでチケット切るようになれば、日本の事務職の生産性は飛躍的に向上すると思う。 https://t.co/E6V2xJhGIZ」 / Twitter

【1】昨今、急にテレワークの作業環境を強いられた場合、Redmineのようなプロジェクト管理ツールでプロジェクト運営していなかったら、案件で開発するのは非常に難しいだろう。

一方、従来からRedmineでプロジェクト運営していたら、VPNさえ確保できれば、オンライン上で作業の管理を継続できるので、スムーズに移行できているだろう。

しかし、日々にコミュニケーションはオフラインのチャネルが全て駄目になったので、オンライン上で何かしらのコミュニケーションが必要になってくる。
もちろん、Redmine単体でチケットのやり取りを通じて、日々の課題やタスクは管理できるが、それだけではコミュニケーションは足りない。
たとえば、非公式なコミュニケーション、ZoomやGoogleMeetによるオンライン打合せを補強するチャットなどでチャットツールが欲しくなる。
おそらく一般には、Slack、MSならTeams、GooleならGooleChat、他に、FB Messenger、LINE、Discordなどが使われているだろう。
つまり、Redmineのようなプロジェクト管理ツールだけではプロジェクト運営は不十分であり、もっと気楽でレスポンスの早いチャットツールが必要ではないか、と思われる。

【2】では、Redmineとチャットツールはどのように使い分けるべきなのか?
また、Redmineとチャットツールを併用することでどんな問題が噴出して、どんな課題が出てくるのか?

「顧客ごとにチャネルがこれだけ違うとは。リアル過ぎて参考になる。RT @_alimika_: 顧客A→Slack 顧客B→Facebook Messenger 顧客C→Chatwork 顧客D→Microsoft Teams 顧客E→メールオンリー 顧客F→Backlog オンリー 顧客G→Confluenceオンリー 顧客H→Redmine オンリー 顧客I→GitHubオンリー」 / Twitter

【2-1】一般には、Redmineのチケットは記録して残す内容、チャットは日々流れて消えてしまう内容、というように使い分けているだろう。
しかし、その使い分けは人によって様々に異なる。

Slackでは、数多くのスレッドをチャネルとしてどんどん追加できるので、チーム間や1対1のやり取りが非常にやりやすい。
すると、そのチャットのやり取りだけで、仕事が捗るので、チケットにわざわざ残すのが億劫になる。
チケット上で成果物のレビューをキャッチボールするのが非常に時間がかかるように思われて、チケットに逐一残すのが面倒に感じてしまう。

特に、気心の知れたメンバーであれば、チケット化しなくても、お互いの暗黙知でいい感じに何とかなってしまう時も多い。
すると、課題やToDoがあったとしても、お互いの頭の中に共有されていて、チャットで常に同期されている感覚になる。
わざわざチケットでやり取りするほどでもない、みたいになってしまう。

【2-2】一方、チャットでは大量の発言が流れる場合が多いので、何が決まったのか、どんな経緯で結論に至ったのか、を把握するのが難しくなる。
作業がスムーズに運ぶ場合はチャットで十分だが、試行錯誤しながら振り返りを参考にして進める場合には、何かしらのログを残したくなる。
しかし、チャットで議論した内容をチケットにまとめる作業は割と手間はかかる。
その手間とチケットの起票更新のコストのトレードオフを無意識に計算しているような気もする。

他方、Githubでプルリクをやり取りするプロジェクトであれば、ソースコードのコミットとプルリクが重要であるから、その部分は必ずチケット化される強制力は働く。

【3】Redmineとチャットツールの間の情報連携にも、いくつか問題や課題はある。

【3-1】ITS(Redmine)→チャット(Slackなど)へ連携する運用は多い。
その理由は、Redmineのチケット・Wiki更新の通知をメールではなく、チャットで把握したいからだ。

Redmineの通知メールは正直うっとうしい。
たとえば、コメントなしの単純なステータス更新、項目更新だけでも通知メールが飛ぶので、プロジェクトが活発になると、1日100通以上のメールが飛び合うのはよくある。
大量のメールに更新内容が埋もれてしまうよりも、チャットで流れた方が正直扱いやすい。

【3-2】一方、チャット(Slack)→ITS(Redmine)の情報連携は手作業でやるのが多い。
REST APIを駆使すれば、チャット内容をチケットに起票できるだろうが、チャットの手軽さの文化と合わない気はする。

しかし、チャットで議論された内容をチケットに記載したい場合は多い。
議論していくうちに、こういう課題は検討すべきだ、とか、ここまでは解決できたから残りはこのToDOだけだね、とか、色々出てくるはずだ。
それらの内容はチケットに残して、誰が担当してボールを持っているか、その課題はどんなステータスにあるのか、を後日把握したいからだ。

そういう運用をしたい時に、チャット→ITSの情報連携をもっと気軽にやりたい課題がある。

【4】Redmineとチャットツールの情報連携の問題点は、たとえば、RedmineやJenkins、GitLabなどの開発基盤の連携とは観点が異なる。

後者は、作業の起点がチケットであり、チケットが更新されていくたびに、Gitへコミットされたり、JenkinsやCircleCIなどでビルドされて、ビルドモジュールがリリースされていく。
つまり、ソースコードという成果物の構成管理が、利用シーンに応じて各種ツールで管理されていくべきだ、という観点になる。

一方、前者は、プロジェクト内のコミュニケーションは、どんなチャネルでやり取りすべきなのか、という点が本質的な観点だ。
議論で発散していくフェーズならばチャット、発散した議論を収束させて検討すべき課題や残タスクにまとめて管理していくならば、Redmineのようなチケット管理ツールが必要になる。
つまり、チームで議論している内容を、チャネルごとに無意識に使い分けているのではないだろうか。

だからこそ、コミュニケーションチャネルをどんな利用シーンでどのツールでやるべきなのか、をプロジェクトリーダーは明確に意識しておくべきだろう。
コミュニケーションチャネルを意識することで、Redmine単体で運用している時よりも、チーム内のコミュニケーションが活発になり、単純な命令伝達だけでなく、メンバーのモチベーション向上も期待できるだろう。

この辺りの事例も色々収集してみたい。

| | コメント (0)

2020/04/01

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


| | コメント (0)

2019/12/28

「マーケティングとは「組織革命」である」の感想

「マーケティングとは組織革命である」を読んで、「組織改革に社内マーケティングの技法を使う」という内容がすごく面白かったのでメモ。
結論のないラフなメモ。

【1】地位が下の立場の人が、自分の提案を通して、組織を変えていくのはとても難しい。
僕も知らない。
でも、この本では、マーケティング技法を社内組織に適用すれば、上手くいくよ、と提示してくれている点が非常に面白かった。

【2】以下、僕の理解を書く。

【2-1】組織文脈
まずその提案は、組織の目的や戦略に合っているのか。
提案の目的に大義がなければ、他人の心に響かない。
目的には、困りごと、不文律や暗黙知、普遍的価値(売上拡大など)がある。

次に、誰が意思決定者なのか?
意思決定者がターゲットになる。

3つ目は、上司のが提案を評価する基準を知っているか?
審判は必ずしもフェアではない。

これらをまず把握して、自分の提案の整合性を取る。

【2-2】ターゲットは2つある
意思決定者がターゲット。
そのターゲットには、組織目的に忠実な人、自己保存に忠実な人の2種類がいる。
成功の鍵は、ターゲットを理解すること。
伝え方の前にターゲット理解が9割。

提案を通すのが下手な原因は、独りよがりであること、ターゲット分析が不十分だから。
なるほど、ターゲットを特定し、そのターゲットの心理変数を分析することが重要なわけだ。

【2-3】便益も2つある
ターゲット2つに対し、その便益も2つある。
公の便益と個の便益。

組織目的という公の便益の観点では、提案が通らない原因は、実現可能性を示すスキルが不足しているから。
これは、なるほどと思う。
コトラーのターゲット設定の条件である測定可能性、維持可能性、実行可能性、到達可能性のうち、実行可能性(実現可能性)を重視せよ、と言っているわけだ。

個の便益という自己保存の利益の観点では、自己保存に忠実なターゲットに対し、実利系の利益を直接示したり、承認欲求の利益を提示することが重要。
ただし、日本人には実利系の利益を見せると建前上断られるので、伝え方が重要。

【2-4】伝える手段は4つある
伝える手段の4つのタイプ、攻撃型、積極型、反応型、消極型それぞれに対して伝え方がある。
この辺りは書籍の中で色々説明してくれている。

だめな営業マンは、客の幅が狭い。
その原因は、自分の相性に客の種類を当てはめすぎ。
無意識に、自分の相性に合う客層を選んでいるから。
つまり、ターゲット設定が狭い。
よって、自分の相性に合わない客にも対処できるように、客の幅を広げていくべき。

| | コメント (0)

2019/12/27

失敗の本質―日本軍の組織論的研究の感想

旧日本軍という当時最先端の高度な官僚組織が日本を破滅に陥れた原因を、組織論に求める、という内容だった。

(1)7つの失敗事例の詳細は、地図を見ながら読まないと完全理解できないと思うけど、失敗に至った話を読むと、とても身に沁みるように感じるのは、たぶん、自分も古い日本の大企業にいるからかもしれない。

改めて思うのは、80年前も今日も、日本のトップは、巨大な官僚組織を上手く使いこなすのが下手、ということ。
一人ひとりの部下を動かせても、「組織を動かす」という能力が足りない、という感触を受ける。

日本の大手企業や官公庁のトップは、その大きな組織の重みをコントロールできず、誰も舵を取らないまま暴走してしまい、破滅に向かう。

一方、アメリカや中国は、官僚組織を使いこなすのが上手い感じはする。
その違いは何にあるのだろうか?

| | コメント (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)

より以前の記事一覧