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

2021/02/13

トランザクティブ・メモリーを使え~「プロジェクトをリードする技術 / Project Leading is Skill」の資料はプロジェクトリーダー初心者にお勧め

プロジェクトをリードする技術 / Project Leading is Skill - Speaker Deckを読んで、特に「トランザクティブ・メモリー」が良かった。
良い資料と思ったのでメモ。

【参考】
akipiiさんはTwitterを使っています 「良いスライド資料だなあ。進捗管理で、ボトルネックを常に移動させることは僕も感じていた。プロジェクトをリードする技術 - kakakakakku blog https://t.co/vB5toW5fSy」 / Twitter

プロジェクトをリードする技術 - kakakakakku blog



【1】プログラマ上がりのプロジェクトリーダーは、プレイングマネージャーだと思う。
すると、一人でプログラムを書いたり、自分でバグ修正した方が速いわけだが、それではチームは回らない。
いかにチームを回すか?

上記の資料で良いと思ったのは、アジャイル開発でやればいいんだ、みたいな一本調子ではなく、バランスが取れている所。
たとえば、「計画が得意=クリティカルパスの見極め」は、ガントチャートでも、バックログ管理でも、スプリント管理でも重要だ。

以前、どこかの本で、MSProjectでいちばん重要な機能はガントチャートではなく、PERT図だ、と喝破した記載があって、同意する。
優れたリーダーは、タスクにばらした時に、ネットワーク図をイメージして、どのパスが最短ルートなのか、を頭の中でイメージしている。

ソフトウェア開発が難しいのは、日々の状況によって、クリティカルパスがどんどん変化することだろう。
たとえPJ計画当初にガントチャートを作っても、初めての技術、コロコロ変わる要件、仕様への落とし込みで、クリティカルパスはコロコロ変わる。
つまり、ボトルネックは常に推移していく。
駄目なリーダーはガントチャート保守でボトルネックを見出そうとするが、その作業に追いつかずに破綻する。

【2】チームビルディングも重要な技術の一つ。
タックマンモデルとか色々あるけど、「トランザクティブ・メモリーを大切にしよう」という言葉は僕も同意する。
メンバーの役割分担をリーダーだけでなく、メンバー全員が知って、リレーのバトンを渡すように上手く回す。
そのためには、誰がどんな専門スキルを持ち、誰が暗黙知を持っているのか、を知っておけばいい。

「トランザクティブ・メモリー」は僕は以前は知らなかったので、もっと早く知っておけばよかったと思う。

「トランザクティブ・メモリー」という言葉は、「ビジネススクールでは学べない 世界最先端の経営学」ではなく「世界の経営学者はいま何を考えているのか――知られざるビジネスの知のフロンティア」を読んで僕は初めて知った。

【3】「世界の経営学者はいま何を考えているのか――知られざるビジネスの知のフロンティア」では、トランザクティブ・メモリーの社会実験でこんな話がある。

交際期間が3ヶ月以上の大学生のカップル60組を集めた。
そのカップルの半数はそのまま、残りはランダムな組み合わせのカップルにする。
そして、それぞれのカップルに、記憶力ゲームを試してもらう。

具体的には、科学、歴史、食べ物、テレビ番組などのカテゴリの文章を、カップルは自分の判断で選択して記憶し、どれだけ正確に記憶できていたかを試す。
カップルごとの合計点で評価する。
つまり、記憶作業は1人で行うが、パフォーマンスの優劣はカップルの合計で決まる。

この実験のポイントは、カテゴリ選択時にカップルが相談できないこと。
つまり、カップルはお互いに相手がどんなジャンルを覚えているのか、知らない。

さらに、交際していたカップルと赤の他人同士のカップルをさらに半分に分けて、もう一方には、男性は歴史、食べ物、テレビ番組、女性は残りのカテゴリと指定しておく。

