正しいものを正しくつくる

建築はソフトウェアづくりにおいてリファレンスとなりうるのか

　「代謝建築論」という本がある。 https://www.amazon.co.jp/dp/4395012086 　この本にインスパイアされて、「正しいものを正しくつくる」という本を書いている。仮説を課題、機能、形態に分類するための指針として、菊竹清訓の本質、実体、形態（か、かた、かたち）を参考にしている。　古くから、建築における営みはソフトウェアづくりにおいてリファレンスされてきた。クリストファー・アレグザンダーの思想がXP、アジャイルへと流れ続いているように、（建築

「お金も時間も決まっているが、実現したいことは見えていない」状況に向き合うべきなのか？

　予算や期日など計画周辺が確定している場合と、そうしたプロジェクト的な仕事ではなくプロダクトづくり、サービス運営のような場合では、どのように取り組むのか、スタンスが大きく異なる。　というのは、もちろんとして、問題は、全体の方向性があるなかで、細部の状況まで確定されているか、否かで、さらに取りうる作戦が変わるというところだ。　結論を言うと、以下の作戦が考えられる。　「精緻な計画づくり」とは、伝統的なプロジェクトマネジメントのナレッジがいきるところである。　「広さに

正しくやれているのに、残念な仕事

　何かにつけやるべきことを増やしてしまって、徐々に身動きが取れなくなってしまう。本来目指すべき目的の達成以上に、「これまでの仕事の考え方、判断軸とあっているかどうか」を優先してしまう。絶望的に時間が掛かり始めて、当初の想定よりも圧倒的に目処感がつかなくなっていく。要は、仕事を増やすことになるので、疲弊もする。やがてどこからと言わず、怨嗟の声があがりはじめる…。　このパターンは多くのことにあてはまる。例えば、新しいプロダクトや事業の開発、あるいはアジャイル開発をはじめて取り

その帰り道で、一人何を思うか？

　デブサミに登壇した。　2020年以来のリアル開催ということで、久々の場だった。今回はいつもの雅叙園ではなく、羽田空港。その場の違いがかえって20年前の初回、デブサミ2003を思い起こさせてくれた。　デブサミには他のカンファレンスに比べて、内輪感が少なく感じる。それだけ多種多様なテーマ、人が集まる場になっている、と言える。デブサミは「誰にとってもアウェイ」。20年かけて、参加者、登壇者、コンテンツ委員、スポンサーと一巡してきても、やはりアウェイ。いつまでもアウェイ、そ

「型」と「作戦」と「運用」

　チームや組織で、ある一定期間以上持続に、一つのミッションに向かって動いていく仕事。例えば、プロジェクトとかプロダクト作り、事業運営など。こうした高度なレベルの協働が求められる仕事は、あらゆる観点で難易度が高い。　まずもって、漫然と取り組んでも上手くいかない。ゆえに、「どのように進めるか？」という算段を立て、なおかつ共通理解にすることが前提になる。ところが、この算段・企て・目論見といった観点が弱い、場合によっては無いこともままある。この傾向は組織観点でも現場観点でも、この

そのプロダクト作りの「進め方の仮説」は立っているか？

　「スケジュール」というものを再考してみよう。スケジュールは必要だろうか、それとも不要だろうか。スケジュール = 役に立たないもの　あまりスケジュールに良い印象を持っている人は少ないかもしれない。過去の体験から「厳しい締め切り」「終わりの見えないタスク」などを思い起こすからだろうか。あるいは、スケジュールによって仕事の進め方が固定化されてしまい、かえってやりにくさを感じるからだろうか。　ひとたびスケジュールを細かく記述したところで、やっていることが変わることがあるか

成功を果たした、残酷なデットエンドを回避するためのプロダクトマネジメント

　苦労してプロダクトの仮説検証を推し進め、ようやくMVPのリリースへとこぎつける。実のところ勝負はその先にあって、MVPに至ってなお、最初の仮説の原型がなくなるくらい検証とアップデートを繰り返す。プロダクト作りにおいてよくある風景。　運良く事業としての最初の嵐を乗り切る。いや、乗り切ったと感じるのは実際にはだいぶ後になってからだ。無我夢中になって日々を重ねる果てに、気がつけば検証をとっくに終えていて、磨き込みを行っている自分たちチーム自身の姿に気づく。意識的な仕組み化が、

