リーダーシップと意思決定の分布では日本が独特のポジションにある

リーダーシップと意思決定の分布では日本が独特のポジションにあるというツイートをメモ。
ロジカルでないラフなメモ書き。

【参考】
日本企業においてリーダーシップが生まれにくい理由～リーダーシップを取る事の割の合わなさ問題～ - Togetter

心理的安全性は日本企業では実現しにくいかもしれない: プログラマの思索

中野 仁 (AnityA)さんはTwitterを使っています 「リーダーシップと意思決定の分布が日本が独特という話。 階層主義で合意形成を重んじるとなると、上下左右全部に話を通して凄まじいコミュニケーションコストがかかる上に、上と左右からはとりあえず意見だけは言えるのでリーダーに対して投げられる石がだいたい当たるという事では…。 https://t.co/bqHxAufImN」 / Twitter

akipiiさんはTwitterを使っています 「このスレッドのリーダーシップ分析が素晴らしいのでリンクしておく。リーダーシップの適切な日本語訳がないのは、日本人がそういう概念を持ってないと言う恥ずかしい事実。」 / Twitter

中野 仁 (AnityA)さんはTwitterを使っています 「確かにリーダーシップに適切な日本語訳が無いという話に繋がるかも知れませんね。 無理やり似た様な概念をひねり出すと、村長シップ、マイルドヤンキーシップ…みたいな。 義侠心(中国発)かなぁ。」 / Twitter

akipiiさんはTwitterを使っています 「@Jin_AnityA ちきりんさんのVoicyを聞いて、ビジネスや組織戦略、ITにカタカナ用語が多いのは日本語に適切な言葉がない、つまり日本人はそんな概念を生み出せなかったと言う事実に気付きました。リーダーシップは統率力や指導力だけではないです。」 / Twitter

中野 仁 (AnityA)さんはTwitterを使っています 「ボトムアップ＆合意によるプロセスの複雑性がわかりやすく出るのがワークフローシステム ・とにかくフローが長い。承認階層が5段階とかある。 ・兼務があちこちにあって分岐の数が多い。例外処理が多い。 ・念の為に参照する人が大量にいる。フローに入ってなくてもひっくり返す事ができる。」 / Twitter

akipiiさんはTwitterを使っています 「ワークフローの複雑さと合意形成のルートの長さは相関関係があるのか、なるほど」 / Twitter

【1】日本人の意思決定やリーダーシップでは、階層主義でボトムアップの合意形成を重んじるタイプ。
一方、アメリカやイギリスは日本と正反対で、フラットでトップダウンのタイプ。
他方、中国やロシア、インドでは、階層主義でトップダウンのタイプ。
なぜか日本だけ特異なタイプになっている。

米英では、フラットに互いに議論して対立しても、最後はリーダーが専制主義のようにトップダウンで決める。
大統領制は民主的な王政に近いスタイルだろうか。

アジアに多い階層主義でトップダウンのタイプは、目に見える身分制度、目に見えない階層があって、専制主義的にトップダウンで決める。
絶対主義王政、東洋的君主制などの過去の歴史を眺めればこのタイプは理解しやすい。

【2】階層主義でボトムアップなリーダーシップを持つ日本は、どんな特徴を持つのか？
目に見えない身分階層は日本でもよく見られる。
建築業界やメーカー、IT業界にはびこる多重請負構造、男女間の目に見えない格差などが思い浮かぶ。
しかも、忖度や根回し、腹芸など日本独特の気遣いもある。

すると、トップは権限を持っていても、実際に権限を振るうとメンバーのサボタージュにあって、にっちもさっちもいかない。
結局、参謀役を使って事前にメンバーに根回しして、ゆっくり推し進めるみたいな感じになる。
ただ、こういうスタイルでなぜ集団主義的傾向が出て、皆が同じような価値観を強いられるのかが不思議だ。
実際は、そういう圧力に反対する人もいるし、力があるなら無視すればいいから。