つまり、
①交際しているカップルでジャンル指定のないカップル、
②他人同士でジャンル指定のなかったカップル、
③交際していて男女それぞれが覚えるべきジャンルを指定されたカップル、
④他人同士で男女それぞれが覚えるべジャンルを指定されたカップル、
の4つでランダム化比較試験を行うわけだ。

その結果はどうなるか?

①のカップルの方が②のカップルよりも結果が良くなった。
交際していたカップルの方が記憶力がいい、というのは常識の範疇。
なぜなら、交際していたカップルは、彼と彼女の強みの部分をお互いに知っているので、強みを発揮できるジャンルをお互いに選べばいいから。

しかし興味深いのは、③のカップルよりも④のカップルの方が結果が良かった。
つまり、あらかじめ記憶するジャンルを指定されてしまうと、交際していたカップルよりも、赤の他人同士のカップルの方が記憶力が良かったのだ。

この実験が意味していることは、「ある程度の交際期間を経たカップルは、お互いにどんな強みや弱みを持っているのか、というトランザクティブ・メモリーを自然に持つようになる」ということだ。
たとえば、彼が映画に強いけど彼女は弱い場合、彼女は彼に聞けばいい。
一方、彼女は美味しいレストランはよく知っているが、彼は知らない場合、彼女に聞けばいい。

つまり、Who knows What、誰が何を知っているのか、誰が組織内で特定分野の専門知識や経験を持っているのかを知っていること、というトランザクティブ・メモリーの重要性を示す。

他方、カップルとして自然に形成されたトランザクティブ・メモリーを新しい枠組みで無理に歪めると、非効率を生み出し、カップルの記憶力は著しく落ちてしまう。
むしろ、赤の他人同士のカップルの方が、ジャンル指定だけに基づいて記憶するので、トランザクティブ・メモリーを歪められてしまった交際カップルよりも、はるかに効率的に記憶できたわけだ。

この実験の話を読んで連想したのは、暗黙知を重視する、トランザクティブ・メモリー型の組織文化を故意に歪めた事例は割と多いのではないか、と思った。

たとえば、自社でソフトウェア開発しないユーザ企業やSIでは、大量の派遣プログラマを案件ごとに短期間に総動員してはリリース後に切り捨ている。
すると、案件のプロマネは、トランザクティブ・メモリーに依存しない、属人性のないPJ管理、属人性のない技術で管理したくなる。
そのやり方は、メーカーの単一製品の大量生産方式のように、単純労働者が多い場合には、トランザクティブ・メモリーを重視しなくても、効率的なオペレーション管理を重視すれば成功しただろう。

しかし、ソフトウェア開発のように、暗黙知があまりにも多いビジネスでは成り立たない。
むしろ、苦労して開発してリリースにこぎつけた時、数多くの暗黙知は派遣プログラマに残っているが、彼らが解き放たれたら、そのチームに得られた暗黙知は雲散霧消してしまう。

たとえば、M&Aで買収した企業の社員を、買収元の経営者が勝手に異動させてバラバラにさせてしまうと、せっかく買収先の企業の社員の中であったトランザクティブ・メモリーが破壊されて、M&Aの相乗効果が得られなかった、とか。

うまい例が思いつかないが、トランザクティブ・メモリーを有効活用していない組織や企業は、日本に割と多い気もする。

なお、「世界の経営学者はいま何を考えているのか――知られざるビジネスの知のフロンティア」も「ビジネススクールでは学べない 世界最先端の経営学」の本もお勧め。

| | コメント (0)

2021/01/14

みんなのPython勉強会#65の感想~社会変革の鍵はIT技術者にあるのかもしれない

みんなのPython勉強会#65に初参加してみて、内容がとても良かった。
自分もPythonが理解できるようになったので、その意義がすごく理解できる。
社会変革の鍵はIT技術者にあるのかもしれない、と思った。
結論のないラフなメモ書き。

【参考】
みんなのPython勉強会#65 - connpass

セミナー参加ログ》みんなのPython勉強会#65 2021/1/13(水) 19:00?21:00(オンライン開催) - acokikoy's notes

