2019/07/01 に開催された プロダクトをつくるとはどういうことなのか？ -正しいものを正しくつくる- のイベントレポートです。

●イベント概要
プロダクトをつくるとはどういうことなのか？
書籍「正しいものを正しくつくる」のサブタイトルとなっているこの問いにわれわれはどのように向き合っていくと良いのでしょうか。

今回はDevLOVEは、「現場で役立つシステム設計の原則」の著者増田 亨さんと、「正しいものを正しくつくる」の著者市谷 聡啓さんのお2人で、この問いに答えていきたいと思います。

2014年に共通の理念を見出し、ともに会社を立ち上げた2人。
それから5年。どこにたどり着いているのか。余すことなくお届けします。

■プロダクトづくりのためのソフトウェア設計スタイル

増田亨 さん

期間や予算に縛られるのではなく
永続的に続くプロダクトと考えると
これまでの受託開発はなにか違うのではないか？

●現場で役立つシステム設計の原則
・出版2周年！
・意図せず2年間を振り返る内容になった

●プロダクトづくり
・不確実性との戦い
・終わりのない進化と成長

●複雑さとの戦い
・構成要素が多い
・構成要素間の関係
・拡張と変更の繰り返し
　　-> 建築や土木とは異質の挑戦

●構造と秩序
・何も気にせず追加すると雑然としていってしまうもの
　　どう秩序を保ち続けるか

●不確実性と叩くためのソフトウェア設計スタイル
・創発的な設計活動
・柔らかなモジュール構造
・20%に投資する

●創発的な設計活動
・局所解は求められるが、構造を考えると視野が狭すぎる
・仮説を立てるためには、視野を広げて観察を続ける
・順に、平行して実験する
・動いた後の考察

何が正解かわからないを前提に進める
うまく行ったら、何が良かったのか、より良くするにはを考える

●設計の基本
・関心を分離する
　　人間の頭の中
・モジュールに分割する
　　ソースコード

●モジュール分割
・入力と出力で分割
　　機能単位で分解
　　大機能、中機能、小機能で分割
　　画面、通信、データベースの操作
　　-> トランザクションスクリプト
　　　　どうしてもモジュール構造を変えずに
　　　　ロジックで変更するアプローチになる
　　-> 硬直化、レガシー化
・計算と判定で分割
　　型で分解
　　ボトムアップ、トライ&エラー的に見つけていく
　　-> ドメインオブジェクトモデル
　　　　手持ちの型では表現できない計算結果
　　　　これを実現するために、新しい型を追加する
　　-> 柔軟性

●型
・int, long, booleanだけではシステムはつくれない
・値の範囲を制限
・有効な操作を定義
・ひとつの入れ物にカプセル化して分解していく
・まず型があった
　　抽象データ型
　　-> 柔軟性をもたせよう
　　-> オブジェクト指向
・型を組み合わせてすっきりできるなど新しい発見

●機能で分解すると
・計算ロジックの断片化、重複
　　-> 修正が漏れたり
　　-> 同時に修正しようとして揃わなかったり

●直接的な写像
・ソースを読んでいてlongがあっても、何に使うか分からない
・金額には金額型
　　longのfieldを持っているだけかもしれない
　　でも、1:1での紐付けができるようになる

●型と計算に焦点を合わせた時の考え方
・データの塊が
　　金額計算に関わるのか
　　納期に関わるのか
・テーブルや画面のパーツも分割単位が変わるかもしれない
・意味のある単位で分割することで柔軟性が生まれる
・計算の文脈から、画面やテーブル間のつながりが見えてくる

●20%に集中する
・ここまで出てきたことを
・全員で全部やっても破綻するのは見えている
・パレートの法則
　　重要な型を考えていくと 20%程度 に収まる
　　重要な型で 80% を網羅できる
　　のこりの20%は例外として扱う
　　適用できる 80% にはある意味手を抜く
・バランスを考えれば、全体のコントロールができるようになる
・中核を見極めて、末端で消耗しないようにしていく

■アジャイル開発は2度失敗する

市谷 聡啓 さん

●正しいものを正しくつくる
・6/14 発刊
・重版決定！

●1度目の失敗
・Do Agile Be Agile
　　どっちにしても難しい

●プロセスの観点では
・少しずつ、繰り返し
・早く形にします
・早いので少しずつです