【3】しかし、なぜ日本だけが階層主義でボトムアップなリーダーシップになりやすいのか？
この辺りは、昭和の頃にすごく流行した日本文化論を思い出す。
日本人は世界から見て特別な人種なのだ、特別な文化を持つのだ、といろんな識者がいろんな観点で解説していたけれど、何かしっくり来なかった気もする。
いくら集団主義的傾向を持つ日本人が多いからと言っても、そこからはみ出た人も多いし、自分の意見をはっきり主張して周囲との軋轢を気にしない人もいるし、一概にそうとは言えない。

【4】こういう傾向を持つ日本人の弱点は、戦略がない点、リーダーシップの経験を持つ人が圧倒的に少ない点だろう。
結局、そういう弱点が今いろんな所で社会に出ているのだろうと思う。
問題は皆分かっているのに、自分の利益を侵害されるとその人達は反対するので、全体最適な観点ではなく局所最適化しやすい。

【5】心理的安全性は日本人の間では非常に難しい文化と思う。
たぶんその理由も、お互いのプライドや人格を傷つけてしまう意識が強すぎるために、忖度や根回し、腹芸のような変なテクニックが必要となり、お互いの心理的安全性を上っ面で維持しようという方向に傾くのだろう。

心理的安全性は日本企業では実現しにくいかもしれない: プログラマの思索

ベロシティをコース定数で理解する

ベロシティをコース定数で理解する記事がとても良かったのでメモ。

【参考】
アジャイルな見積もりを理解する「コース定数」という概念 - だいくしー(@daiksy)のはてなブログ

Dai Fujihara | mabl（メイブル）ノーコードテスト自動化SaaSさんはTwitterを使っています 「こんな定数あるのか。山の高さや行程ふまえての数値はわかりやすいなー / アジャイルな見積もりを理解する「コース定数」という概念 https://t.co/O5HeylyzvJ」 / Twitter

Miho??NagaseさんはTwitterを使っています 「身近なベロシティのたとえで図らずも山行について学べてしまった / “アジャイルな見積もりを理解する「コース定数」という概念 - だいくしー(@daiksy)のはてなブログ” https://t.co/QMsU1aw12a」 / Twitter

プロジェクトのリスクはコストの増減で管理する: プログラマの思索

【1】アジャイル開発を日本のSIの現場でやる時に、5本の指に入るくらい壁があるのが、ベロシティやプラニングポーカーによる見積もりだろう。
日本のWF型開発案件は、PJ計画時にスケジュール、コストを可能な限り再現性のある絶対数値で見積もらなければならない。
一度決まった見積もりは計画と実績の予実管理のための指標となり、独り歩きして、その見積もりから離れられなくなる。

一方、アジャイル開発では、相対的な数値で見積もりする。
しかも適当な数値ではなく、フィボナッチ数を使って相対的な比較をもって見積もりする。
それをスプリントごとに計測して、実際の実績値を計測し、チームの生産性をベロシティを算出する。
ただし、ベロシティはあくまでも相対比較の数値なので、他チームの生産性と比較することは無意味だ。

WF型開発でもアジャイル開発でも、定量的なデータ管理は必須要件だ。
しかし、その扱いが全く異なる。
つまり、WF型開発は絶対的な数量、アジャイル開発は相対的な数量で算出する。

【2】以前、プロジェクトのリスクはコストの増減で管理する: プログラマの思索の記事で、リスクもコストという数値で定量化して測定すべきなのだ、という気づきがあった。
定量化した数値があるからこそ、洗い出した複数のリスクを比較して、意思決定できる。
そもそも、リスクというからには、リスクを回避したり、リスクを低減したり、リスクを解消するには、それなりの費用がかかるはず。
だから、リスクという、今は潜在的で分かっていない対象を費用という数値で定量化することで、見える化し、意思決定の根拠にするわけだ。