【1】Pythonのビジネス、データサイエンティストの話、LT、そしてシビテックまで、幅広いテーマでとても興味深かった。
その中で、シビテックの話がとても興味を引いた。

シビテックは、プログラマが市民の立場で、政府や公共機関に出てくる問題をITで解決すること、と理解している。
関さんは、Coder fo japanというOSSコミュニティで活動されている。
東京のコロナ感染のWebサイト構築で一躍有名になった。

都内の最新感染動向 | 東京都 新型コロナウイルス感染症対策サイト

また、台湾のIT大臣のオードリーさんがGithubにプルリクを送ったことでも注目された。

ソフトウェアの政治的影響力とは何だろうか: プログラマの思索

関さんの話によると、日本では、2011年の東日本大震災の時にシビテックに関わるプログラマが増えて注目を浴びたらしい。
さらに、昨今のコロナ感染状況の期間で、関さんのいるSlackメンバーは、約4倍以上の人数に増えた、とのこと。
つまり、社会の危機的状況が、プログラマをシビテックに関与しようというモチベーションを与えているわけだ。

では、なぜそんな状況でプログラマは、シビテックに関わろうとするのか?
理由は色々あるだろう。
たぶん、人間としての生存本能が現れるのではないだろうか。

こういうOSSコミュニティは、IT技術者にとって、とてもメリットがある場だ。
理由は、自分とは違うバックグラウンドを持つ技術者と関係ができて、技術力もアップするし、視野も広がる。
講演では、東京のコロナ感染のWebサイトでは、色盲の人に優しいアクセシビリティを考えるべき、というプルリクもあって、非常に勉強になった、とのこと。

【2】講演後の質疑応答で気になったのは、シビテックが欧米と日本でどのような特徴の違いがあるのか、という話。

関さんによると、欧米人は自分の意見を持って自己主張する。
政府はこういう政策を取るべき、こういう行動を取るべき、とか。
一方、日本人は、自己主張しない代わりに、応援するタイプが多い。
良い政策があれば、それを後押しするように活動する。
言い換えれば、日本人はリーダーシップがなく、受け身の人が多いのだろう。

また、米国では行政府の人はリボルビングドア(回転ドア)なので、OSSコミュニティの人の中に、行政府に所属して働いた経験を持つ人が多い。
すると、行政の事情に詳しいので、行政のニーズをよく知っていたり、行政の人間関係や法律上の壁などの事情をよく知っている。
ゆえに、シビテックではそういう人たちと組むことで、より効果の出せるIT技術による解決策を提示できる。

一方、日本では、OSSコミュニティに行政に関係する人が少ないので、行政と連携しにくい。
プログラマもそういう行政の裏事情を知らないので、連携しづらい面がある。
しかし、東京の副都知事にヤフー経験者の人が入ったおかげで、東京ではシビテックが盛んになってきた、と。

また、行政はITに詳しくないので、ITに詳しい技術者やOSSコミュニティと関わりたいニーズはある。
特に最近は、デジタル庁を設立する話も出たし、農林水産省や経済産業省もIT技術者を募集する広告を見かけるようになってきた。
こういう危機的な状況だからこそ、IT技術者が求められているのだろう。

社会変革の鍵の一つに、IT技術者も含まれている。

【3】そういう講演を聞きながら、今のコロナ感染対策が難しい理由も素人ながら何となく想像できるようになってきた。
その理由は、コロナ感染という問題が影響する範囲が広すぎて、数多くの分野の専門家を集結させて、一貫した方針を打ち出す必要があるのに、どれが正解か分からないので対策を取るのが難しいからだろう。

たとえば、コロナ感染の新規感染者を予測し、政策に合わせてその精度を次々に手早く変更していくには、西浦先生のような疫学の専門家が必要だし、感染などの医療に詳しい医学者が必要。
しかし、彼らだけで問題を解決できるわけではない。