「星座」を見出すように、事業仮説を捉える

　事業開発とは「星座」のように捉えられるかもしれない。ふとそんなことを思った。　いくつもの星の光から、意味ある形を見出すのが星座。事業作りも、いくつもの仮説から、価値ある事業モデルを見出す、という点でイメージが合う。　自分で立てた仮説や、得られる情報群から、何が価値へと繋がるのか。俯瞰して、見極めていく必要がある。やみくもに、仮説にあたっていくわけにはいかない。捉えやすいように並べて、価値の繋がりを見出す。そのために「仮説キャンバス」というフレームを利用する。　「仮

なぜ、アジャイルに仮説検証を含めるのか

　書籍「正しいものを正しくつくる」で、仮説検証型アジャイル開発について言語化し、整理している。　なぜ、仮説検証を強調し、アジャイル開発と連動したスタイルを提案するに至ったのか。あらためて、整理をしてみる。観点として「解くべき問題の設定」と「解決手段の構築」の2つを用いる。　さっそく、結論はこのとおり。　解くべき問題が分かっているか？解決手段は決められるのか？の回答に基づき、方法を選択する。解くべき問題は分かっているし、解決手段も考えたらあらかじめ決められる場合は

価値をつくるのか？ vs 組織をつくるのか？

　組織で新たな取り組みを始めようとする。例えば、これまでの事業領域を越えて、新たな価値を創出するための探索的なプロジェクトや組織を立ち上げようと。こうした動き自体はとても良い、というか、こうした動き出しを作るために現代組織では相当なる労力を必要とする。だからこそ、この "灯火" ともいうべき動きを丁寧に扱わなければならない。そうチャンスは多くない。　ところが、この手の動きで直面する一つの事象がある。それはいつの間にか論点が「組織構造」にフォーカスがあたり、そこから抜け出せ

探索とは、知ること（差分型、越境型、探検型）

　たいていの組織において、探索する機会が不足している。「探索適応欠乏症」はいかなる事業にも起こる。事業の継続自体が「目の前のこと」への最適化を自ずと強いることになるからだ。だからこそ、探索と適応を事業、組織を選ばず、強調することになる。　デジタルトランスフォーメーションによる混乱が最盛期にあった頃は、私も探索適応は取り入れる領域は「絞るべきだ」と主張した。「組織の隅々まで、探索せよ」というのは、そのケイパビリティもろくにないところでは土台現実に欠ける話だった。トライアルを

"表"だけではなく"裏"までプロダクトマネジメントする

　プロダクトマネジメントには2つの世界がある。一つは、ゼロからイチ。もう一つは、イチから先。前者は「新規事業」であり、後者は「既存事業」の認識へと段階的に移っていく。　新規から既存への認知的な移行は比較的時間をかけておこなわれるが、その本質は比較的早く移り進んでいく。事業が一定の成果をあげて、持続する段階に入ったところで、効率への最適化にモードが切り替わる。これは人の意図が介在せず、ほぼ無意識に取られると思って良い。　だからこそ、「次の価値」、「まだ見ぬ価値」を見出す

なぜ、本を8冊もつくる必要があったのか？（前編）

リーン開発の現場　最初に本を作ったのは「リーン開発の現場」だった。　原著は「Lean from the Trenches」。Agile2012という海外のカンファレンスで手に入れた紙の本を、帰りの飛行機で読んでいるうちに「これは日本に届けたい」と思い立つに至った。著者のHenrik Kniberg（ヘンリック・クニバーグ）については、「塹壕より Scrum と XP」で認識していた。　今は、Spotify-modelの人と言ったほうが伝わるかもしれない。カイゼン・

「整合を取ろうとしてみる」ことで、必要な「変化の段階」に気付ける

　先日の「シン・正しいものを正しくつくる」でコンセプトにおいたのは「整合を取る」ということだった。　左に仕様、右にソフトウェア。　左に仮説、右にプロダクト。　左に人材モデル、右側に育成施策。　左右の整合を取る、取れるように左側を見出し、あるいは右側の実現に注力する。得てして、左が整っていないのに、右側だけを思い込みや深く考えずの取り組みだけで進め、期待外れになる。だからといって左側が大事だからと莫大な時間を投じたところで、正解に辿り着けるわけでもなく。やはり結果は

フォローしませんか？