第3回 ソフトウェア設計における思考と学び方を考える 「増田さんとビジネスの重力を見極める型を作る」
増田さんが重視すること
ソフトウェアエンジニアとして、事業課題や事業方針を理解することは非常に重要
ソフトウェアを開発・運用することは事業活動の一部
費用対効果を求められる
つまり、開発・運用することの効果を明示しなければならない
ソフトウェア（システム）と事業の関係が急速に変わってきている
DX、デジタル化、、
事業提供側は、顧客のニーズにリアルタイムに反応し、サービス提供・決済まで行うことが望ましい
前世紀では、事業の一部をシステムが担うことが一般的だったが、今や事業の全般をシステム化する必要がある
言い換えると、ソフトウェアエンジニアは事業活動の統治者としてソフトウェアを設計・開発しなければならない
ソフトウェアの出来は収益に直結する＝ソフトウェアエンジニアとして良い仕事ができない
前世紀では、データ収集・レポート・人間が判断。だった。
基幹システムは収集→Excelがレポート→人間が判断
人間が判断するためにデータ収集し、レポーティングする
基幹システムは入出力を定義して、データモデリングできれば仕事になっていた？
今や、要求をデジタルに収集・判断し、自動的に判断しなければ顧客は満足できない？
たとえ物流が伴う物理的な業界であっても、自動化は必要。競争力の源泉になるはず
「自動化」には熟練の業務経験や知識が必要→ドメインエキスパート
エンジニアはドメインエキスパートの思いを汲み取らねばならない
増田さんが↑の考えに至る過程
印象的な2つの案件
DNAの創業期．ビッダーズというオークションサイト（あったあった
ヤフオクはアレだったところ、ビッダーズを「安心して利用できるECがあれば」と企画した
不都合がありリリースできない状況に、増田さんが火消し？で入った
商業的な意図よりも、株主マターで「どうにかするしかない」状況だった
「今年中にサービスインしないと明日はない」という状況
タコ部屋で突貫
「最低限やらねばならないことはなにか？＠事業として経営として」が非常に重要
南場さんは主張はするが、状況に応じた判断
何とかリリースしたが上手くいかなかった
各ポータルサイトに、オークション機能としてOEMすることにした
ヘッドレスオークション
またしても「やらねば明日はない」
品質保証や保守うんぬんではなく、期日までにやらねばならない
SBの孫さん＞1990年代は「インターネットでなければビジネスでない」だった（いまはAIで同じこと言ってる
AmazonみたいなECサイトを半年で立ち上げろ←ｗｗｗ
孫さん周りは、できるできない｜いつならできる、という思考はない
どうやってやるか？しかない
増田さんがDB周りの責任者として入場
孫さんのBPはセブンイレブン。2社間で「今年中にAmazon的ECを立ち上げる」という事業計画
テレビCMを始めるなど、Xデーに向けたピボタルイベントが山積みになる
が、期日までにバックエンドは6割ほどしか完成しなかった
初月は手作業
翌月はスクリプト
UI付きシステムができたのはさらにその後
JGEEM.icon VPPの実証が思い出されるな
技術的にヤバいところは早期につぶし、なんとかなる（手で回る？）ところは後回し、やらなくていいことはやらないなどなど事業としての判断する機会を得られた
大きな泥団子
知人（SBグループ）から大みそかに呼び出される
採用管理のSaasを作った。契約も取れてサービス提供している。。が、バグだらけでマジ動かん
PdM兼テックリードが心身ともに限界でリタイア
JGEEM.icon その状況に知人を呼ぶってすげえなｗ
知人は飲食店対応した時の関係者
ソフトウェアとしてはあり得ない設計（設計というべき構造がない）
つぎはぎでここまでデカい泥団子が作れるのかと
致命的なバグ（情報統制できない）が散見
だが、ある機能は顧客から好評。バグは直してもらうとして続けて使いたいと
エンジニアとしてはかなりショック
バグは極力少なくすべきでは？
設計もない、業務知識もない、という状況からのリファクタリング
画面のパラメータが永続化層まで依存関係を持つ、あるいは永続化層の都合が画面の制約になっている
関心の分離とは、、
使えない機能が画面に表れているなど、商用では考えられない状況
リファクタリング＆リファクタリング
2回／日リリース
SaaSなのに、昼と18:00過ぎにサービス停止時間を設けてリリースしていた
リファクタリングやり放題？
「とにかくメスを入れるしかない」が許された
事故りもするが、元がひどいので致命的な状況にはならない
リファクタリングを重ねることにより「関心を分離することの効果」を体感できる
ソフトウェアとして対応するよりもDBをきれいにしてSQLを頑張ったほうが楽
と思いきや
DBが業務知識を反映しておらず、まったく使えない
「人材採用」という事業にはどういうイベントがあるのか？など、まったく理解されていないテーブル設計
業務知識を学びながら、ソフトウェアとして頑張った（ドメインモデリングだな）
レポート出力に5分もかかったが褒められた（神様扱いされた）とかｗ
蓋を開けてみれば、業務知識に関連しないロジックはごく単純なシステムだった
業務知識に関連するクラス設計さえきれいにすれば、全体がすっきりする
結果的には転売に次ぐ転売を経て（事業譲渡を受けて使い続けたいとか）もなかなか生き残った
からの、写真館
スタッフアロケーションシステム？
これまでの経験から、業務知識にまつわるところ（複雑になりそうなところ）を始めに整理してから周辺部分（アダプター）に進めた
期間的にも無理難題感はあったが（いろいろあったが）問題なくサービスイン
費用対効果としても初年度で+3000万円出た
「複雑になりそうなところをきれいにする→あとから必要なアダプターをくっつける」という設計パターン
そこからさらに、業務知識の拡張要求があっても短期間で追随することができた
業務知識をきちんと理解することでシステム開発に絶大な効果が期待できる
やはり事業活動の統治者としてソフトウェアに向き合い、
業務知識が複雑なところに最大限注力することで、だいたいのことには対処できる
事業活動 命、業務知識 命、ドメイン知識 命
内製とPKG/SaaSの使い分け←競争優位性の観点で判断
エンジニアが「この感覚（事業活動の統治者として）」で判断できるか
-- 後半戦 --
事業方針が、業務ルールとして、事業活動をどう刺激・制約するか
「事業課題→事業方針→業務ルール」という構造
事業方針を業務活動に徹底するための「業務ルール」
業務ルールは「刺激」と「制約」
業務ルールの意図は
利益を増やすため
売上を増やす
経営資源の有効活用（たんに効率化やコストダウンでない）
適正価格で売りたいが、価格競争になる
価格競争を避けるために、異なる手段を用いる
経営資源の有効活用？
オーバーブッキングルール
キャンセルを見越した過剰受付
リソースの稼働率
システムを開発するにあたって、事業構造・利益構造・コスト構造を理解すれば、業務ルールはある程度見えてくる
逆に、業務知識（why）を知らなければ業務ルールの誤りに気付けない
whyが分かると、エッジケースが並んでいるかのような業務ルールに構造が透けて見えてくる
つまり、網羅的なテストをせずとも構造に沿ってテストすれば品質は保てる
コードに書くべきはエッジケースではなく、業務ルール
複雑で高品質なソフトウェアを開発できるようになる
トップダウンで業務理解を進めても、業務ルールにはたどり着かない？
ボトムアップで理解を進めれば業務ルールが見つかるが、スコープがどこまで広がっているか分からない。事業課題も見えない
両方から（往復しながら）アプローチしなければ、業務課題→事業方針→業務ルールを解き明かせない
いい感じで知識が付いてくると、トップ→←ボトムのアプローチがつながる
おかしなところにも気付く
JJUGcccの春？版で分析パターン10選として挙げた
いかにトップダウンで課題を洗い出すか
事業活動は互恵（サービス提供→←対価支払）
事業の互恵関係を知る
事業活動は契約
価値の即時交換ではなく、まず提供。後に支払。不履行のペナルティ。
商取引。契約を履行することが事業活動
事業は互恵関係のネットワーク
原料を調達、加工して商品を成し、商品を販売する
ビジネスモデル（ビジネスフロー）を図示してみる
JGEEM.icon そいえば前職では結構書いてたな
直接契約ではないかも
広告モデル、サブスクモデル
このモデルが事業の重力
これを理解しないと業務の流れもつかめない
そこには競合も存在する
重力ではなく圧力
経営資源を有効活用するために事業活動を分解する
直接的には出てこない
役割、部門、人、業務内容、、などなど
分解していかねばルールは見えてこない
マイケルポーター「バリューチェーン」「サービスブループリント」
事業の基本課題に、どういうルールで取り組むことで収益を産むか
whyが見えてくるのでは？
ルールやフローの羅列では見えない「軸」が見えてくる
変えようのないルール
変化が多いところ
どれが中心？どれが付属？の判断はもはや「感覚」←ビジネス感覚か
これを理解できないと、ビジネス要求があるたびに苦しむことになる
公開情報からアプローチする
事業内容、組織図、財務状況、
参考にすべき事業モデルを展開している他社
最初は深堀しない。俯瞰してインデックスする
ただ、一朝一夕には情報を取得する勘所は身につかないかも
設計情報とか
前提知識（管理会計とか簿記とか）
初伝、中伝、奧伝
初伝
費用対効果の高い学び方≒初伝の型？
財務諸表とは何で、どう読むか？、何を得られるか？など
ガイドとツアー
中伝
前提知識はあるが、どうやって設計に結びつけるか
「結びつける方法を見つける」方法
課題感はあるが解決策に結びつかない
ハンズオン的なワーク
奧伝
オーラを見せてみろ（ｗ
自らの課題と考え方を披露して、奧伝者同士での講評
型を繰り返すことで内面化する（JGEEM.icon seciモデル的だな）
繰り返す→手を動かす
単純作業ではなく、思考する
まずは資料を読んでまとめる
アウトプットする
財務諸表から特徴、気付きを書き留める
そこから事業上の変化や外部環境の変化に紐づけて整理してみる
JGEEM.icon 4C？だっけ？
展開している販促などの施策を挙げて、それぞれの狙いを書き留める
発表しよう・誰かにFBをもらおう
共創しよう
自身が保有している知的財産をどう活用するか
そもそもどんなリソースを保有しているか
公開情報から事業活動の把握
現実に見える事象からその活動の背景を類推
集める→整理する→一般化する（非 抽象化）
一般化：普遍的な法則や概念を引き出すこと（概念化か？）
事業理解・業務知識・設計の相互作用
DDDを始めようでは、明確に「中核・補完・一般」と分けてアーキテクチャを変えよと述べていた
お気に入りのアーキテクチャ本について「いかにして事業課題と業務知識の反映するか」が書かれているか
現場でやるなら、コンテキストマップを書く／This is 泥団子のようなリファクタリングに手を出す
リファクタリングも、事業観点・業務知識を軸にして取り組む
学び方の型／新しいことに取り組むときの型
メタっぽい
自分のやり方を見つけられると良い
自走できる
JGEEM.icon どうやってる？