たとえば、ロックダウンにより経済的に困っている人たちへ給付する政策を実行して、人々にどういうインセンティブを持たせれば効果が上がるか、という行動経済学とか、財政出動とその効果を測定するには、マクロ経済学とか、そういう経済学の専門家も必要。
そして、そういう経済政策や医療政策を実行するための正統性を確保するために、新しい法律を整備する法律家も必要。

たとえば、コロナ感染者が増加している状況で、コロナ感染者をスマホで追跡・隔離したり、検査した情報をクラウドの基盤に蓄積したり、刻一刻と変わる情報をWebサイトで収集・公開したり、各人に適切な給付金を配布するための一連の仕組みをWebシステムで構築したりするには、専門のIT技術者が多数必要になる。

つまり、それぞれの分野で一流の人を集めて、彼らを的確にアサインし、振ってくる問題をさばいていくことが求められる。
そういうことを実施する時、トップが全ての分野に精通して理解できるのは難しいだろう。
トップは全ての分野に精通した専門家ではないのだから。

では、そういうチームを編成して、問題を一つずつ解決していくことを成し遂げるには、何が必要なのだろう??
専門家でもないリーダーには、どんなスキルが求められるのだろうか?
どんなリーダーシップを発揮したら、問題となる状況を解決できるのだろうか?

何故ファシリテーションが流行しているのか?: プログラマの思索

| | コメント (0)

管理職に求められる能力はPM理論そのものではなかったのか

管理職に求められる能力の記事を読んでいたら、三隅二不二のPM理論そのものではないか、と感じた。
ラフなメモ書き。
浅い考えなので後で直す。

【参考】
管理職に求められるものとは─新世代リーダーへの条件─(前編)【ONE JAPAN CONFERENCE 2020レポート:PEOPLE④】|ONE JAPAN|note

(3) akipiiさんはTwitterを使っています 「これって、昔のPM理論そのままじゃないか!管理職の職能は不変なんだなと思った。“管理職に求められることは今も昔も変わらず、パフォーマンスとメンテナンスです。” 管理職に求められるものとは─新世代リーダーへの条件─(前編)【ONE JAPAN CONFERENCE 2020レポート:】https://t.co/XFNjuiTutr」 / Twitter

【1】(引用開始)
基本的に管理職に求められることは今も昔も変わらず、パフォーマンスとメンテナンスです。パフォーマンスとは、部門の業績を管理することで、メンテナンスはそのために多様なメンバーをマネジメントすることです。

しかし、管理職は組織の中間点にいるので、この2つに加えてダイバーシティや働き方改革、DX(デジタル・トランスフォーメーション)などあらゆる組織の問題が、すべて管理職にしわ寄せが来てしまっています。

さらに経営層からは、新規事業や新しい価値を作ってくれとオーダーされたり、現有の戦力の中で、多様な部下の強みを引き出して、なるべく早く革新的な成果を、しかもリモートで出してくれと命じられています。
(引用終了)

「基本的に管理職に求められることは今も昔も変わらず、パフォーマンスとメンテナンス」ということは、まさにPM理論そのままだなと思う。
成果を求めるパフォーマンス(P)と、チームビルディングなどのメンテナンス(M)の2つ。

PM理論 ? リーダーシップインサイト

PM理論by三隅二不二 | EARTHSHIP CONSULTING

PM理論とは ~理論から理解するリーダーシップとその変遷~|人材育成・社員研修|ラーニングエージェンシー

【2】そう言えば、PM理論は別名、パパママ理論とも呼ばれるらしい。
「業績:目標達成機能」(Performance)はパパ、「維持:集団維持機能」(Maintenance)はママに相当するように覚えると理解しやすかった。

(引用開始)
当時はまだまだ男が稼いで奥さんが家を守るという雰囲気の世の中だったので、このPM理論はパパ・ママ理論とも呼ばれ、厳しく子どもを育てるお父さんと、子どもの気持ちに寄り添うお母さんのイメージをあてて、このPM理論を説明していた。
(引用終了)

【研究ノート1】リーダーシップ理論(その1)「PM理論」|鈴木康宏|note

【3】「管理職に求められる能力はPM理論そのもの」という意見から気づいたことは3つある。