ソフトウェア開発の費用は、スーパーで売っている生鮮食料品、家電量販店で売られている電気製品とは違って、定価や希望小売価格を決めづらい。
なぜなら、価格の妥当性の根拠をとても説明しにくいのだ。
実際、ITに詳しくないユーザ企業の経営者から見ると、こんなボロカスで20年以上前の古いシステムの保守費用がなぜ数千万円、数億円もかかるのか、疑問に思いながらも、ベンダロックインされているためにベンダの言いなりになっているだろう。

その費用や価格を絶対的な数値ではなく、アジャイル開発では、相対的な比較で数量を見積もる点が上手。
相対比較であれば、その判断の根拠も簡単だ。
また、相対比較に必要な数値を算出する作業工数も少なくできる。

一方、WF型開発の見積もりは、プロマネが非常な労力をかけて案を出し、数多くの有識者のレビューを受けて初めて確定するから、見積もりを出すまでの工数が非常に膨大にかかりすぎ。
その割には、その見積もりは不安定であって、要件が少しでも変わってしまえば、その見積もりはすぐに無駄になる。
また1から作り直さなければ、正確な見積もりは定まらない。
なぜなら、要件の要素が一つでも変われば、その影響は要件同士の整合性、後工程へのスケジュール、新たな担当者のスキルなどの数多くの変数を考慮して、正確に見積もる必要があるからだ。
それくらい、WF型開発の見積り金額は、金額の妥当性の根拠を問われるから。

そういうことを考えると、アジャイル開発はソフトウェア開発特有の難しさを上手く飲み込んで対応しようとしているように思う。

redmine.tokyo10周年を祝う会でふりかえりしました #redmineT

redmine.tokyo10周年を祝う会が開催されたのでメモ。

【参考】
Redminetokyo 10周年を祝う会 - redmine.tokyo

shinagawa.redmine キックオフミーティング が開催されました - secretbase.log

akipiiさんはTwitterを使っています 「https://t.co/i2sJFMVOU3 の初回の打合せの参加者は、割といましたね。@tkusukawa @tech_machii まるやまさんもおられましたね。#redmineT」 / Twitter

はるかさんはTwitterを使っています 「あきぴーさんの記事はこれですね。https://t.co/DjjTZPJ3S2 #redmineT」 / Twitter

redmine.tokyo10周年を祝う会で歴史を堪能する #redmineT | マドびっ！ Madosan's View

【1】redmine.tokyoのコミュニティですごいと思うのは3つある。
1つ目は、コミュニティが10年続いたこと。
自分がスタッフとして関わったコミュニティで、熱量が維持されて10年も続いたコミュニティは、redmine.tokyoとSEA関西ぐらいだろうか。
アジャイルのコミュニティも他のコミュニティも、10年も長続きしなかった。
どのコミュニティも浮き沈みがある。
ブームに乗って盛り上がった時もあるが、スタッフが高齢化したり、熱量を持つスタッフが減ってしまったりする。

あるいは、熱量を持つスタッフが複数人いて最初は良かったが、視線のベクトルが異なってしまって、コミュニティとして分離してしまったり、とか。
いくら仲が良くても、思想や性格も違うので、それがきっかけで別れてしまう時もある。

そんな経験を経て、「コミュニティは細く長く続けること」が大事かなと思っている。

【2】2つ目は、redmine.tokyoは初期立ち上げのスタッフが多数残っていること。
@tkusukawaさん、@naitohさん、@ohwadaさん、@haru_iidaさんが残ってくれている。
もちろん離れたスタッフもいるが、10年も続いた縁は本当に長いと思う。
人間関係は長いほど、その人の性格や価値観も分かってくるし、そういう安心感もある。
熱量が減ったとしても、同窓会みたいな感じで戻れる場があるのは心強い。

【3】3つ目は、KPTを10年続けていること。
会社でも、コミュニティでも、KPTのふりかえりを実施している所は少ないのではないか？

