DevLOVE「オブジェクト設計とリーン開発、その実践」に参加しました

@名古屋市中区錦1-15-8 アミティエ錦第一ビル 4F Coworking Space A+LIVE セミナールーム

正しいものを正しくつくる
ギルドワークス創業おめでとうございます！
増田さんのプロジェクトで増田さんに叱られながら仕事してみたいなぁ。

第一部 オブジェクト設計エクササイズ [13:10〜14:00] 増田亨氏

実践的な設計って、なんだろう？ from 増田 亨

設計とは、変更コストを下げるためにコードを整理整頓する実践的な工夫

プロセスやツールよりも設計

コードを整理、整頓する。
それは、変更コストを下げたいから。
（作って終わりならいらないけどね。）

実践的ってなんだろう？

いくつかの観点で、対岸を行ったり動きながらバランスを取る。
（全体<->部分、長期<->短期・・・）

具体的にどうやるの？

変更コストの原因を知る。
変更コストの最大の敵は「重複したコード」。

重複したコードのいやな臭い（Martin Fowler "Refactoring"）

• 長いメソッド
• 大きなクラス
• たくさんの引数

マスダ流重複の臭い判定基準

• クラス：50行（100行）
• メソッド：3行（5行）
• 引数：0（1）

これを超えたら警戒警報！
（カッコの中はチーム用に緩めた数字）

コード整理の基本パターン

• Value Object
• 振る舞いを持った区分
• ファーストクラスコレクション

Value Object

immutableがポイント。
例）Stringクラス
内部の値を変えずに、新しいObjectを返している。

getメソッドをつくらない。
getをつくるとロジックが散らばる。
データのある場所にロジックを寄せる。
setメソッドもつくらない。
setをつくると状態管理のコードが散らばる。
=> immutable（不変オブジェクト）

プリミティブなクラスは使わず、業務（ドメイン）固有のクラスを作る。
例）
String, StringBuilder, List<String> => ProductName, Remarks
BigDecimal, Integer => Money, Quantity, Unit
Calendar, Date => InitialDate, DueDate, ValidTerm

振る舞いを持った区分

enumにメソッドを持たせる。
定数も、関連するロジックはそこに閉じ込める。

ファーストクラスコレクション

privateなコレクション、publicな振る舞い。
コレクションをgetして操作するとあちこちにコードが登場する。
例）
Customers, OrderLines, UsageHistory, ToDoList・・・

コードの整理　アンチパターン

• Smart UI（画面単位で設計）
• トランザクションスクリプト（機能単位で設計）
• Active Record（テーブル単位で設計）

=> 必ずコードが重複する。

Smart UI => 画面間で重複が発生する。トランザクションスクリプト => 機能間で重複が発生する。
Active Record => テーブル間で重複が発生する。

コードの整理　グッドパターン

• ３層＋ドメインモデル
• 業務の関心事（業務知識）に基づき設計する

=> 変更が簡単

• 仕様変更は業務から発生する
• 業務の関心事の依存関係がクラスの依存関係になっている
• 変更の対象箇所以外でわけのわからない副作用がおきない

第二部 リーン開発の現場 [14:10〜15:00] 市谷聡啓氏

理想とはたとりつくべき場所のことではなく、ありたい姿に向かい続けることなんだ！

誰かが正解を持っている訳ではない

開発の命運を握る２つのレバー

• 期待
• リスク

期待

関係者が互いに持っているプロダクト/プロジェクト/チームへの暗黙的な望み

期待マネジメント

期待を明らかにして適切に調整しつづける。役割と時間を超えて。

チーム => プロジェクト => プロダクト => ビジネス => 組織

レイヤーごとに目的と期待がある。
レイヤーを超え、役割を超えた理解が必要。

Moving Management Target

期待とリスクのバランスは時間とともに変わっていく。
時間を超えた理解が必要。

インセプションデッキ

期待マネジメントのツールの１つ。
大事なのは、アウトプットではなく、その過程でお互いに理解しあうこと。

仮説検証型と最短距離型