●早く（少しだけ）形にできることの意義
・9つの効果を期待して進めていく
・全部が当てはまることはない
・1つも当てはまらないのは、やっていることが違っているかも

●「早く少しだけ形にする」の難しさ
・車を作る場合
　　タイヤからつくっても最後まで乗れない
・移動したいと捉えると
　　スケボー、キックボード、自転車、バイク、車

●どうやってやるか
・教科書通りにやれているのか はできる
・早く少しだけ形にして新たにわかってきたこと
　　これをどう受け止められるようにするのか？が難しい

●学びが次の不確実性を連れてくる
・そのままバックログに積むと混沌としてくる
・「状況を整えてください」だけでは机上の空論

●トレードオフが成り立たない現実
・3ヶ月後に売上が立たなかったら終了
・その中で何を優先するか？

●なぜアジャイル開発ができるようになったか
・アジャイルサムライ以降、トレードオフを回せるようになったから
・一旦、トレードオフが成り立たない現実を見ないようにした

●変化を受け止められる余白をつくる
・余白をつくると食いつぶすのがヒト
・プロダクト全体で確実性を高めようとすると
　　要件定義して...また机上の空論
・短いスプリント期間で固めていく

●余白づくり
・スプリント単位ではすぐに食いつぶす
・戦略的にプロジェクトに盛り込む

●スプリント強度を高める
・確実性を高めていく

●プロジェクトとプロダクトを二項対立で考えない
・人の集中は続かない
・適切なタイムボックスを設計
　　時間やお金もセットで
・プロジェクトでの局所最適で、全体の判断を誤ってしまう
　　同時に考えることが必要

●2度目の失敗
・プロダクトオーナーと開発チームの間にある境界線

●不吉なにおい
・「こいうもんだ」
・間違っていないか？という問いがない
・プロダクトオーナーが正解を持っているわけではない
　　その中で確からしさを仮説検証していく

●理想的なプロダクトオーナー
・仮説検証ができて知識と経験がある
・新規事業やサービスづくりのタイミングで手が空いている
-> だいぶ分が悪い
-> 間違ったものを正しくつくる状況へ

●仮説検証型アジャイル開発
・繋がりを作る
　　仮説検証とアジャイル開発の統合
　　開発チームがユーザの欲しいものを理解しながらつくるなら
　　仮説検証での学びが必要
　　分断していたらスピードは出てこない
　　何が良さそうなのか、を流れの中でアップデートしながら進める
・段階をつくる
　　これは本には書かれていない最近の考え
　　理解とプロダクトの段階の統合
　　何が必要なのか見当がついていない
　　　　競合や既存の手段を代替して検証
　　何が問題なのかわかってきた
　　　　ハリボテをつくる
　　つくるものが見えてきた
　　　　分解してつくる
・作らない、利用する、その上でつくる

●段階のデザイン + 変更容易性 = 適者生存の構造化戦略
・勝ち筋が見えてきた
　　今後の変更に耐えうる構造重視の設計
・この話が通じないことは多い
　　2段階目くらいで「予算があるからつくりたいんだけど」

体験版はここまでです
続きは製品版でw

●「正しいものを正しくつくる」という言葉が人に傾きを与える
・問いとして使いたい
　　必要としているものをちゃんとつくれているのか？
・この問いは自分自身に向けて
　　次の自分につながっていく
・自分で自分の有りたい方向に向き合えているのか

「正しいものを正しくつくれているか？」

■対談

増田亨 さん
市谷 聡啓 さん

●レビューの話をしておきましょう
・増田さん
　　第一印象は、よくここまで言語化したな
　　出てきたレビューは逆方向だった
　　ただ、これまでの会話ではもっと濃厚で生々しかった
・市谷さん
　　単純な指摘ではない、考えさせられる
　　増田さんの指摘で増えたポイントも
　　戦略と戦術、作戦が抜けてないか？

　　こんなに厚いとは思ってなかった
　　カイゼン・ジャーニー +2,30ページくらいかと思ったら
　　縦書きと余白もあるかも

●観察 -> 仮説 -> 実験 -> 考察
・増田さん
　　市谷さんを見ていて感じた
　　観察と考察の量がすごい
　　本などのインプットの量がすごい
　　終わった後も引きずっている
・市谷さん
　　観察は、どれだけ経験があるか、他の業界から持ってくる
　　考察は、言語化が大切。概念化は意図的に進めなければできない