第1回勉強会でKPTをWikiに残しているが、当初は僕がちょっとやりたかったという気持ちもあって気軽な感じだった。
それが10年もKPTを続けると、今回の勉強会で試して分かったことや良くなかった点を、次回に活かしたいね、という内容が出てくて、次回の勉強会に活かせるようになる。

年2回の勉強会なので、半年ごとのPDCAサイクルを自然に回していることに、後から気づいた。
KPTの活かし方はこんなものなのかな、と後から気づきが多かった。

【4】僕はコミュニティという場は好きだ。
理由は、コミュニティでは、同じ価値観や問題意識を持っている前提が暗黙的にあるおかげで、誰とでも気軽に人間関係を作れるから。
相手がたとえ社長のような社会的地位が高くて年収が高くても、コミュニティでは全く関係ない。
その人自身に能力があり、人格が優れていて、リーダーシップがあれば、自然に輝くし、自然に人間関係が作れる。
つまり、本音で話せる雰囲気が出やすい。

一方、会社では、組織上の地位や権限、権力関係が人間関係にも現れてくる。
どうしても、腹を割って話すのは難しい。
上司であれば、丁寧語を使ったり、相手におもねったり、忖度してしまう。
営利企業であり、仕事であるから、人間関係に請負契約みたいな雰囲気も出てしまう。

コミュニティではそういう責任がない点もあるだろうが、より純粋な人間関係が現れやすい気がした。

【5】redmine.tokyoも今振り返ると、浮き沈みはあったのではないか、と思う。
立ち上げ当初は、藤原さん、小久保さん、岡本さん、@haru_iidaさんのように、ツールの自動化の連携、アジャイル開発への適用に興味を持つ人が多かった。
あるいは、SIerのプロジェクトリーダーとして、ソフトウェア開発のPJ管理を自動化して、チーム運営する基盤を求めていた。
しかし、Scrumが普及し、ツール自動化が当たり前になって、その流れはある程度廃れた。

一方、2015年頃からRedmineユーザの兆候が変わってきた。
情シスやメーカーのような他業界の人達が入ってきて、いろんなRedmine利用事例を発表するようになってきた。
あるいは、PMOやSEPGのように、複数プロジェクトのQCDをモニタリングしたい第三者レビューの観点の人も入ってきた。
そんな話を聞くと、いわゆるプロジェクトリーダー層だけでなく、他業界で現場を回している係長クラスの人達にRedmineが当てはまっているんだな、と感じる。
つまり、Redmineユーザ層の変化が暗黙的にスムーズに行われたのではないか、と結果的に思う。

【6】参加者が現場に持つRedmineは、どれも唯一で、独自にカスタマイズされたRedmineばかりだと思う。
つまり、参加者が運用しているRedmineは、他のユーザの現場に持っていくと使えないだろう。
なぜなら、参加者が持っている問題意識や課題を解決するためのRedmineに特化しているので、他の現場ではコンテキストが違うからだ。

特に最近のredmine.tokyoのLTで聞かれるRedmine利用事例は、どれも個性的で、その現場でしか通用しないRedmineだ。
他に持って行っても通用しない。

だからこそ、そういうRedmine利用事例を聞くのは面白い。
そういう問題意識や課題から、なぜ、そんなカスタマイズしまくりのRedmineになってしまったのか、そういう経緯を知れるのが面白い。

【7】僕自身も最近はRedmineとチケット駆動開発の思索よりも、他のテーマのほうが多くなってきた。
今となっては、会計システムと同じように、チケット管理システムも普通の開発基盤になったように思える。
チケットでタスク管理することで、一元管理する発想は、もはや当たり前で、そこに新規性はない。

では、Redmineはどういう方向に進化すべきか？
どんな課題を解決していくべきなのか？
Redmineが提示すべき価値観とは何なのか？

その辺りは今後も考えていく。

