ソフトウェア設計における思考と学び方を考える 〜増田さんの思考を構造的に見える化してみる〜

Leviiやべえな ← モデリング特化じゃないか

当日のホワイトボード（Balse）

結論的なフレーム

https://scrapbox.io/files/66d41af4d09c27001cd5d8b5.png

まずアクターを見極める

コンテキスト大事

昔から全体像を把握する営みはあったが、アクターを特定するのはオブジェクト指向で出てきた

アクターとは組織構造でもある

組織構造をホワイトボードに列挙していく（モデリングしていく）

それから機能を見極める

重要な業務を見極めたい

大前提として「ビジネスの重力」がある

重力とは金を稼ぎたい。売上を上げたい。リソースを有効活用したい

システムを改善したいということは、それらがうまくワークしていないということ

画面の仕様を聞きながら、君ら何してるの？何に使うの？という一般的なヒアリングをしているが、

気にしているのは、どの重力に引かれているのか？という観点

では、重要な業務とは？

言い換えると「面倒くさいところ」「明確な答えが出てこないところ」「言語化しにくい仕様」「ごちゃごちゃするところ」

なのでヒアリングの相手が重要（エース級の社員、主導的な幹部、次期役員候補など）

システムの目的と事業が紐づく

（どうすると最適化できると「思っている」か、どうするともっと儲かると「思っている」か）

（そうでない相手からのヒアリングは適当に見切りをつける。費用対効果が悪い）

（自分自身のビジネス＝部門ミッション？とのマッチングも重要）

つまるところ「ビジネス」をどれだけ理解できるか

システム化する前はどうしてたの？

最初に作るべきは

判断に必要な材料をオブジェクト化（エンティティかな？）

日付や区分などを値オブジェクトk

（必要な機能に絞って。MVPか？）

手運用でどうにかなるなら重要な機能ではない？

重要なアクターの最大の関心ごとは何か？にフォーカスする

あとは技術的な不確実性があるところ、代替案のないところは早めに潰す

（この辺はリスク探索して炙り出すのかな）

--