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

2021/04/08

プロジェクトのリスクはコストの増減で管理する

「プロジェクトのリスクはコストの増減で管理する」のであり、「コスト管理と課題管理は同じではない」。

【参考】
コストマネジメント(コストコントロール体系) | イノベーションマネジメント株式会社

プロジェクトリーダーのレベルではなく、事業部長や複数プロジェクトを取りまとめる組織の長の観点では、各プロジェクトのリスクをどのように軽減したり、回避したりするか、に注力するようになる。
リスクを完全にゼロにすることは、お金もリソースも使い過ぎるので、現実的ではない。

各プロジェクトでは、計画時にプロジェクト特性に応じて、リスクを洗い出す。
プロジェクトリーダーは、プロジェクトのキックオフ後、実行中では、リスクがどのように変化して、増大して手に負えなくなるか、事前に防げるか、に注力していく。

一方、事業部長や部課長の観点では、どこかのプロジェクトで火を噴くリスクがあると考えて、事前に各プロジェクトのリスクをコストで予算化しておく。
そういう予算は、プロジェクト外費用ならコンティンジェンシー予備費だし、プロジェクト内費用であればマネジメントリザーブ(マネジメント予備費)になる。
そして、実際に火を噴いたら、マネジメント予備費を使うし、更に足りなければ、コンティンジェンシー予備費を投入してでも、火を消すようにする。

一般に、マネジメント予備費を使う権限は、プロジェクトリーダーの采配と組織の最末端の管理職である課長の采配の2つで決まるだろう。
マネジメント予備費は契約時に、利益やコストを見込んで、契約金額に上乗せして積まれている。
マネジメント予備費を使うほど、利益は落ちるので、プロジェクトリーダーの権限ですべてを使っていいわけではなく、最低限の利益ラインを超える場合は、課長の承認が必要になるだろう。
普通は、一旦プロジェクトが火を噴けば、際限なくコストは膨らんでいく。

そして、コンティンジェンシー予備費は、事業部のトップである事業部長の承認で決まる時が多いだろう。
コンティンジェンシー予備費を使う段階まで来ると、経営陣にもその使途理由を問われるので、社内では相当な噂になりやすいだろう。

駄目なプロジェクトでは、プロジェクト計画時にリスクをそもそも洗い出せておらず、単なる課題一覧に過ぎない。
適当に解決するだろう、という期待を含めた課題管理に陥っている。
だから、リスクが顕在化して手に負えなくなると、肝心の予算がなく、単なるデスマーチ案件となってしまって、会社のお金や人員を無尽蔵に浪費していってしまう。
元々、リスクに対する予算などの手当がないので、何の戦略もなく、ズルズルと状況に押し流されるだけになる。

本来は、リスクの内容に応じて、影響度や深刻度、重要度に応じて、そのリスクが発生した場合にかかる費用を見積もり、それらの合算をコストとして予算として見込む。
もちろん、全てのリスクを洗い出して合算したら、途方もない金額になるから、ある程度のリスクは許容することで予算化しないことになる。
あるいは、コストが掛からない対策があれば一番良いが。

PMOの仕事をしていると、プロジェクト運営という観点だけでなく、プロジェクトの採算やコスト管理まで見るようになってきた。
その時に、駄目な会社では、ISO9001を運用していると標榜しながらも、プロジェクト計画書に記載されたリスク一覧が単なる課題一覧に貶められている風景を何度も見てきた。
本来、リスク管理とは何だろうか?という疑問があったが、リスクはコストの増減で管理するという発想が必要と分かり、ようやく腑に落ちた。


| | コメント (0)

2021/04/04

沢渡さんの資料「テレワークに役立つ8つのスキル」はいいね

沢渡さんの資料「テレワークに役立つ8つのスキル」が参考になるので、メモしておく。

【参考】
経営課題解決のためのテレワーク導入・活用Webセミナーレポート|トピックス|ハマリモ! 浜松テレワーク推進プロジェクト

テレワークが主体になった仕事では、以前とは違ったスキルが必要になっていると感じる。
特に、周囲に誰も居ないので、自分自身でスケジュールや仕事の内容をコントロールすることが重要になったし、それがさらにシビアに厳しくなった感じだ。
テレワークによって、正社員であっても、個人事業主が請負契約で仕事しているイメージに近い。

なぜなら、テレワークの成果物としてアピールすべきものは、目に見える成果として出さなければ、存在しないのと同じだから。
よって、より高いアウトプットを定期的に出すためのスキルが別途必要になっている、と考える。

「テレワークに役立つ8つのスキル」では、下記がある。
・ロジカル・コミュニケーション
・セルフマネジメント
・ヘルプシーキング
・クリティカル・シンキング
・チームビルディング
・プロジェクトマネジメント
・ファシリテーション
・ITスキル/リテラシー