●重要な20%をどう見極めるか？
・増田さん
　　経験は必要
　　どんなことをやっているか
　　　　バサッと半分に切って、どっちが重要かは判断できる
　　　　これを繰り返せば 25%
　　　　この中に重要な 10%は含まれている
　　　　残りの10%は、後で見えてくる
　　　　はじめに切ってしまった 50%に含まれていることも
　　業務でいうと
　　　　お客さんの市場ポジショニングが効いてくる
　　　　リーダー、フォロワー、ニッチャー、チャレンジャー
　　　　でやることが決まってくる
　　　　大変なのはチャレンジャー

●20%を見極めるトレーニング方法は？
・増田さん
　　観察。幹を切ったら影響が大きい
　　ソフトウェアなら壊せる。壊してみて影響範囲を見る

●プロダクトの成長が長くなってくると、必要な強みが変わってきそう
・市谷さん
　　関心事が変わってくる
　　局面ごとに長けた人は必要
　　今のユーザは捉えられた、次をねらっていくと活動が変わる
　　プロジェクトの視点が必要

●不確実性って何なんでしょうか？
・増田さん
　　つくることによって見えてくる不確実性
　　情報が増える、学習することで、新しい知見から選択肢が増える
・市谷さん
　　これはソフトウェアだけなのか？
・増田さん
　　建築だと、失敗を失敗と言わない
　　建築会社の中では学びでも、表に出ない

●観察の幅広いinputとは？
・増田さん
　　観：広く見る
　　察：深ぼる
　　両方を意識することが大切

　　市谷さんのinputが長けているポイント
　　気が短いこと
　　　　思い立ったらすぐ調べる、すぐ動く
　　貪欲さ
　　　　知識に飢えるところが必要

●仮説検証型アジャイル開発は、
　自分なりに作り上げた正解を否定していくということ？
・増田さん
　　否定する必要はないが、満足しない
　　未来に対する欲求
・市谷さん
　　信じない はある

●言語化するためにはどうすれば？
・増田さん
　　日記などでも良い
　　言語化して、構造化していく
　　きっかけは市谷さんからの登壇依頼
　　LTなどでも良い
・市谷さん
　　公演駆動のときもあった
　　週に一回noteを書いている
　　指を鍛える

　　twitterも言語化のトレーニングじゃないですか？
・増田さん
　　140字縛りでの表現、うまくいくとは楽しい
・市谷さん
　　自分のために書いている部分も多い
　　反応してくれる人がいると嬉しい

・市谷さん
　　増田さんのやり方の呼び方は何が良い？
・増田さん
　　オブジェクト指向、XP
　　型で考えるアプローチ
・市谷さん
　　建築などでも流派がある
　　日本のソフトウェア開発者で、なんとか流って無い気がする
・増田さん
　　向こうではコミュニティという言葉を使っている
　　日本では設計コミュニティってないね
　　一人を挙げるならケント・ベック
・市谷さん
　　増田流？増田式？w

■感想

バサッと半分に切って、どっちが重要かは判断できる
これを繰り返せば 25%
この中に重要な 10%は含まれている
残りの10%は、後で見えてくる
はじめに切ってしまった 50%に含まれていることも

なるほど！いつも割合を気にせずに、肌感覚でコアだなと分類しているだけでしたが、20%というしきい値を考えると、こんなにスッキリしたアプローチができるようになるのですね。

●「早く少しだけ形にする」の難しさ
・車を作る場合
　　タイヤからつくっても最後まで乗れない
・移動したいと捉えると
　　スケボー、キックボード、自転車、バイク、車

改めてこの図を見て、次の段階でつくるものに、目的以外の何が引き継げるのだろうと、勝手に問いをいただいていました。
引き継いでいるものが 車輪 -> ハンドル -> ギア -> エンジン と捉えると、その仮説を検証するためにつくったコアなロジックなのかもしれないな、と。そして、コアなロジック以外はほとんどをつくりなおす。

コアなロジックを切り出して、他でも利用できるようにしくみをつくっていくことが、ソフトウェアでの学びを広げ深めていくことなのかな、と感じました。

増田さん、市谷さん、medibaの皆さん ありがとうございました！