1つ目は、リーダーシップには成果(P)を求められること。
採用基準」本に「リーダーシップとは成果を求めること」というフレーズがあったが、たぶんそのことを指しているのだろう。
問題解決のためには、リーダーシップを発揮して、周囲を巻き込みながら、あるべきゴールへ到達するルートをとにかく進んでたどり着く。
まずはそういうスキルがなければ、話にならない。

2つ目は、ファシリテーション能力が10年以上前から重視されている理由は、メンテナンス機能の特徴の一つであること、そして、リーダーシップを補完する機能であるためだろう。
管理職に成り立てのマネージャは、部下に仕事を回すよりも自分でやった方が速いので、どうしてもマイクロマネジメントになりがち。
そういう時に、プロジェクトファシリテーションのようなスキルがあると、結果を出すチームを形成できるようになる。
スクラムマスターという役割も、メンテナンス機能を重視しているのではないか、と思う。

3つ目は、上記の記事では、管理職には新規事業を提案することまで求められてはいない、と記載されていたが、優秀な中間管理職ほど、新しい事業アイデアを実現したくてウズウズしている。
誰だって、上から言われた仕事をそのままやるのがモチベーションではない。
自分で実現したいアイデアや夢があって、それが会社の方向性と一致していれば、やる気も上がるし、そうなるように仕向けたいと思うからこそ、職務や権限を利用して動く。

特に、日本の組織では、名君と言われる経営トップは必ず、優秀な中間管理職をブレーンとして持ち、自由に采配が振れるように配慮してくれるものだろう。
たとえば、幕末から明治維新の頃は、薩長の下級武士がそういうトップに引き立てられて、彼らが原動力となって時代を変えていったように。
たぶん、日本は、経営トップが独裁的に振る舞うような欧米・中国のやり方ではなく、中間層のリーダーがリーダーシップを発揮するような、そういう組織文化なのだろう、と思う。

| | コメント (0)

2020/12/25

因果ループ図を再考する~問題の症状をシステム構造として捉えて解決策を見つける

プロジェクト管理や要件定義、システム企画をやっていると、どうしても因果ループ図のような考え方が欲しくなる。
自分の気づきをラフなメモ書き。

【参考】
因果ループ図(いんがるーぷず) - ITmedia エンタープライズ

システム原形とは?複数の切り口で根本原因を探る | akibito

システム原型を知れば、課題に予め対処することができる ? 変化から進化の物語へ/(株)Salt

因果ループ図の書き方 ルール編 ? 変化から進化の物語へ/(株)Salt

因果ループ図の書き方 実践編 ? 変化から進化の物語へ/(株)Salt

「引き寄せの法則」はシステム思考で説明できる ? 変化から進化の物語へ/(株)Salt

システム思考がアマゾンを世界一のECサイトにした ? 変化から進化の物語へ/(株)Salt

ルールを覚えても、因果ループ図がうまく書けない理由 ? 変化から進化の物語へ/(株)Salt

新しいビジネスモデルの作成(構築)方法 ? 変化から進化の物語へ/(株)Salt

System Dynamics 日本未来研究センター Japan Futures Research Center

相殺フィードバックを再考: プログラマの思索

相殺フィードバック: プログラマの思索

【1】因果ループ図を使いたい場面はどこなのか?

ロジックツリーやWBS詳細化のように、既に確定した要件を分解していく時ではなく、輻輳した現状、混沌とした現状で使いたい。
問題の原因を掘り下げていく時に、単純ななぜなぜ分析では難しく、いくつかの要因が複雑に絡み合っている場面で使いたい。

プロジェクト管理で、進捗遅延が発生した問題、テスト工程でバグが噴出して品質が劣化している問題。
企画や要件定義で、利害関係者の要望が予算の上限枠に当てはまらない問題、要件定義やシステム企画が混乱している問題。
それらの背後には、数多くの因果関係が問題を複雑にしている。
単純な解決策では、応急処置に過ぎなかったり、逆に問題をさらに悪化させる場合もある。