「テレワークに役立つ8つのスキル」を分類すると、2つのカテゴリに分類できるだろう。
他者とやり取りする技術、そして、自分自身を律する技術。

テレワークでは、他者とやり取りする手段がチャットやTV会議に限られるため、対面よりも情報量が圧倒的に少ない。
だから、いかに濃い情報をやり取りできるか、が鍵を握ると考える。

そのために、論点を明確に手短に話したり、議論している内容から課題を抽出して構造化・言語化したり、お互いに率直に話せる環境を醸し出したり、などのスキルがいる。

また、テレワークでは、自分一人で成果物を作り出す能力がより求められるので、自己管理がより重要になる。
問題を整理し、ゴールを定め、ゴールまでのプロセスを作り、作業に分解して、作業しながら自分の立ち位置を自己測定する。
つまり、プロジェクトマネジメント力がかなり求められる。

また、集中して仕事できる環境を整備し、時にはモチベーションを奮い立たせたり、リラックスできる環境もいる。
もちろん、オンライン会議ツール、チャットツール、チケット管理ツール、オンラインスケジュール、オンラインファイル共有などのツールを使いこなすことも大事。
つまり、セルフマネジメントの環境を整備するのも大事。

無理ならば、アラートをあげて他者にヘルプを求めたり、専門家に頼れるルートもいるだろう。

自分でリモートワークしていて、こういう考え方が必要だな、と色々思いつくものの、整理できていなかったので、こういう図で言語化できて、とてもありがたい。
他人に話す時にも使えるので有用と思う。





| | コメント (0)

2021/03/30

ソフトウェア開発は打ち合わせ駆動開発だ

ソフトウェア開発は打ち合わせ駆動開発だ、と思う。
WF型開発でも、アジャイル開発でも、同じように思える。
以下、ラフなメモ。

たとえば、一般的なWF型開発では、各工程の終了ゲートでは、顧客やステアリングコミッティの承認を得るための会議を開いて、そこを通過するのを目的とする。
その会議のために、プロジェクトマネージャはパワポの資料をわんさか作成する。
その会議で報告して最終検収するために、メンバーはその会議資料の元ネタとなるプログラミングしたシステム、その設計書、テスト仕様書、不具合一覧、リリース手順書などを揃える。

もちろん、設計、開発、テストの各工程では、レビューを通過しなければ、先に進めない。
レビューアが承認する、という儀式が待っている。

一方、アジャイル開発では、各工程のゲートはないが、スプリントプラニングやスプリントデモなどのイベントがある。
それらイベントが、開発チームの行動を制約して、プロジェクトの目的をメンバーに思い出させる。

では、ソフトウェア開発以外のビジネスでは、打ち合わせ駆動のスタイルではないのか?
営業であれば、打ち合わせするよりも、お客様の現場に直行して交渉するほうが大事だ。
受付や店頭販売の人であれば、窓口や店頭でお客様に商品説明するほうが大事だ。
工場の生産現場であれば、打ち合わせよりも実際に生産ラインで組み立てるほうが大事だ。

つまり、普通のビジネスでは、SEやPMのように、1日のスケジュールが打ち合わせで一杯になる、なんてあまりないのではないだろうか。
換言すれば、ソフトウェア開発では、打ち合わせで仕様を詰めたり、アーキテクチャの方針を決める、という創造的な仕事よりも、出来上がった成果物のレビューで完了承認する、とか、作業が遅延していないか進捗確認する場の方が良いのではないか。
とにかく、ソフトウェア開発に関わる人は打ち合わせが多すぎる。
だから、会議室をたくさん用意するほど、どんどん会議室が埋まってしまう症状が見られやすい。

ソフトウェア開発が打ち合わせ駆動開発になりやすい原因は何だろうか?
平鍋さんは、ソフトウェアはコミュニケーションウェアだ、と言われたが、まさに、数多くの伝言ゲームを経て、一つのソフトウェアが作られる。
ソフトウェアは目に見えないものなので、逐一、みんなが額を寄せ合って、プログラムの意図や意味、バグ、アーキテクチャなどを説明しなければ伝わらないのかもしれない。

ソフトウェア開発が打ち合わせ駆動開発になりやすい特徴があるならば、その打ち合わせをもっと有意義なものにすればいい。
PMBOKでも、会議体というコミュニケーション計画は重要なマネジメントの一つ。
アジャイル開発では、故意にイベントを設けて、イベントが開発チームのモチベーションを上げるような仕組みを提供した。

そういう事を考えると、打ち合わせを制するものはソフトウェア開発を制するのかもしれない。

