Pinned
#エンジニアリング組織論への招待
が「技術書大賞（翔泳社）」と「ビジネス書大賞（ブクログ）」の二冠をいただき、ついに技術とビジネスがつながることが当たり前の時代に！！
広木 大地/ エンジニアリング組織論への招待
広木 大地/ エンジニアリング組織論への招待
27.3K posts
広木 大地/ エンジニアリング組織論への招待
@hiroki_daichi
株式会社レクター代表/朝日新聞社社外CTO/㍿グッドパッチ、スパイダープラス㍿ 社外取締役/ 日本CTO協会理事 /主著『エンジニアリング組織論への招待』/新著「AIエージェント 人類と協働する機械」発売中/⿻
広木 大地/ エンジニアリング組織論への招待’s posts
人間にはあらかじめ組み込まれたバグがあります。それを「認知の歪み」と言います。多分どこかでみたことのある景色ばかりなはず。まずは、自分が歪まないなんていう幻想を捨てることです。みんな歪む。だけど、それを認識できる人間が不確実性の時代においてリーダーシップを持てる。
エンジニアリングチーム作るとき、例えば4000万の原資あったら、400万x10人じゃなくて、1000万x4人にするだけで生産性10倍以上ちがうという原理を覚えておけばそこそこうまくいく。なぜならコミュニケーションコストがプロダクトづくりにおける最大の問題だから。
ソフトウェアエンジニアに向いていない人の3つの特徴。
一、エラーログを読まない。
二、エラーログを読まない。
三、エラーログを読まない。
ソフトウェア開発における「時間の値段」は想像する以上に高い。
一般的に同一のシステムを開発するのに：
- 10%の時間(1割短縮)を買うのに1.5倍のコスト
- 50%の時間(納期半分)を買うのに16倍のコスト
というのを頭に入れておくと、ビジネスと開発コスト効率のイメージはしやすいと思う。
正直いうと「業務時間外に勉強すべきかどうか」みたいな頭の悪い質問をしようと思う時点で、頭が悪いから勉強してもしなくてもどちらでも良いです。
仕事を「タスクを完了すること」ではなく「わからないことを減らすこと」として捉え直すと、優先順位が一変する
夏休みの宿題で、自由研究や苦手科目を後回しにして最後まで憂鬱だった経験はないだろうか
ベンチャー、うまくいってる時は成長が全てを癒してくれて、小さな個人的対立も意識することなく楽しい。徐々に成長がサチるころに、新しく入った人に先にいた人が防御、回避、攻撃的反応をするようになり摩擦が起きる。時を同じくして技術的負債が問題となり、「つまらなくなった」と初期メンが辞める
ソフトウェアの欠陥は見積もりに対して20%の余分な時間を与えることで、半分以下になります。
このグラフはFive Core Metrics からの引用です。どこで読んだか思い出すのに苦労してたのですがやっと見つけた。
おおよそ20%という数字は、経験則的にも多くのテック企業が採用している改善への投資です
ペアプログラミングをしていると、成長を阻害する習慣が見えてくる。
最も印象的だったのは、エラー画面を一瞬で閉じてしまう人だった。動体視力を試されているのかと思ったが、実は全く読んでいなかった。エラーメッセージという貴重な情報を捨てて、自分のコードを漠然と眺めている。
日本でアジャイルが広まりにくい理由は実は単純なんです。
不確実性を避けたがる文化的特性。
アジャイルの本質は不確実性に向き合う考え方です。わからないことがあったら実際にやってみる。失敗したらそこから学ぶ。これが基本的な発想。
ペアプログラミングで新人エンジニアを見ていて気づいたことがある。コードリーディングの比率が圧倒的に低い。エラーが出ると自分の書いた箇所をまじまじと眺めて、フレームワークのコードは読まない。
理由を聞くと「難しそうだから。早く終わらせたいから」。
ソフトウェアプロジェクトで人を増やしても速くならないのは、コミュニケーションコストが人数の二乗で増えるから。
100人月のプロジェクトの標準工期は12.5ヶ月。これはJUASの統計で工期が工数の三乗根に比例することが分かっている。
大学の先生などで、レポートをChatGPTをつかってあまり考えずにやっている学生を見つけたいと思ったら、お題の中に存在しない学術用語を入れてみてください。
存在しないにも関わらずそれっぽく回答する人がいたらそいつがルパンです。
プロジェクトマネジメントでよく見かける光景があります
タスクを細かく分解して、ガントチャートを作って、進捗を追いかける。でも気がつくと予期せぬ問題で炎上している
実はこれ、タスクという「見えるもの」ばかり追いかけて、リスクという「見えないもの」を軽視しているからなんです
僕が「技術的負債」という言葉を使うとき、その正体は「ソフトウェアの複雑化による開発出力の低下」そのものでなく、その認識を意思決定者と共有しづらいという視界の非対称性にこそあると考えていて、対策はその観点から行われるとうまくいくことが多い。
アジャイル等の原理がその言葉の意味から「速さ、敏捷性」に関連づいて説明されることでわかりにくくなっている。ソフトウェア開発における重要な原理は「Fail-Fast」であり、静的型付けも自動テストもカオスエンジニアリングもスクラム開発もプロダクトマネジメントも原理は「早期失敗」することだ。
CTO/VPoE/TechLead(スペシャリスト)の仕事って一体どう言う役割分担なの？みたいなことを聞かれる。
これはクネビンフレームワークで捉えるとわかりやすい
CTO は Chaoticな問題 -> Complex
VPoE/EMは Complexな問題 -> Complicated
TechLeadは Complicatedな問題 -> Simple
不確実性が減っていく
1on1でいきなり将来の話を聞かれても困りますよね。
キャリアについて語り合うのが良い1on1だという風潮があるけれど、実際のところ多くの人はもっと身近な悩みを抱えている。
ブリリアントジャーク、半分ぐらいは、自分より下のレベルの人に対してのコミュニケーションが高圧的だったり、馬鹿にしたような態度を取ったりすることによって表面化したりする問題が多くて、自分より上のレベルの人間に対してはそういった面を見せなかったりするから、賢くて面白い奴だなぁと思って
Quote
Ryo Tomidokoro
@hanhan1978
「ブリリアントじゃないジャーク」には、会ったことある。 x.com/konifar/status…
最近、エンジニアリング組織の健全さの指標に、
d/d/d というのを用いてる。
deploys / a day / a developer の略で
1日あたりのデプロイ回数を開発者数で割ったもの。
だいたい、0.1 以上なら健全と言える
これが悪化しているとき、最上流含めたエンジニアリングパイプラインのどこかに問題がある
障害報告を書くのは始末書ではありません。失敗は大事な資産なんです。
システムにバグはつきもの。大切なのは、その失敗を次に活かせるかどうか。
エンジニアがいい会社に入りたかったら、
ブログで失敗体験を共有してるところがいいですよ。
意識高いカッコつけてる感じがするのは、次点ですね。まだ全然ましです。
ダメなのはメンバーが全然発信してない。採用記事しか出てない。採用記事に具体性のないこと書いてあるところ。
ひさびさに新劇エヴァみたけど、ネルフって働きたくない組織だなぁ。
過干渉で感情的な割に説明不足の直属の上司（ミサト）は、セクハラ・アルハラしてくるし、ライバル意識剥き出しの同期（アスカ）、情報の透明性が全くない幹部（ゲンドウ）、親会社の（ゼーレ）事情で振り回されるし。
Linuxの出始めにあんなのはおもちゃだから実用に使うなんてどうかしてる！っていう人いたし、クラウドの出始めにもあんなのはおもちゃだと言ってる人いたし、ノーコード的なものも、おもちゃだなーっていってスルーしてるうちに仕事の大半がノーコード的なアプローチになってもおかしくない。
開発チームにありがちなバッドパターンは、
1、マネージャーが不安ゾーンでメンバーがコンフォートゾーンの「過保護アニキ」パターン
2、マネージャーがコンフォートでメンバーが不安ゾーンな「マウンティングボス」パターン
3、マネージャーが不安でメンバーが無関心な「離職サイクル」パターン