目的実現のための選択肢がいろいろある。
=> 何を選ぶか決めるために試行し検証する。
=> 検証から何をどう作るか徐々に決められる
=> 手段と対象がわかれば、最短距離でつくる

スコープが決まってないのに期限だけ決まってる
=> 超危険
=> 仮説検証時は期間契約、スコープが決まれば請負契約

大事なのは、フェーズによって戦い方が変わるということ。

仮説検証型のPlan

リーンキャンバス（仮説）
=> エクスペリエンスマップ（検証）
=> ユーザーストーリーマッピング（仮説）
=> インセプションデッキ（検証）

参考）
「開発戦略は「意思決定」を遅らせろ！」（稲垣 公夫）

最短距離型のPlan

CCPM
パーキンソンの法則：バッファを使いきってしまう。
=> バッファをプロジェクト全体で管理する。

荒ぶる計画を飼い慣らす

• 要求レベルをMust, Want, Tryで可視化する
• プロジェクトの8-9割でMustを実現できる見込みを立てる
• 残った工数でWantを開発する

仮説検証型のDo

なんのための反復？
何を検証するのか？

カンバン（仮説検証型、最短距離型）

仮説検証型：タスク、課題解決の可視化 => タスクボード
最短距離型：全体フローの見える化 => カンバンボード

仮説検証型と最短距離型の見極め

=> インセプションデッキ

ソフトウェアを創り上げるもの

誰が、誰と、誰のために
どういうルールで、何を作るか

リーン開発の現場 P.109

理想とはたとりつくべき場所のことではなく、ありたい姿に向かい続けることなんだ！

第三部 Q&A [15:10〜16:00]

• DDDをどれくらいかけて覚えれば？
  => 2008年からはじめてわかりはじめたのが2012年。現場で続けるのが一番。
• フレームワークを使っている場合（コード自動生成）の折り合いは？
  => 大嫌いだから使ってない。折り合いの付け方もノウハウ。
• クラスが多くなったときのまとめ方は？
  => 業務にあわせてパッケージを構成している。
• お客様に丸投げされたときにどうすれば？
• バッファと見積の合意方法は？
  => QCDSのトレードオフスライダーを使ったりする。
• そもそもドメインって何？
  => まあ、気にしないほうがいい(^^)。カタカナは日本語にするとよい。
• インフラからプログラマになるとき何を学べば？
  => 今はインフラもコードで自動化する時代。そこからはじめては。
• 設計の価値をどう伝えれば？
  => 相手が開発者であれば、変更が大変だったネタを思い出して盛り上がる。そこからスタートすると伝わりやすい。設計とは何かとか良い設計とはとかのアプローチは必ず失敗する。ただ、人がつくったコードで痛い目あってる体験共有からだとうまくいかない。
• 期待をどうマネジメント？どうまとめる？
  => インセプションデッキを使う。困ったらぜひギルドワークスへ(^^)。インセプションデッキの期待が高くなり過ぎないようにしれっとね。
• 設計の考え方をどう共有するか？
  => 経験がないのでわからない。若い頃は意地になって相手を潰すぐらい勉強した。
• カンバンをどう広めるか？
  => いきなり実プロジェクトでやるのはリスクが高い。カンバンだったら、まずは、自分でやれる範囲でやるとか。失敗できるところでやってから。
• どんなドキュメント管理してる？
  => クラス図やドキュメントを全部作ってない。ドメイン知識が増えれば、ドキュメントがなくてもわかる。新しいメンバーにはドキュメントではなく、業務を覚えてもらう。業務がわかれば、ソースが読める構造になっている。
  => IDEが優秀だから。IntelliJ IDEAがオススメ。すぐ乗り換えよう。
• どんな工程？
  => 全部網羅的に設計せずに、重要な部分だけ抜き出して設計してる。
• 開発スピードが落ちない？
• マスダ流は厳しすぎない？
  => 実践でいきなりやるのは難しいかもしれないが、実際にやって、まずは体験してみて。
• なんのロジックも持たなくて、単純な置き換えでもクラス化する？
  => する。名前がほしいから。