| | コメント (0)

2021/03/02

プログラマとスクラムが社会実装を変えていく #Findy_GovTech

今夜、ガバテックの話をZoomで聞いていた。
話は面白かったが、色々考えさられた。
考えたことをラフなメモ書き。

【参考】
経済産業省デジタル化推進マネージャーと弁護士ドットコムが語る!行政にエンジニアが関わる意義 - connpass

【1】政府行政をエンジニアが関わって、DXを推進していくのがガバテックと言えるかもしれない。
パネラーが言うように、今まさに旬のテーマ。
デジタル庁ができるし、ITエンジニアがより政治に関わっていくこともできる。

パネラーは、エンジニアリングで社会実装を変えていく、と言っていたが、話を聞いていたら、僕は「プログラマとスクラムが社会実装を変えていく」という意見を持った。

理由は2つある。

【1-1】1つ目は、プログラマが政府行政のIT化で活躍できる場がすごく多く、昔から受け継がれる問題、今まさに直面している問題に対し、プログラマしか解決できないテーマが多すぎるから。

たとえば、コロナワクチン接種管理システムの構築もそうだし、コロナ不況で失業したり、緊急事態宣言でビジネスを制限された人達に補助金を出すシステムもそう。
こういうシステムが必要とされているのに、インフラ構築できない、Webシステムを構築できない、業務要件をデータモデリングでまとめられない状況にある。
政府行政にいる人達は、ITの専門家ではないのだから、そういう技術に詳しくないのは当然だ。
だからこそ、ITエンジニアがより深く関わるチャンスがあるし、それによって、社会を変革していく道筋も生まれる。

ハンコ押印を使った各種申請、税金の支払いが楽になるだけでなく、より積極的に、ITという手段を通じて、政府を通じて世の中をより良くしていく、という活動にコミットできるわけだ。

【1-2】2つ目は、プログラマが政府行政のIT化に関わっていく場合、組織体制はスクラムに即した体制にならざるを得ない印象を持ったから。
パネラーが言うには、政府行政で、パネラーに協力してくれる人達は、事実上、プロダクトオーナーの役割を担ったり、色んな部署と調整したり、逆にパネラーのようなITエンジニアを守ってくれるような活動をしてくれたらしい。
パネラーのようなITエンジニアと政府行政の人達の間に信頼関係が構築できたことで、より深くコミットすることもできた、と。

そういう話を聞くと、まさに、そういう組織体制はスクラムで実装することになるだろう、と思う。
なぜならば、スクラムを適用すれば、スクラムの3つの役割にピッタリ当てはまるからだ。

【1-3】国民の公共サービスの利便性を提供するようなサービスを提供するケースを考えよう。
すると、そのような業務要件を考えるプロダクトオーナーが必要であり、政府行政の業務や法律に詳しい、政府行政の人達自身が担当する。
インフラを構築したり、システムを実装したり、セキュリティ対策を考える人達は、各分野のITエンジニアがチームを形成する。
そして、外部から雇い入れたスクラムマスター、または政府行政の人でファシリテーションが上手い人が、プロダクトオーナーとチームの間で調整する役割を担うだろう。
結局、そのようなプロジェクトチームをシステム毎にたくさん作り、スピード感を持って政府行政のDXを推進していくしかないだろう。

【2】しかし、政府行政のDX推進を妨害する問題は、内製開発できずにベンダーに発注してベンダーロックインになってしまうことだろう。

現状は、政府行政の中の人達が、ITプロジェクトをマネジメントする能力が不足しているし、発注者として、プロダクトオーナーの役割を果たす能力も不足している。

【2-1】本来のあるべき姿は、政府内部で公共サービスを提供するシステムは、全部自前で開発できると一番いい。
リリース後も常に保守する責任を持つし、サービス利用者の声を集めることで、次々に新たなサービスを提供して利便性を高めて、世の中をより良くしていくことができるはずだ。

そういう内製開発が政府内で実現したならば、SaaSベースの開発スタイルになるだろう。
文字通り、ソフトウェアでサービスを提供するわけだ。
理由は、「ソフトウェア・ファースト」の本に書いてある通りと全く同じ。

そして、そのシステム開発のプロセスはスクラムで行われるのが自然だ。
政府行政内の人がプロダクトオーナーを担当し、その業務要件がプロダクトバックログで表現され、サービス利用者が使いやすいように、業務フローやデザインは、ストーリーテリングのように数々の利用ストーリーを踏まえたもので作られるだろう。

【2-2】しかし、現状はギャップが大きすぎる。
パネラーも言っていたように、いきなりデジタル庁で解決するわけではないだろう。
おそらくは、デジタル庁のメンバーは発注者のプロジェクトマネージャーの立場がまず求められて、そういう仕事から現状の問題をこなしながら、今後のあるべき姿へ地道に変革していくことになるのではないか。