様々な確率分布は正規分布のバリエーションに過ぎない

「経済数学の直観的方法 確率・統計編 (ブルーバックス) | 長沼 伸一郎 |本 | 通販 | Amazon」で、様々な確率分布は正規分布のバリエーションに過ぎない、という言葉で気づいたのでメモ。
以下はラフなメモ。

【参考】
17-3. 中心極限定理1 | 統計学の時間 | 統計WEB

　｢経済数学の直観的方法　確率・統計編｣のあとがきに代えて

「推計学のすすめ」「経済数学の直観的方法～確率統計編」の感想: プログラマの思索

統計学の考え方に関する感想: プログラマの思索

経済学は信頼性革命や構造推定により大きく変貌している: プログラマの思索

中心極限定理により、全ての確率分布を集めると正規分布に一致する。
逆に言えば、正規分布からあらゆる確率分布を導き出せる。

正規分布を有限回数の離散分布にすれば、二項分布になる。
1回あたり1万分の1ぐらいの確率分布を数年に渡って眺める場合、正規分布を1回毎の確率と時間を大きくスケール変換すればポアソン分布。

正規分布から、一定のバイアス部分、つまりトレンドだけを抽出すれば、ベキ分布。

正規分布の母集団から、少ないサンプル数で標本を取り出し、平均値を推測するのがt分布。
正規分布の母集団から、複数の標本を取り出し、複数の標本の不偏分散のバラツキを見たのがF分布。
正規分布の母集団から、任意の標本を取り出し、その不偏分散のバラツキを見たのがカイ二乗分布。

こういう理解を元にすれば、目の前にあるデータから、本来の母集団のデータ構造を推測するにはどのように考えたらよいか、を少しは考えやすくなると思った。

OODAループの時代は、大事なのは使命であり、目標は使命達成のための手段に過ぎない

あるブログ記事で、OODAループの時代は、大事なのは使命であり、目標は使命達成のための手段に過ぎない、というメッセージが非常に心に残ったのでメモ。

【参考】
成績未達のものは、きつく叱責すべきか - ウィリアムのいたずらの開発？日記

PDCAサイクルは、1年毎の年間計画でよく使う。
しかし、超短期のサイクルでは使いづらい。
また、コロナ禍のような時代では、当初立てた計画が無意味となってしまった場合、PDCAを最初から作り直さないといけなくなる。

「PDCAサイクル全盛の時代は、目標を数値化してたてて、それを達成したらちょっと伸びた目標を立て続けていく」そんなやり方だった。
しかし、OODAループの時代では、「会社で大事なのは使命であり、目標は使命達成のための手段に過ぎない。」
つまり、「目標が達成しようがしまいが、目標と現実との差を常に感じ、使命達成のために行動する。そのためには目標の変更もあり得る。」

OODAループの考え方は、More Effective Agile ~“ソフトウェアリーダー"になるための28の道標で知っていたけど、腹落ちできていなかったと思う。
飛行操縦士が敵機を撃ち落とすための意思決定構造を形式化しただけ、というイメージで、ソフトウェア開発や経営に活用するイメージがなかった。

OODAループでは、目標よりも、価値や使命が最重要であり、目標や計画は達成するための手段に過ぎない。
目標や計画よりも、価値や使命が最優先であるという行動を誘発させること。

そんなことを考えると、OODAループはスクラムと相性が良いように思える。

INSPIRED 熱狂させる製品を生み出すプロダクトマネジメントの感想～日本に足りないのはプロダクトマネジャーだ

INSPIRED 熱狂させる製品を生み出すプロダクトマネジメントを読んで、日本に足りないのはプロダクトマネジャーだと改めて思った。
ラフなメモ。

【参考
ソフトウェア・ファーストの感想: プログラマの思索 】
プロダクトマネジメントの感想～プロダクトオーナーはもっとチームの外のユーザに寄り添うべき: プログラマの思索