【2】因果ループ図のメリットは何なのか?

問題の症状を定義して、その問題を増幅させる変数を複数個洗い出し、それを因果関係でつないで、一つのシステム構造として見てみたい。
そうすることで、問題の本質が見えてくる。

堂々巡りの議論ではなく、問題を一つの構造として洗い出したい。

【3】因果ループ図を書くコツは何か?

基本は、時系列グラフを収集して、変数を洗い出す。
時系列で見ると、何らかの目的変数が増大して、問題になっている。
顧客の不満、コスト、行動、利益、資源、など。

時系列グラフにはパターンがある
指数関数、S字型曲線、頭打ちの曲線、振動する曲線、振動しながら成長する曲線、成長するが最後に崩壊する曲線、など。
それらは因果ループ図が背景として構造を持つが、それを具現化したもの。

相関関係と因果関係は異なる。
因果関係→相関関係だが、相関関係→因果関係とは限らない。
統計学では当たり前の常識。

因果関係の間にある潜在変数は書き出す。
潜在変数があるということは、疑似相関があること。
因果の飛躍を避ける。

因果ループ図では、フィードバックという考え方が大事。
システム思考の構造が「システム」「情報」「制御」から成り立つ。
制御=フィードバックになる。
システムダイナミクスの創始者がフィードバック制御の専門家だった。

フィードバックして因果ループ図になる。
たとえば、因→果が正の相関であっても、果→因は負の相関の時もある。
この場合、バランスループ、均衡ループになる。

各ループが自己強化型かバランス型かを判断することが大事。
変化を強めているのが自己強化ループ。
抑制しているのがバランスループ。

拡張フィードバック⇒自己強化ループになる。
拡張ループとも呼ぶ。
雪だるま(スノーボール)が転がる絵を描く方法を指導している。

相殺フィードバック⇒バランスループになる。
均衡ループとも呼ぶ。
天秤の絵を描くように推奨している。

以前、「相殺フィードバック」という言葉が何故か頭の片隅に残っていたが、意味を理解できていなかった。
たぶん、相殺フィードバックはバランスループを表す。

ループ構造に名前を付ける。
因果関係のループには意味がある。
フィードバックの特徴を表す名前を付ける。
読者の直感的理解を促進する。

ストックフロー図に置き換える。
微分方程式に置き換えられる。
専用ツールで、時系列グラフに変換できる。
因果ループ図は定性分析。
ストックフロー図は定量分析に相当する。

【4】自己強化ループ、バランスループの区別するコツは何か?

2つある。
一つは、どこか任意の変数を出発点として、ループに沿ってぐるっと一周して、最初の変数の変化を強めるのか、抑制するのかで判断する。

他方は、マイナスループの合計個数で、自己強化orバランスに分ける。
奇数ならバランスループ。
偶数なら自己強化ループ。

【5】因果ループ図を元に、どんな解決策を実行するのか?

絡み合った因果関係の中で効果的な作用点=レバレッジポイントを発見するのが大事。
Amazonビジネスモデルの初期モデルは、顧客体験だった。
Kindleビジネスは、出版社だった。

割れ窓理論では「割れた窓ガラス」だった。
割れた窓ガラスを徹底的に無くすことで、最終的に犯罪件数が劇的に減った。

目的は成長させたい場合、
システム内の自己強化ループを強める施策を入れるなら、「ベゾスが考えたAmazonビジネスモデル」のように、別の自己強化ループを作る。

システム内のバランスループを弱める施策を入れるなら、「成功の限界」のように、制約を入れる。
「犯罪都市ニューヨークの割れ窓理論」のように、流量を抑える変数を入れる。

目的は現状維持なら、
システム内のバランスループを強める施策を入れるなら、制約や流量を抑える変数を入れる。
システム内の自己強化ループを弱める施策を入れるなら、別の自己強化ループを作る。

【6】感想

因果ループ図は使いこなすのが難しい。
因果関係となる変数を導くこと、それらを意味あるようにつなぐのが難しい。