【3】しかし、政府行政のIT化の根本問題は、個人のプライバシーとどのように折り合いをつけるべきなのか、があると思う。

【3-1】実際、確定申告のWebシステムであれ、コロナ接触管理アプリCocoaであれ、国民全員に10万円をばらまいた補助金であれ、全て、国民1人が持つプライバシーをどのように扱えばいいのか、に苦慮している。

そもそも、中国のような監視社会であれば、個人の行動履歴、購買履歴、所得や資産情報、医療情報も全て、政府が把握できているのだから、本当に困っている人達に特定して補助金を配ることもできるし、特定した感染者を強制隔離することで、世間の人達の健康を守ることもできる。

だが、政府の公共サービスでは、個人のプライバシーが他人に悪用されるリスクや脅威がとても影響が大きいために、セキュリティ面の対応によって、機能は複雑化し、業務フローもとてもややこしくならざるを得ない。
たとえば、確定申告のeTAXは、なぜあんなに、スマホでもPCでも使いにくいのか、とみんな思っているのではないか。

しかし、過去の歴史を踏まえると、政府に個人情報を預けると何をされるか分からないという、命に関わる危険性をみんなが持っていたし、政府を信用していないから、プライバシー保護という名目で、今までこの問題を放置してきた。

コロナ感染という特別な状況が、その問題が自分たちの生活に直結するぐらい重要である、と分かってきたのではないか。

【3-2】一方、今回のコロナ不況で薄々分かったことは、我々自身も、政府の行動が信用できるならば、自分の個人情報を預けてもいい、と考えているのではないか。

実際、現在の政府の公共サービスは全て申請主義なので、サービスを受けたければ、自分たちからたくさんの書類を集めて、大量の文書を書いて、提出後は長く待たないといけない。
本当に困っている人達に、給付金を直接渡すべきなのに、政府から困っている人達を特定できないから届けることもできない。
よって、失業者が溢れたり、犯罪者や自殺者も増えたりして、社会自体が重苦しく、不便なものになっていく。

だからこそ、そうならないように、例えば、本当に困っている人達に給付金を配ったり、あるいは、コロナワクチンを接種すべき人達を政府自身が特定すべきだし、それらを一括管理できるようにすべきだろう。

【3-3】他方、プライバシー保護のグレーゾーンや法律のグレーゾーンに積極的にリスクを取って関わっていくことで、新しいビジネスを生み出すことの重要性も分かってきたのではないか。

たとえば、テスラは電気自動車を単に提供するだけでなく、販売した電気自動車の走行ログをもとに自動運転技術をより強化させている。
また、走行ログというビッグデータをもとに、自動車損害保険ビジネスに乗り出す、とか、Uberのような配達ビジネスに自動運転をミックスしたビジネスも生まれるだろう。

アップルも、アップルウォッチを提供することで、個人の健康情報を収集することで、ヘルステックという新たなビジネスを生み出そうとしている。
個人の健康情報のログをもとに、医療サービスや保険サービスの新たなビジネスが生まれるし、健康に関わるスポーツビジネスも生まれるかもしれない。

【3-4】つまり、個人情報の保護がグレーゾーンであっても、それに関するビジネスにソフトウェアが決定的に重要な役割を果たし、大きく社会を変えている状況では、この流れに乗り遅れると、もはや国自体が衰退するしか無い。
実際、コロナ感染の社会状況において、日本の大臣は、日本はデジタル敗戦だ、という発言もした。
すなわち、日本はソフトウェアでビジネスを変革するだけでなく、ソフトウェアで公共サービスや社会を変革していくことすらも、他国から大きく遅れてしまった。

米国は、多くのベンチャー企業などが法律のグレーゾーンをものともせずに、ソフトウェアで新たなビジネスを生み出した。
中国は、一党独裁の統制社会を維持するために、ソフトウェアを上手く利用して、インターネット規制やネット検閲、監視カメラなどによる監視体制などを利用してきた。
もちろん、BATのようなIT大企業も生み出しているが。

EUもプライバシー保護や民主主義を掲げてGPDRとか色々作ってきているが、結局、米国や中国のソフトウェアビジネスやソフトウェアの変革の波から乗り遅れているのではないか。

【3-5】そんなことを考えると、プライバシーはもちろん重要だが、各種申請や税金支払、補助金受け渡しのような公共サービスの利便性を求めたり、コロナ感染のように公共性を重視すべき場面では、ある程度のプライバシーは政府に委ねる方向性に今後進んでいくような気がしている。

| | コメント (0)

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)

より以前の記事一覧