「クライアント-ベンダーアンチパターン」という根本問題: プログラマの思索

プロダクトマネージャに必要なスキルは何か？～「世界で闘うプロダクトマネジャーになるための本 ～トップIT企業のPMとして就職する方法」の感想: プログラマの思索

(2) 伊藤 大地 / Daichi ITOさんはTwitterを使っています 「NHKのデジタル人材採用の募集要項に並ぶ言葉がもはや「メディア」ではなくて、「テック」企業のそれ。全てはソフトウェアの構築とその応用…というデジタルの性質が募集要項にそのままアウトプットされている。 https://t.co/yIZHbpQG5y https://t.co/Yu4YGX97Wu」 / Twitter

一括請負案件では、どうしてもプロダクトマネージャーという役割は持ちにくい。
プロジェクトマネージャが案件の中心にいて、顧客とプロジェクトマネージャが対峙するというクライアント・ベンダー・アンチパターンにはまりやすい。

では、日本では、どんなソフトウェア開発でプロダクトマネージャーという役割が必要になるのか？
INSPIRED 熱狂させる製品を生み出すプロダクトマネジメントのあとがきでは、日本でプロダクトマネージャーが必要とされる場面は、スマホアプリの開発だという。

なぜなら、スマホアプリの開発では、利用ユーザの観点で、利用ユーザの導線を極力簡素化すべきであり、そのために機能はできるだけ削ぎ落とし、シンプルでワクワクするUIをいかに作り出すか、が大事になるからだ。
実際、一括請負案件でも、スマホアプリの開発が混じってくると、従来のウォーターフォール型開発で要件をガチガチに固めた後に機能やUIを開発したとしても、最後のユーザ受け入れテストで数多くの不満が出て収拾がつかなくなる場合も多い。
スマホアプリを実際に触ってみて、初めて操作感だけでなく、本来のユーザ導線を考えるという手戻りも発生しやすい。
僕もそういう現場を見てきた。

つまり、スマホアプリの開発はとりわけアジャイル開発に適していて、利用ユーザのユーザエクスペリエンスを重視するには、プロダクトマネージャーという役割の人が統括する方がうまくいきやすいと思う。

CISOは経営がわかる情報セキュリティ最高責任者である

CISOハンドブック ――業務執行のための情報セキュリティ実践ガイドを読んで、CISOは経営がわかる情報セキュリティ最高責任者であると知った。
ラフなメモ。

CISOハンドブック ――業務執行のための情報セキュリティ実践ガイドは、セキュリティの本というよりも、IT技術者が経営層になった時、こういうふうに考えたり行動していくべきで、こういう考え方を持つべき、という点が参考になった。
既存の経営陣に情報セキュリティの重要性を認識してもらうよりも、IT技術者自身が経営の知識を持つ方が手っ取り早いし、その方が実際はうまくいくと思う。

リスク管理は、予想される潜在リスクへの対策だけでなく、想定よりも状況がうまく行った時に備える場合もある。
たとえば、ベンチャー企業が社員20名から200名へ急激に成長した時、事業拡大の速度が速い分、いろいろな歪が出てくる。
上手く行っていたチームも、業務量が増えてメンバーが増えると、チームが回らなくなる。
ソフトウェア開発では人員増はうまくいかないという先入観がありすぎて、人員増を極力抑えるのは失敗しやすい。

事業が予測よりもうまくいくと、問題が少しずつ表面化する。
そこで、こんな対策がある。
業務をアウトソースして、固定費（人件費）費を変動費化する。
商流を変えて、固定費（人件費）を販管費にする。
業務をシステム化して効率化することで、固定費（人件費）を抑制する。

組織的には、事業や業務の観点で組織構造を変えて、チームを分けたり増やしたりする。
チームリーダーを社内で育成する。
それでも不足するなら、リーダーを外部から採用する。

つまり、良い状況に変わることも一つのリスクとみなして、リスク対策は考えるべき。