一つのきっかけは、時系列グラフとセットで考えること。
そして、2つの変数のみでまずはループ構造を描いて、雪だるま式に自己強化ループを増やす。
あるいは、天秤のようにバランスループを書き出す。

ループ構造に名前を付けるのも重要。
この認識が以前はなかった。
売上増大ループ、顧客関係性強化のループ、とか。

因果関係と相関関係は違うのに、混同している時もある。
まずは書いてみては直す。

やりたいのは、問題となるシステム構造を描き出したい。
そうすれば、どこかの変数に制約を入れれば、流量が減るので、拡張ループは抑えられる。
成長させたい時は、別の拡張ループを増やるように、売上増加の別の戦略を打ち立てれば良い。

Amazonのベゾス、MSのビル・ゲイツも因果ループ図を使いこなしていた、と言う。
この考え方を実際に使ってみる。

| | コメント (0)

2020/08/14

「チームが機能するとはどういうことか――「学習力」と「実行力」を高める実践アプローチ」の感想

「チームが機能するとはどういうことか――「学習力」と「実行力」を高める実践アプローチ」の感想をメモ。
ラフなメモ書き。

期待して読み始めたが、自分の心に引っかかるものが正直なかったように感じた。

確かに、チームが大事だ、という主張は分かる。
昨今は、ソフトウェア開発プロジェクトのように、プロジェクトのリーダーもメンバーも、ある一定期間で集合離散を繰り返す。
アプリ、インフラ、ミドルウェアなどの専門能力を持つ開発者がプロジェクト型のチームを作り、成果を出すには、チームとしてすぐに形成できる力がいる。

この話を読みながら、10年前に流行したプロジェクトファシリテーションを思い出した。
つまり、チームビルディングのスキルがプロジェクトリーダーには必要だ。
だから、そういうイメージでこの本を読んでいた。
たぶん僕は、チームビルディングのプラクティスやアンチパターンを追い求めていたので、心に残らなかったかもしれない。

個人的には、ファシリテーションのスキルを身に付ける時に留意すべき概念は、2つあると思う。
一つは、タックマンモデル。
もう一つは、バーナードの組織の3要素。

タックマンモデルとチームビルディング ? ゲームを用いた企業研修なら| 株式会社HEART QUAKE

バーナード組織の3要素【共通目的・協働意欲・コミュニケーション】 | Act And Act

タックマンモデルが僕にとって新鮮だったのは、チーム内のコンフリクトは悪ではなく必要不可欠なものだ、という考え方だった。
たぶん、僕が日本の学校教育で、和を尊ぶ思想に染められていたからかもしれない。
むしろ、コンフリクトとして、意見や立場の対立を見える化することで、問題の本質が見えてくる、という逆説。
人間として大人のチームでは、激しい議論や意見対立はあっても、問題の真因がはっきりすれば、一致団結しやすい。

一方、バーナードの組織の3要素を診断士の先生から教わった時に強烈な印象を受けたことは、トップの人が共通目的を語り、メンバーの貢献意欲を引き出し、コミュニケーションを活性化するように汗をかくべきだ、ということだ。
僕は、組織文化というものは、ボトムアップで生まれるものだ、という思い込みがあった。
アジャイル開発が好きだから、メンバー自身がチームの文化を生み出すのが普通だろう、と。

しかし、プロジェクトリーダーの立場に自分が属するようになると、自らがビジョンを語り、メンバーの貢献意欲を引き出すように心がける言動の方が実際に多くなった。
そうした方がチームが上手く回る、と経験したこともあったが、バーナードの組織成立の三要素を知らない時はしっくりこなかった。
でも、今ではその意味は分かるような気がする。
結局、チームは人に依存するからこそ、自らエネルギーを噴出させて、周囲の人に影響させることで、チームとしての一体感や使命感を醸成させるのだ。

それは一つのスキルだろうし、後天的に身に付けられるものだと思う。

| | コメント (0)

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)

より以前の記事一覧