rtree☂️🛡️

大手町にあった逓信総合博物館です。 東京都下に住んでいた昭和40～50年代の小学生は、高学年になると親の許しをえて、子どもたちだけで都心へ出かけました。わりと厳しい家庭でも、友だちと一緒ならばとＯＫが出た。 この博物館や、すぐ近くにあった電気通信科学館、神田須田町の交通博物館、竹橋の科学技術館、そして13号埋立地の（当時はお台場なんていいません）船の科学館などに行った。理科や動物の好きな子ならば上野の科学博物館へ。 広い館内を走ったり、ボタンをあちこち押しまくったり。売店のみやげ物をいじったり。 今でも思い出すけれど、あれは博物館をめぐる楽しさだけでなかった。子どもだけで改札口を通り抜けて電車に乗り、流れていく街をながめる解放感。都心の雑踏、大人の世界に身を置く緊張感。

私がPMOが難しいと思うところの一つは、 ・どいつもこいつも我儘 ・しかもそいつらが自分より社内で上位ランク なことなんじゃないかと思いますね コンサルのシステム開発PJTだと、社内だけでも ・業務チーム ・ソリューションチームA（ERPとかSFDCとか） ・ソリューションチームB（インフラとかフロント部分のスクラッチ開発やる人たちとか） ・ソリューションチームC（AI系とか） ・デザインチーム みたいな混成具合になっており、それぞれのタワーの責任者がM～Pあたり、しかも利害も一致していなくしょっちゅう喧嘩腰、とくるので、CランクとかでPMO回すのは鋼のメンタル必要と思うのよね

PMOの難しさは「自分では決められない・動けない立場なのに、プロジェクトを動かさなければならない」こと。 そのためには、腹落ちさせたうえで、相手が自ずと答えを見出していけるようなアプローチが必要。 調整力が甘いと起きること ・決まらないまま時間だけ過ぎる ・依頼しても動いてくれない ・結局PMOがこっそりやってしまう PMOとしてやるべきこと ・状況の見える化。課題、リスク、タスクと担当者の明確化 ・論点や判断基準を絞って決めやすい状態を作る ・背景、目的を伝え納得してもらう ・頼みっぱなしにしない ・現場のキーパーソンと日頃から関係構築する

私がPMOが難しいと思うところの一つは、 ・どいつもこいつも我儘 ・しかもそいつらが自分より社内で上位ランク なことなんじゃないかと思いますね コンサルのシステム開発PJTだと、社内だけでも ・業務チーム ・ソリューションチームA（ERPとかSFDCとか） ・ソリューションチームB（インフラとかフロント部分のスクラッチ開発やる人たちとか） ・ソリューションチームC（AI系とか） ・デザインチーム みたいな混成具合になっており、それぞれのタワーの責任者がM～Pあたり、しかも利害も一致していなくしょっちゅう喧嘩腰、とくるので、CランクとかでPMO回すのは鋼のメンタル必要と思うのよね

デザインドキュメントをしっかり書くとエージェントに投げつけるだけでまぁまぁいい感じのパッチが錬成できるようになってきたけど、それはつまりデザインと向き合う時間ばかり増えてコードと向き合う時間が減ってしまい心の中のプログラマーが嘆いている

AIに巨大なプログラムを書かせているとき、本質的なのは「AIが1秒あたり何行書けるか」ではない。実際に効いてくるのは、コード量が増えるにつれて、開発オーバーヘッドがどうスケールするかである。 AIが素で単位時間あたり一定量aのコードを書けるとしても、実開発ではコンパイル、テスト、デバッグ、調査、影響範囲の確認といったオーバーヘッドが必ず乗る。問題は、そのオーバーヘッドがその時点tでのコード全体量C(t)に対してどう増えるかだ。 単純化すると、以下の二つのケースがある。 1. オーバーヘッドが C にほぼ比例するケース 2. オーバーヘッドが log C 程度に抑えられるケース コンパイル時間は、フルビルドだと1.に近い。 原因の切り分けが二分探索的に進められる種類のデバッグでは、2.に近い。 1.と2.のケースにおいてC(t)が時間tに対してどのように増加するか計算してみたのが添付図だ。 結論としては、 1.は、C(t)は√tに比例するので、コードを10倍にしようと思うと100倍の時間が必要。 2.は、C(t)はtに対してかなり直線に近い増え方をする。 である。 言うまでもなく1.と2.とは雲泥の差である。ソフトウェア工学のかなりの部分は、1.の世界をいかに2.に近づけるかという試みだったとも言える。 コードを書くときの認知的・構造的オーバーヘッドも、放っておけば前者に寄りやすい。しかし、モジュール分割、関数分割、クラス分割、依存の局所化、テスト単位の分離をきちんと行えば、そのコストを後者に近づけられる。そうなるようにプログラミング言語やモジュール機構、テスト手法、設計原則は発展してきたわけであり、マイクロサービスやクリーンアーキテクチャも、その文脈で理解できる。 AI時代になると、この問題はむしろ先鋭化する。AIはコードそのものを書く速度が高いぶん、設計や検証のオーバーヘッドの悪さが、以前よりはっきり露呈するからだ。 設計が悪く、影響範囲が広く、テスト単位が粗く、どこが壊れたのかを絞れない構造になっていると、1.に近づく。すると、せっかくの生成速度がオーバーヘッドに食われる。 だから、今後AIで巨大なプログラムを開発するエンジニアに強く求められるのは、単にプロンプトがうまいことではない。 システムを分割し、影響範囲を閉じ込め、検証単位を細かく設計して、開発全体のスケーリング則そのものを改善する能力だと思う。