Developers Summit 2021 Summer (2021/07/30)の登壇資料です。 https://event.shoeisha.jp/devsumi/20210730/session/3249/
ビジネス考えてるかい？事業の持続的成長を促進させるシステム設計の考え方Jul 30, 2021 @ Developers Summit 2021 SummerREADYFOR株式会社 仙塲 大也（ミノ駆動）
View Slide
アジェンダ● 自己紹介● 持続的成長とソフトウェア品質特性● ビジネス理解の重要性に気付いた開発経験● 持続的成長の減衰とビジネス目的減衰● 目的駆動名前設計● 目的ベースのモデリング● 機能性のイノベーション● イノベーションを目指す組織のあり方● まとめ● おまけ
自己紹介ミノ駆動@MinoDriven仙塲 大也電子機器メーカーや大手精密機器メーカー、そしてクラウドワークスを経て、2021年4月にREADYFORにジョイン。リファクタリングやドメインモデリングを主軸に、システム設計に従事。悪しき構造が招く凄惨な結末を風刺した「クソコード動画」シリーズの作者。Twitterに不定期で投稿しています。
ビジネス考えてますか？事業を考えてエンジニアリングしてますか？
「技術には興味があって楽しいよ。会社の事業の細かいことは良くわからないけど、仕様書さえあれば、その通りに実装してみせますよ」…このような考えだと、システムの活力が減衰し、事業継続が困難な状況に陥るかも知れません。
本セッションで解説すること● ITサービスを用いた事業を持続的に成長させていく上で、ソフトウェア品質が大きく影響する。● ソフトウェア品質向上には、ビジネスを理解した設計が必要。
ITサービス事業の持続的成長とはサービスが利益を生み出し続けること、かつ利益拡大を継続していくこと。身も蓋もなく言うとお金の話です。これは、短期的な話ではありません。長期的に成長を継続できるかどうかがです。
長期的にです（大事なので繰り返しました）
ITサービスの持続的成長にはソフトウェア品質特性が関係します
ソフトウェア品質特性(JIS X 25010:2013)品質特性 品質副特性機能適合性 機能完全性、機能正確性、機能適切性性能効率性 時間効率性、資源効率性、容量満足性互換性 共存性、相互運用性使用性 適切度認識性、習得性、運用操作性、ユーザーエラー防止性、ユーザーインターフェース快美性、アクセシビリティ信頼性 成熟性、可用性、障害許容性、回復性セキュリティ 機密性、インテグリティ、否認防止性、責任追跡性、真正性保守性 モジュール性、再利用性、解析性、修正性、試験性移植性 適応性、設置性、置換性
ソフトウェア品質特性(JIS X 25010:2013)品質特性 品質副特性機能適合性 機能完全性、機能正確性、機能適切性性能効率性 時間効率性、資源効率性、容量満足性互換性 共存性、相互運用性使用性 適切度認識性、習得性、運用操作性、ユーザーエラー防止性、ユーザーインターフェース快美性、アクセシビリティ信頼性 成熟性、可用性、障害許容性、回復性セキュリティ 機密性、インテグリティ、否認防止性、責任追跡性、真正性保守性 モジュール性、再利用性、解析性、 修正性、試験性移植性 適応性、設置性、置換性機能適合性（機能性）、修正性（変更容易性）が本セッションに関係します。
機能性と変更容易性品質特性 説明機能適合性（以後「機能性」と呼びます）機能がニーズを満たす度合い。修正性（以後「変更容易性」と呼びます）既存品質を低下させずに、有効的、効率的にシステムを修正可能な度合い。
損益の観点から見ると品質特性 損益への影響機能性 利益の増加に貢献。プラス要素の強化。変更容易性 開発コストの低減に貢献。マイナス要素の低減。
アーキテクチャとは特定のソフトウェア品質特性の促進を目的とした、システムの論理的構造。促進の意味するところ：放っておいても促され、影響を与え続けていくこと。たとえば交通の便が良いと街が発展したり、水はけが悪いと作物の育ちが悪くなるなど。
アーキテクチャ設計にビジネス知識が大きく貢献します
なぜ「ビジネス知識が大事」に行き着いたのか私の開発経験と直面してきた課題の振り返りをまじえて説明します
変更容易性、機能性の順で説明します
変更容易性
変更容易性とは開発コストの継続的な低減に貢献する品質特性。この品質をおろそかにすると、コード理解困難、エンバグ頻発。変更の時間的コストやエンジニアの精神エネルギーコストが著しく増大。バケツの底に穴が空いた状態に。サービスがせっかく利益を生んでも、かさんだ開発コストのために利益が薄くなる。下手すると赤字化。サービスの維持はなんとかできても新機能の実装が困難に。事業の持続的成長が果たせなくなります。
ビジネス知識の重要性に気付くより前私が設計の門を叩いたエピソード
レガシーコードとの遭遇
レガシーコードによる疲弊あるシステム開発において、レガシーコード（保守や変更が困難な、変更容易性の低いコード）に苦しめられたことがありました。何か変更するとすぐバグ化。そして長時間労働の慢性化。「なぜこれほどバグが頻発するのだろう」「何が原因なのだろうか」当時は何がマズいのか分からず、悩む日々が続きました。ところがある日、転機が訪れます。
書籍「リファクタリング」との出会い
運命の書籍「リファクタリング」私が設計の道を志すキッカケになった、私の運命を変えた本。職場の本棚を漁っていたとき、偶然手にしました。「コードが理解しやすくなる」「バグが少なくなる」の記述を目にしたとき、「これだ！」と衝撃をおぼえました。
リファクタリングの練習と設計スキル向上プロダクションコードを使ってリファクタリング。練習用のブランチを切って、裏でコソコソひたすらリファクタリングの練習を積み重ねました。プロダクションコードは複雑怪奇。実践レベルの設計スキルを磨くのにうってつけ。コードが整理されていく有様があまりに面白くて、レガシーコード改善ガイドやドメイン駆動設計など設計技術書を買い漁っては実験する日々。このとき最も設計スキルが伸びました。
ビジネス知識の重要性に気付いたエピソード その１あるべき設計構造
リファクタリングの限界リファクタリングは途中まで順調で、コードはまあまあ整理されました。しかし整理したクラスには、依然として意味のよく分からないロジックが混在しているものがありました。「特殊計算クラス…？仕様書に特殊計算なんてないぞ？お前は一体何をするクラスなんだ？お前の正体は一体なんなんだ…？」WorkflowManager特殊計算クラスPersonInfo
ロジックの背景にあるビジネス知識を調査特殊計算クラスに関係のあるロジックや仕様、ビジネス要件を調査。以下の計算ロジックが含まれていることが分かりました。・商品の割引計算・商品の梱包サイズの計算特殊計算クラス商品の割引計算商品の梱包サイズ計算
あるべき設計構造「割引金額」クラス、「梱包サイズ」クラスに分解。分かりやすくなった上に、イビツさが解消されました。割引金額に依存していた他のクラスから、割引率を抽出することもできました。ビジネス背景の分析により、あるべき構造を設計できました。WorkflowManager特殊計算クラス 割引率割引金額梱包サイズ割引率
ビジネス知識の重要性に気付いたエピソード その２リファクタリングの費用対効果
リファクタリング推進時のコスト説明リファクタリングを推進したとき、コストの説明を追求されたことがありました。「コスト面でどんなメリットがあるのか」「投資に値するものなのか」「リファクタリングの箇所は妥当なのか」「もっと費用対効果が高い箇所はないのか」 etc…はじめ、上手く説明できませんでした。何のためにリファクタリングするのか整理することにしました。
リファクタリングは変更容易性を向上させる。変更容易性が向上すると将来の変更コストが低減する。将来あまり変更されない箇所をリファクタリングしても効果は薄い。将来頻繁に変更され続ける箇所ほど変更コスト低減効果が高い。
開発リソースは有限。無限にリファクタリングはできない。将来頻繁に変更されそうな箇所を狙ってリファクタリングする必要がある。頻繁に変更されそうな箇所はどこか？システムの主力となる部分ビジネス的な価値が高く競争優位性のある箇所
コアドメイン 利益の中心的源泉となるシステム化対象領域ドメイン コアドメインシステム開発対象のビジネス領域ドメインの中で最も価値があり、利益の源泉で、競争優位性のある領域ドメイン駆動設計(DDD)ではビジネスの最重要領域をコアドメインと位置づけ、アドメインの価値が最大化するよう重点的に設計することを説いています。コスト戦略の整理を経て、コアドメインの概念を知るキッカケになりました。分かりやすく言うとサービスの一番のウリの部分
ビジネス知識の重要性に気付いたエピソード その３機能性の損失
機能性
機能性とは機能がニーズに適合している度合いを示す品質特性。機能性が高いほど顧客ニーズを満足するものになり、顧客が対価を支払い、利益が向上します。ニーズの方向性とズレていたり、機能に不備があるものは機能性が低い。機能性の損失は顧客離れを引き起こし、利益が低下してしまいます。
特定状況で想定通りの動きにならないメカ制御停止中 動作準備 動作中 停止準備 停止中特定状況では想定の動きにならないあるメカ制御アプリの開発エピソードです。メカの状態をステートマシンとして設計。Stateパターンを用いて、各Stateクラスに状態ごとに対応するロジックをカプセル化しました。しかし、ある特定状況で上手く動作しないことがありました。
特定状況で想定通りの動きにならないメカ制御停止中 動作準備 動作中 停止準備 停止中しかし微妙にぎこちなさが残存なんとか仕様通りに動くよう無理矢理で不自然なロジックを実装なんとか仕様通りの動作になるよう、調整用の固定値を挿入したり、特殊なロジックを追加したり、だましだまし動かすようなことをしていました。しかしやはりどうしてもイビツさが解消できないケースが残存していました。
外部仕様には現れない、メカの内部挙動停止中 動作準備 動作中 停止準備 停止中あるビジネスニーズを満足するために一部特殊な動作をしているメカ部門に問い合わせたところ、外部仕様には現れない内部の特殊挙動がありました。その特殊挙動は、あるビジネスニーズに対応するものでした。
状態クラスの設計改善により機能性を満足停止中 動作準備 動作中停止準備α停止中ビジネスニーズと内部挙動を考慮した状態クラスを再設計したところ、今度こそ仕様通りに動作するようになりました。なんとかだましだまし動かすためのいびつで不自然なロジックは不要になりました。停止準備βビジネスニーズと内部挙動を考慮した状態クラスを再設計不自然なロジックが不要になった
モデリングと機能性ビジネス理解が不十分だと、モデル設計に不備が生じ、機能性を発揮できなくなることを学びました。天動説では天体の挙動を上手く説明できません。地球平面説では遠くのものが沈んで見えるなどの事象を上手く説明できません。同様に、ビジネス理解が未熟な状態で考え出されたモデルは、課題を上手く解決できず、機能性に不備が生じます。機能性の不備をなんとか解消しようとすると、なぜそうなるのか説明のつかない意味不明なロジックを実装しかねないことを学びました。
私の開発経験と学び まとめエピソード 品質特性 学びあるべき設計構造 変更容易性 ビジネス知識のおかげであるべき構造を設計できた。リファクタリングの費用対効果変更容易性 対象ビジネスの中心的価値の模索が、費用対効果の高いリファクタリングスコープの策定に役立った。機能性の損失 機能性 背景のビジネスニーズを知ることで正しい状態モデルを設計でき、機能性の満足に貢献した。
経験と学びから得たこと本セッションで最も伝えたいこと
事業の持続的成長の減衰はすなわちビジネス目的の減衰
私の開発経験と学び 振り返りエピソード 品質特性 学びあるべき設計構造 変更容易性 ビジネス知識のおかげであるべき構造を設計できた。リファクタリングの費用対効果変更容易性 対象ビジネスの中心的価値の模索が、費用対効果の高いリファクタリングスコープの策定に役立った。機能性の損失 機能性 背景のビジネスニーズを知ることで正しい状態モデルを設計でき、機能性の満足に貢献した。ビジネス目的（なぜ目的なのかは後述）を喪失していたら、これらの課題を解決できず、持続的成長性に禍根を残す結果になっていたかもしれません。
ビジネス目的は様々な要因で減衰する
ビジネス目的は様々な要因で減衰するビジネス要求ビジネス要件仕様設計実装特にスタートアップ時は市場動向や要求が不鮮明、目的の解像度が悪い要件に落とし込んだ段階で目的が減衰する場合あり仕様は目的達成の手段に過ぎないので、目的を喪失しやすい仕様を満たすためだけの、機械仕掛けなロジックが書かれる
システムからのビジネス目的の減衰をいかに抑止し続けるかフレッシュなビジネス目的をシステムにいかに適用し続けるか事業の持続的成長において重要です
ビジネス目的の減衰を防ぎビジネス目的を推進するテクニック
認知の歪み
私たちはシステム化対象のビジネス概念を正確に認知できていないことがままあります
認知の歪みと意味不明なロジックレガシーコードが書かれてしまう開発では、目的の減衰が起こりやすくなっています。ビジネス目的がろくに伝わらず、単に仕様書だけが渡され、仕様を満たすように実装するだけになりがちです。すると、私が経験してきたように、ビジネス目的を喪失した、技術駆動なクラス名や意味不明なロジックになります。変更容易性が低下します。WorkflowManager特殊計算クラス PersonInfo
裏に複数の概念が隠れていた事例商品取引履歴注文おすすめ商品予約巨大でイビツな商品クラスがありました。何に使われているのか目的を探り、正体を暴き出したら、実は4つの概念がキメラになったクラスでした。「おすすめ商品」が概念としてカスッているだけで、全く「商品」にそぐわない概念が他に隠れていたのです。
悪魔は正体を隠しているはるか昔、人々は疫病の原因を悪魔のシワザと考えていました。悪魔と呼称して、当時効果的に対処できていたでしょうか…？？のちに、細菌の発見により対処方法が劇的に革新されました。変更容易性や機能性を貶めるロジックは、悪魔のようなものです。私が設計やリファクタリングするとき、ソースコードに常にこう問いかけています。
お前の正体はなんだ？
アンカリング効果に振り回されずに正体を見破るアンカリング効果：最初に提示された情報が基準となってしまい、その後の判断を歪めてしまう認知バイアス。システム開発では、既存のクラス名やメソッド名が基準となってしまって、判断を歪めている事象となって現れています。レガシーコードが書かれてしまう現場では本当に多くて、ほとんど誰もがアンカリング効果から逃れられない状態に陥っています。病原菌が原因なのに、「悪魔が…」「いや、ですから悪魔クラスが…」「ビョウゲンキンってなんだか分かんないけど、とにかく悪魔クラスがですね(怒)」こういうコミュニケーションがシステム開発では本当に多いです。
アンカリング効果に振り回されずに正体を見破る一見妥当そうに見えるクラス名やメソッド名、ロジックであっても、一切信用しないようにしています。また、自分の認知が歪んでいる可能性もあるので、自分が書いたコードに対しても「お前の正体はなんだ？」と問いかけるようにしています。既存の構造や名前を完全に頭から消し飛ばして、ゼロベースで「あるべき」を追求することで、より精度の高い設計やリファクタリングを実施できます。そして正体を暴くにあたって、さらに有用な考え方があります。それが…
目的駆動名前設計(Purpose Driven Name Design)
目的駆動名前設計とは私が勝手に提唱した名前の設計方法です。（DDDの設計思想由来の名前設計）（そもそもオブジェクト指向のObjectが「目的」を意味し、「目的指向」なのではという説もあり）プログラミングでは「良い名付けをしよう」とよく言われてはいます。しかし可読性だけで話が止まっていたり、良い名前を付けたと思っても、名前が仇になってクラス構造がイビツになることに疑問を覚え、発案しました。システム上のビジネス目的の減衰防止、さらには目的促進を目指した名前設計の考え方です。
目的駆動名前設計とは● 設計要件○ ビジネス目的を表現した名前であること。○ 目的特化の名前であること。○ 可能な限り意味範囲が狭く、ザルで曖昧な解釈を許容しない具体的な名前であること。● メリット○ ビジネス目的の減衰防止○ 変更容易性向上○ 機能性向上○ 機能の発展性（イノベーション）への寄与
「商品」は「売る目的」を表現していそうですが、特化してはいません。意味範囲が広くて曖昧です。「在庫品」「注文品」「発送品」など、より目的特化な名前を設計します。
存在ベース、物ベースの命名やモデリングは上手く働かないユーザー、金額、住所など、単に存在しているだけの、物をベースとした命名やモデリングは、どういった用途に対応するものなのか目的を喪失しやすい。多くの場合は多目的に使われて混乱したり、用途不明で混乱したり、ときには巨大クラス化します。物ベースで目的不明なクラスを何と呼ぶかというと…存在、物ベース 目的ベースユーザー アカウント、プロフィール、職務経歴名前 アカウント名、表示名、本名金額 請求金額、原価、延滞料金、配送補償金額住所 配送元、配送先、勤務先、本籍地
目的不明オブジェクト(Unknown Purpose Object)
目的不明オブジェクト（UPO）とは私が勝手に提唱した概念です。その名の通り目的のよくわからない、または多目的で使われているクラスをUPOと呼ぶことにします。UPOに遭遇すると誘拐されて怪しい金属片を体内に埋め込まれたり記憶を消されたりはしませんが、混乱することには違いありません。ただちに目的を分析し、目的ごとのクラスにリファクタリングすることをオススメします。
目的達成手段としてのモデル
物としてモデリングすると低凝集に陥りがち現実世界のモノを単にモデル化すると、モノの属性、つまりデータを格納するだけのモデルやクラスとして設計されがちです。ロジックを持たずデータ保持だけするクラスをデータクラスと呼びます。データクラスがあると、データを操作するロジックは別のクラスに実装され低凝集構造になります。低凝集は変更容易性低下を招きます。
モデルは物ではなく、目的達成の手段モデルは、ひとつひとつが課題解決の仕組みを持った、ミクロなコンピュータです。それが集まってシステムになります。判断し、情報加工する手段をモデルは備えます。モデルを「特定目的達成の手段」と解釈すれば、データとデータを操作するロジックが凝集し、変更容易性は向上します。システムモデル(手段)モデル(手段)モデル(手段)
目的駆動名前設計の練習
「商品購入」これの正体、真の姿ってわかります？
売買契約の締結
多くのECサイトやフリマサービスの利用規約では、商品購入操作を売買契約の締結と定義付けています。法的な意味を持つようになり、重みが全く違ってきますね。「購入」モデルではなく、「売買契約」モデルとなると、支払条件など契約上の属性が必要になります。もし、こうした法的な側面がシステム化されていないとどうなるでしょう？売り手と買い手になんらかのトラブルが発生した際、法的な有効性を発揮できず、トラブルを上手く解決できないシステムになってしまう可能性があります。機能性が損失してしまいます。機能性を上手く発揮するには、ビジネス概念の正体や、裏に隠れた重大な目的を見破る必要があります。
機能性のイノベーション
機能性0ここまでの解説は、機能性の低減をいかに防ぐか、という内容でした。
機能性0ここからは、機能性をさらに高めてイノベーションへ向かわせるお話をします。
目的ベースのモデリングと発展性
物ベースモデリングと抽象化サバ サンマどう抽象化しますか？
物ベースモデリングと抽象化サバ サンマ魚類
物ベースモデリングと抽象化サバ サンマ 豚魚類じゃあ豚が追加されたら？
物ベースモデリングと抽象化サバ サンマ 豚魚類動物哺乳類物ベースだと、抽象化ではなく単なる分類になりがち
モデルは「目的達成の手段」だと述べました「目的達成の手段」の観点で見ると今までにない発展性が生まれます
目的達成手段としてのモデルと抽象化サバ サンマ 豚栄養摂取手段栄養摂取手段の目的を据えて抽象化すると、他の手段も考えられる
目的達成手段としてのモデルと抽象化サバ サンマ 豚栄養摂取手段「食べる」以外の手段も考えられる。目的達成手段としてモデリング、そして抽象化すると、手段に発展性が生まれる加工食品 点滴 胃ろう
目的達成手段のイノベーション史：移動手段二足歩行 馬車 鉄道移動手段自動車 飛行機 ？？？次はどうイノベートされるのだろう？？
目的達成手段のイノベーション史：運搬手段手 手押し車 鉄道運搬手段トラック ドローン ？？？次はどうイノベートされるのだろう？？
ソフトウェアイノベーションの例BBS メール ブログ情報拡散手段SNSTwitterのリツイート？？？リツイートは、良くも悪くも話題性のあるツイートを爆発的に拡散する仕組み。こうした本質を解決するモデルを、ドメイン駆動設計では深いモデルと呼びます。深いモデルは機能性の革新に大きく貢献します。私は深いモデルを発明、発見してイノベーションに貢献したいです。
目的推進しイノベーションを目指す組織のあり方
真のビジネス目的を探し当てるのは至難の業ビジネス理解市場反応顧客の声仕様変更 リリースフィードバック「顧客は自分がほしいものを知らない」と言われるように、真のビジネス目的を探し当てるのは至難の業です。このフィードバックサイクルを回して少しずつビジネス理解の解像度が向上し、その先にやっと見えてくるものです。
ビジネス部門とエンジニアリング部門の分断分断ビジネス部門とエンジニアリング部門がキッチリ分かれていると、ビジネス目的がエンジニアリング部門に伝達しにくくなり、目的減衰が発生します。事業の持続的成長を果たしていく上で課題となります。そこで…
乳化
READYFORのチームビジョン「乳化」組織の中にエンジニアリングが自然に溶け込んでいる状態、エンジニアリングとビジネスの近接を実現するコンセプトが「乳化」。フレッシュなビジネス知識を常にエンジニアリングへフィードバックし続けています。ビジネス目的と一貫性のある設計を策定し、事業の持続的成長へつなげることを目指しています。
皆さんはこれからどう取り組みますか？
考えてみようシステム開発する上で、目的減衰を防ぎ、目的推進する方法は他にないでしょうか？本セッションで紹介した手法は、あくまで手段の一部に過ぎません。皆さんもいろいろ考えてみましょう。事業の持続的成長の鍵が見つかるかも知れません。
まとめ
まとめ● ITサービスの持続的成長にはソフトウェア品質特性（変更容易性、機能性）が関係する● 品質特性を促進するアーキテクチャ設計には、ビジネス知識が大きく貢献する● 事業の持続的成長の減衰とは、すなわちビジネス目的の減衰● 目的減衰防止と目的推進には様々な方法が考えられる○ 目的駆動名前設計と目的ベースのモデリングは、変更容易性と機能性向上に貢献する○ 目的ベースのモデリングはイノベーションの可能性を秘めている○ READYFORでは「乳化」によりビジネスとエンジニアリングの近接を図っている
おまけ
本を出版することになりました
アンチパターン駆動の設計技術書を出版します悪しきコード、悪しき構造がどんな弊害をもたらすのか、そして解決にはどんな設計構造に落とし込めば良いのかについて書いた本です。サンプルコードを大量に用意しています。理論だけに終わらず、具体的なコードとしてどうなれば良いのかを分かりやすく網羅している構成です。本セッションで取り上げたビジネス目的周りについても、さらに詳細に解説しています。技術評論社様より、年末年始ごろ全国出版予定です。
私もはじめはレガシーコードを書いていました。でも何年もかけて設計を学び、咀嚼し、仕事に活かしてここまで来ました。この本には、私のこれまでの学び、皆さんに活かしてほしい知見が詰まっています。是非お手に取っていただけると嬉しいです。
私たちはやれる、必ずやれるみんなで事業を成長させていきましょう
ご清聴ありがとうございました
minodriven
danilop
akitotsukahara
little_rubyist
jmatsu
utgwkk
ymotongpoo
shinmiy
koic
beberlei
ffjlabo
headius
takesinoda
chrislema
hannesfritz
sferik
paigeccino
jonyablonski
deanohume
morganepeng
carmenintech
stephaniewalter
bkeepers
jasonvnalue
zenorocha