Thought

はじめに 発生した課題・問い なぜモデルを分けるべきなのか？（2つの理由） 1. 「最新状態（ステート）」と「過去の出来事（ログ）」はライフサイクルが違う 2. 不要なプロパティの持ち回りを防ぎ、責務を分離する 単一責任の原則に立ち返る 「変更理由が複数ある＝責任が混在しているサイン」 1箇所でモデルを変換すれば、影響範囲は閉じられる おわりに はじめに Androidアプリ（Kotlin + Jetpack DataStore）で見守りチェック機能を実装していた際、バックグラウンドでの判定用データと、画面に表示する「チェック履歴」の持ち方について設計を見直す機会がありました。 最初は「既存の判定用モデルをそのままリスト化して履歴として保存すればいいのでは？」と考えていたのですが、モデルを分離（SafetyData と MonitoringHistoryLog）する設計を検討・議論する中で、「単一責任の原則」をどう実務に活かすかについての腹落ちが得られたのでブログにまとめます。 発生した課題・問い 見守りアプリにおいて、以下の2つのデータを管理する必要がありました。 システムの最新ステート：前回のバッテリー残量、前回のチェック時刻、現在機能が有効かどうか等（次回チェック時の差分判定に使用） 時系列の履歴ログ：いつチェックが走り、活動が検知されたか（履歴画面でタイムライン表示に使用） 当初は、1の最新ステートを表す SafetyData をそのまま List<SafetyData> としてDataStoreに保存すれば、クラスも増えずシンプルで良いのではないかと考えました。 しかし、このアプローチにはいくつかの懸念点がありました。 なぜモデルを分けるべきなのか？（2つの理由） 議論を通じて整理された「モデルを分けるべき理由」は以下の通りです。 1. 「最新状態（ステート）」と「過去の出来事（ログ）」はライフサイクルが違う ステート（SafetyData）: 次回のチェック判定まで保持されればよく、常に新しい値で上書きされるデータ（生存期間：短）。 ログ（MonitoringHistoryLog）: 過去の記録として蓄積され、ユーザーに見せるためのデータ（生存期間：長）。 寿命（ライフサイクル）や保存方式（上書き vs 追記）が異なるデータを1つのモデルに詰め込むと、データの読み書きや更新処理が無駄に複雑化します。 2. 不要なプロパティの持ち回りを防ぎ、責務を分離する SafetyData には isMonitoringEnabled（機能全体のON/OFF設定）などの設定項目も含まれています。これを履歴として毎件保存すると、データサイズが無駄に肥大化するだけでなく、「履歴画面を表示したいだけなのに、無関係な設定データまで持ち回る」 ことになります。 専用の軽量モデル MonitoringHistoryLog を用意することで、データサイズを削減し、履歴画面側が不要なプロパティを気にしなくて済むようになります。 // 1. システム内部の最新判定用モデル（ステート） data class SafetyData( val lastBatteryLevel: Int?, val lastActiveTime: Long?, val isMonitoringEnabled: Boolean, // 履歴ログには不要な設定データも含まれる // ... ) // 2. 履歴画面・記録用の専用モデル（ログ） @Serializable data class MonitoringHistoryLog( val id: String = UUID.randomUUID().toString(), val executedAt: Long, // 実行時刻 val isActivityDetected: Boolean // 活動検知があったか ) 単一責任の原則に立ち返る これまでプログラミングの本などで 「単一責任の原則＝クラスを変更する理由を1つにせよ」 という解説を読んでも、イマイチピンと来ていませんでした。しかし今回の設計を通じて、その捉え方がガラッと変わりました。 ...

設計のフレームワークを作っていたら、モデリングのフレームワークになっていた 要件定義、仕様策定、設計、実装は、すべてモデリングなのではないか モデリングのフレームワーク 実装で迷ったとき、「どこで迷っているのか」が分かるようになった そういえば、要件と仕様の違いをちゃんと理解していなかった 要件は What / Goal、仕様は How 「迷い」を上流へ遡る モデリングのフレームワークを作っていたから見えるようになった 設計のフレームワークを作っていたら、モデリングのフレームワークになっていた 現在、私はソフトウェア開発における「モデリングのフレームワーク」を作っています。 もともとは、より良い設計をするためのフレームワークを作ろうとしていました。 しかし、考えているうちに、あることに気が付きました。 要件定義、仕様策定、設計、そして実装は、それぞれ独立した活動ではなく、前工程で作られたものを、別の形でモデリングし直していく活動なのではないか。 この気付きから、現在は「設計のフレームワーク」ではなく、「モデリングのフレームワーク」として整理し直しています。 要件定義、仕様策定、設計、実装は、すべてモデリングなのではないか ソフトウェア開発では、一般的に、 要件定義 ↓ 仕様策定 ↓ 設計 ↓ 実装 という工程に分けて考えます。 以前の私は、これらをそれぞれ別の作業として捉えていました。 しかし、モデリングという視点から見ると、少し違った見え方をします。 例えば、要件定義では、現実世界の課題や目的を、「システムが何を達成する必要があるのか」という形に変換します。 仕様策定では、その要件を、「システムがどのように振る舞うべきか」という形に変換します。 設計では、その振る舞いを、「ソフトウェアをどのような構造にすれば実現できるか」という形に変換します。 そして実装では、その設計をコードという形に変換します。 つまり、 現実の課題・目的 ↓ 要件として表現 ↓ 仕様として表現 ↓ 設計として表現 ↓ コードとして表現 というように、同じ対象を、工程ごとに異なるモデルとして表現していると考えることができます。 この見方をすると、要件定義、仕様策定、設計、実装の間にあった境界が、少し違って見えてきました。 モデリングのフレームワーク 現在作っているフレームワークは、まだ大枠しか定まっていません。 イメージとしては、クリーンアーキテクチャのような同心円状の構造を考えています。 中心から外側に向かって、上流工程から下流工程へと進んでいきます。 そして、それぞれのレイヤーには、その工程で適切なモデリングを行うための考え方を配置します。 ┌───────────────────┐ │ 実装 │ │ ┌───────────────┐ │ │ │ 設計 │ │ │ │ ┌───────────┐ │ │ │ │ │ 仕様 │ │ │ │ │ │ ┌───────┐ │ │ │ │ │ │ │ 要件 │ │ │ │ │ │ │ └───────┘ │ │ │ │ │ └───────────┘ │ │ │ └───────────────┘ │ └───────────────────┘ まだこの図自体も発展途中です。 ...

はじめに 1. 「裁量がある会社」を探していた 2. さらに抽象化してみた 3. 抽象化には「ちょうどいい地点」がある 4. これはソフトウェア設計にも応用できる 5. 「本質を見抜く」と「抽象化しすぎない」は両立する まとめ はじめに ソフトウェア設計では、「抽象化」が重要だと言われます。 重複した処理を共通化したり、具体的な実装から本質的な概念を取り出したりすることで、変更に強く、再利用しやすい設計を作ることができます。 私自身、これまで設計について学ぶ中で、具体的な事例から共通する本質を見つけ出し、より抽象的な概念として捉えることを意識してきました。 しかし最近、別の重要なことに気づきました。 抽象化は、必ずしも最後まで行えばよいわけではない。 抽象化を進めすぎると、今度は意味が伝わりにくくなることがあります。 今回は、転職活動での企業選びを通して、このことに気づいたので整理してみます。 1. 「裁量がある会社」を探していた これまで私は、転職先を選ぶ際の基準として、 裁量があること をかなり重視していました。 例えば、 設計に関われる 技術選定に関われる 仕様について提案できる スケジュールについて意見を言える といったことです。 しかし、改めて「なぜ裁量が欲しいのか？」を考えてみると、裁量そのものが目的ではないことに気づきました。 例えば、技術的負債によって実装が非常に難しくなっている状況を考えます。 現場のエンジニアが、 「このままでは予定通りに実装するのが難しい」 と判断したとします。 このとき重要なのは、必ずしもそのエンジニア自身が、 「では私の判断でスケジュールを変更します」 と決められることではありません。 むしろ、 「このままでは難しいので、スケジュールを見直したほうがよい」 という現場の判断を、上司やマネージャーが受け止め、必要ならさらに上の意思決定者に伝え、組織として判断できることのほうが重要です。 つまり、私が本当に求めていたのは「裁量」そのものではありませんでした。 現場で行われた合理的な判断が、組織の意思決定に反映されること だったのです。 2. さらに抽象化してみた そこで、もう一段階抽象化してみました。 「現場の判断が尊重される」ということをさらに抽象化すると、 チームとして適切な意思決定が行われていること と言えそうです。 または、 適切な意思決定プロセスがあること とも表現できます。 確かに、これは概念としては間違っていません。 抽象化したことで、より本質的な意味を表しているようにも思えます。 しかし、ここで問題が起きました。 分かりにくいのです。 自分の企業選びの基準として考えてみても、 「チームとして適切な意思決定が行われている会社がいい」 と言われたとき、具体的に何を確認すればいいのかが分かりにくい。 面接官に説明するとしても、 「適切な意思決定プロセスとは何ですか？」 という話になり、かえって説明が必要になります。 一方、すこし具体的にして 「現場の判断が尊重されること」 なら、かなりイメージしやすい。 例えば、 技術的に難しい問題があれば相談できる 無理なスケジュールなら調整を検討してもらえる より良い設計案があれば検討してもらえる 技術的負債の解消が必要なら、リファクタリングの時間を確保してもらえる といった具体例にすぐ落とし込めます。 ...

はじめに 1. 影響範囲が読めないコードの例 2. 仕様とコードの因果関係を分かりやすくする 3. 開発者にとって怖いのは「影響範囲が読めないコード」 4. 良いコードとは「変更の影響範囲が読めるコード」 はじめに 「とりあえず動くものを作る」。 ソフトウェア開発では、どうしてもこの誘惑があります。 目の前に要件があり、それを満たすために必要なAPIを調べ、コードを書き、動作確認をする。テストも通った。これで完成です。 しかし、その実装が半年後、1年後も安全に変更できるとは限りません。 私は最近、ソフトウェア開発において特に避けるべきなのは、単に「バグのあるコード」や「複雑なコード」ではなく、 変更したときの影響範囲が読めないコードを書くこと なのではないか、と考えるようになりました。 そして、そのようなコードが生まれる大きな原因の一つが、 仕様や利用する技術の仕組みを十分に理解しないまま、目の前の要件を満たす実装をしてしまうこと なのではないかと思います。 1. 影響範囲が読めないコードの例 例えば、ECサイトに「購入金額が1万円以上なら送料無料」という仕様があったとします。 目の前の要件を満たすだけなら、注文処理の中に、 if (totalPrice >= 10_000) { shippingFee = 0 } のような処理を追加すれば十分です。 実際に動作しますし、テストも通るでしょう。 ところが、しばらくして仕様が変更され、 「1万円以上でも、一部の商品は送料無料の対象外とする」 となったとします。 すると、先ほど追加した処理を変更する必要があります。 さらにその後、 「会員ランクがゴールド以上なら、5,000円以上で送料無料」 という仕様が追加されたらどうでしょうか。 最初は注文処理の中に直接書いた条件が、次第に複雑になっていきます。 if (totalPrice >= 10_000) { shippingFee = 0 } else if (isGoldMember && totalPrice >= 5_000) { shippingFee = 0 } さらに商品ごとの例外が追加され、キャンペーンが追加され、地域による違いが追加され……。 最初は「数行追加するだけ」だった実装が、いつの間にか、 「送料の仕様を変更したら、どこに影響するのか分からない」 という状態になってしまいます。 ここで重要なのは、最初の実装が間違っていたとは限らないことです。 その時点では、要件を満たしていたかもしれません。 問題なのは、目の前の要件だけを見て実装した結果、後から仕様との関係を追いにくくなってしまったことです。 2. 仕様とコードの因果関係を分かりやすくする では、どうすればこのような状態を防げるのでしょうか。 一つの方法は、 仕様に存在する概念やルールを、コード上でも分かる形にすること だと思います。 先ほどの例なら、「送料」という単純な値を注文処理の中で直接変更するのではなく、 注文 ↓ 送料を計算する ↓ 送料無料条件を判定する ↓ 送料を決定する という仕様上の流れが、コードからも読み取れるようにします。 ...

実装すると違和感が見えてくる 設計にはフィードバックループが通用しない場面もある おわりに 「フィードバックループを速く回すことが重要」という考え方は、アジャイル開発やリーンスタートアップなどで広く知られています。 実際、動くものを早く作り、フィードバックを得ながら改善していくことで、短期間で品質を高められる場面は少なくありません。 最近、この考え方は設計判断にも当てはまるのではないかと考えるようになりました。 実装すると違和感が見えてくる 設計は頭の中だけで考えていても、問題に気付けないことがあります。 しかし、実際に実装してみると、 クラスの責務が曖昧ではないか 命名に違和感はないか 依存関係が複雑になっていないか モデルがドメインを自然に表現できているか といった違和感が見えてきます。 この違和感こそが設計を改善するためのフィードバックです。 つまり、まずは実装してみる、そして、フィードバックを早く得るという考え方は重要だと考えています。 そのため、 仮説 → 実装 → フィードバック → 改善 というサイクルを速く回すことで、設計判断の質も向上すると考えています。 設計にはフィードバックループが通用しない場面もある 一方で、この考え方を設計全体にそのまま適用することはできません。 例えば、ドメインモデリングやシステム全体の概念設計を誤ると、後から修正するために多くのコードを書き直すことになります。 つまり、フィードバックループを速く回すことによるメリットよりも、作り直しのコストが大きくなる場合があります。 そのため、設計では 後から変更しやすい部分は、早く実装してフィードバックを得る 後から変更しにくい部分は、十分に検討してから実装する というように、変更コストを考慮してフィードバックループの回し方を変えることが重要なのだと考えました。 おわりに 私はこれまで、「フィードバックループを速く回すこと」で開発体験を向上させるという話はよく聞いていました。 しかし今回、設計判断においても同じ考え方が有効である一方、設計には変更コストという制約があるため、適用範囲を見極める必要があることに気付きました。 「速く作って、速くフィードバックを得る」という一択ではなく、変更コストに応じてフィードバックを得るタイミングを設計することも、設計者に求められる重要な判断なのだと考えています。

ハウツーは具体例に過ぎない 抽象的な概念はそのままでは実践できない 設計はパターンではない 思考の型は経験によって磨かれる 人間の脳も本質を抽象化している まとめ ソフトウェア設計を学び始めた頃、多くの人は「設計パターン」や「ベストプラクティス」を覚えようとします。 しかし、経験を積むほど、あることに気付きます。 良い設計とは、ハウツーではないということです。 ハウツーは具体例に過ぎない 例えば、100個の設計事例を学んだとします。 それらを一つずつ覚えるのではなく、 なぜその設計が良かったのか 何を守ろうとしていたのか どのような考え方が共通しているのか を考え続けると、100個の具体例は、やがて10個程度の共通した思想へと整理できます。 さらに、その10個を見比べると、もっと本質的な共通点が見えてきます。 最終的には、 「良い設計とは○○である」 という一言で表現できるようになります。 しかし、この一言だけを最初に聞いても、多くの人は何を意味しているのか理解できません。 それは、この一言が100個もの具体例を抽象化した結果だからです。 抽象的な概念はそのままでは実践できない 抽象化された概念は、本質を表しています。 一方で、そのままでは実践には使えません。 例えば、 「責務を適切に分離する」 という言葉だけを聞いても、 実際のプロジェクトで、 どこでクラスを分けるべきか どこまで責務を持たせるべきか 例外的なケースではどう判断するか までは分かりません。 抽象的な概念は、「考えるための軸」を与えてくれるものであり、「答え」そのものではないのです。 設計はパターンではない 設計パターンは非常に役立ちます。 しかし、それだけでは十分ではありません。 なぜなら、ソフトウェア開発で解決したい課題は無限に存在するからです。 チームも違えば、 ビジネス 技術的制約 開発体制 メンバーの経験 将来の変更 もすべて異なります。 つまり、たとえ100個のパターンを覚えたとしても、世の中のすべての問題を解決できません。 だからこそ重要なのは、 パターンを覚えることではなく、未知の問題に対して適切な判断ができる思考の型を持つことです。 思考の型は経験によって磨かれる 思考の型は非常に抽象的です。 そのため、実践経験が少ないうちは、 「なるほど」と思っても、実際の設計にはなかなか活かせません。 さまざまな失敗や成功を経験し、 「あの設計が良かった理由は、この考え方だったのか」 と何度も気付くことで、初めて抽象的な考え方が自分のものになります。 つまり、思考の型は知識ではなく、経験によって検証され、磨かれていくものです。 人間の脳も本質を抽象化している 実は、この考え方はソフトウェア設計に限った話ではありません。 人間の脳は、使わない知識を忘れていきます。 もし、あらゆるハウツーをそのまま覚え続けようとしたら、脳の負担は非常に大きくなります。 そこで脳は、多くの具体例を経験すると、 共通点を見つけ 抽象的な概念へ整理し 必要な場面で、その概念から具体例を導き出す という学習を自然に行います。 つまり、人間は無意識のうちに、 ハウツーを抽象化し、本質だけを残すように学習しているのです。 ソフトウェア設計についても、パターンとして覚えると、世の中の課題の数だけパターンを覚えることになってしまいます。 それは現実的に無理です。 だからこそ、現場でたくさんの事例を見て、そこから共通的な概念を抽出してこそ、初めて現場で使える抽象的な思考の型が身に付くと考えています。 ...

設計とはソフトウェアを作る技術なのだろうか 最初は「応用」だと思っていた 本当に応用していたのだろうか 設計は人間の思考を形にしたものだった 現実世界も設計されている 私が本当に学んだもの このシリーズを書いて分かったこと 設計とはソフトウェアを作る技術なのだろうか ここまでの記事で、私は、 言語化 モデリング 判断 について考えてきました。 そして、設計から学んだ思考法は、ソフトウェア設計だけではなく、 転職活動 UI設計 要件定義 AI活用 など、様々な分野でも役立っていました。 ここで、私は一つの疑問を持ちました。 なぜ設計の考え方が、これほど多くの分野で通用するのだろう。 最初は「応用」だと思っていた 以前の私は、設計を他の分野へ応用しているのだと思っていました。 つまり、設計で学んだテクニックを、人生へ応用している。 そう考えていました。 しかし、今は少し違います。 本当に応用していたのだろうか ここまでの記事を書いてきて、私は一つのことに気付きました。 転職活動でも、要件定義でも、UI設計でも、私がやっていたことは同じでした。 現実を理解する モデルを作る 判断する つまり、設計だけが特別だったわけではありません。 設計は人間の思考を形にしたものだった 私は、設計とは、ソフトウェアを作るために考えられた技術だと思っていました。 しかし、逆だったのかもしれません。 設計とは、人間が良い判断をするための思考を、ソフトウェアという世界で、最も厳密に実践したものだったのです。 だから、前提を考えることも、責任を分けることも、名前を付けることも、違和感を大切にすることも、 すべて、ソフトウェアだけではなく、現実世界でも通用します。 現実世界も設計されている 考えてみれば、企業も、組織も、仕事も、人間関係も、すべて現実世界の仕組みです。 そして、設計とは、現実世界をどう捉えるかを考えることでした。 だから、設計が役立つ範囲は、ソフトウェアだけでは終わらないのです。 私が本当に学んだもの 私は、設計を学んでいました。 でも、今振り返ると、本当に学んでいたのは、 良いモデルを作り、より良い判断をするための思考法 だったのだと思います。 だから、設計だけではなく、人生そのものが変わったように感じたのでしょう。 このシリーズを書いて分かったこと このシリーズを書き始めた頃、私は、「言語化能力が上がった」と思っていました。 しかし、書きながら考え続けることで、 言語化はモデリングだった。 判断はモデルに対して行われていた。 設計の思考法は良いモデルを作るためのものだった。 ということに気付きました。 つまり、 私自身が、このシリーズを書くことで、さらにモデルを更新していたのです。 ここまで来ると、私はこのシリーズ自体が、「言語化しながらモデリングする」というテーマを体現しているように思えます。

良いモデルを作るために、私が設計から学んだ思考法 前提を明確にする 違和感を大切にする 適切な名前を付ける 責任の所在を明確にする 意味のあるものをグループ化する 因果関係に無理がないかを考える ありえない状態を作らない 思考法は目的ではなかった 次に考えたいこと 良いモデルを作るために、私が設計から学んだ思考法 前回の記事では、私は、 人は現実そのものではなく、自分の頭の中にあるモデルを基に判断している。 という考え方にたどり着きました。 もしそうであるなら、次に考えたいことは一つです。 どうすれば良いモデルを作れるのだろう。 私はその答えを、ソフトウェア設計から学んできました。 ただし、ここで紹介する考え方は、ソフトウェア設計だけのものではありません。 今振り返ると、転職活動でも、要件定義でも、UI設計でも、同じ考え方を使っていました。 前提を明確にする 設計では、前提を曖昧にしたまま話を進めることはできません。 前提が違えば、同じ言葉でも意味が変わってしまうからです。 転職活動でも同じでした。 私は、 「良い会社とは何か」 という前提を改めて考えた結果、 「プロ意識の高いチーム」 という結論にたどり着きました。 前提を整理したことで、会社選びの判断で迷うことが減りました。 違和感を大切にする 私がここ数年で最も大切にするようになったことの一つが、違和感です。 設計でも、「何かおかしい」という感覚は、 モデルが現実をうまく表現できていないサインであることが多くあります。 今回のシリーズでも、 「就職活動がモデリングというのは違和感がある。」 というところから、 新しい考え方にたどり着きました。 違和感は、間違いではありません。 考え直すきっかけです。 適切な名前を付ける 名前は、単なるラベルではありません。 現実をどう捉えるかを表しています。 私は、現場で起きていた様々な問題を整理した結果、 「プロ意識」 という名前にたどり着きました。 もし、違う名前を付けていたら、 違うモデルになっていたでしょう。 責任の所在を明確にする 設計では、責任が曖昧になると、変更しづらいソフトウェアになります。 私は、これは人間の思考も同じだと思っています。 何が原因なのか。 誰が責任を持つのか。 どこまでが一つの役割なのか。 責任を整理すると、 現実も整理されます。 意味のあるものをグループ化する 人は、情報が増えれば増えるほど混乱していきます。 だから、関連するものをまとめ、意味のある単位を作ります。 私は、現場で経験した様々な問題を、 「プロ意識」 という一つの概念にまとめました。 これも、モデルを作るということだったのです。 因果関係に無理がないかを考える 設計では、「なぜそうなるのか」を何度も考えます。 せっかく一般的なモデリングから抜け出し、独自のモデリングをしても、因果関係に無理があっては、良いモデルはできません。 今回の転職活動でも、私は、エージェントの担当者から 「マネジメント経験が何年あるか」 を聞かれました。実際に年数で判断される企業様も多いとは思います。 しかし、「年数=実力」ではありません。私は、 「ほかの現場でも再現性のあるマネジメント力なのか」 ...

なぜ人は判断を誤るのだろう 人は現実を見て判断しているのだろうか モデルが違えば判断も変わる 判断を誤る理由 私が設計から学んだこと 判断とはモデルに対して行うもの 次に考えたいこと なぜ人は判断を誤るのだろう ここまでの記事で、私は、 言語化することで判断に自信が持てるようになったこと 就職活動もモデリングだったこと 言語化すること自体がモデリングだったこと について書いてきました。 そして、ここで一つの疑問が生まれました。 なぜ、モデリングすると判断の質が上がるのだろう。 この問いについて考えているうちに、私は、もう一つの問いにたどり着きました。 なぜ人は判断を誤るのだろう。 人は現実を見て判断しているのだろうか 私たちは普段、 「現実を見て判断している」 と思っています。 しかし、本当にそうでしょうか。 例えば転職活動なら、会社そのものを見て判断しているわけではありません。 私たちは、会社について知っている情報から、頭の中で会社のイメージを作り、そのイメージを基に判断しています。 つまり、 判断している相手は、現実そのものではなく、自分の頭の中にあるモデルなのです。 モデルが違えば判断も変わる 例えば、 「良い会社とは何か」 という問いがあります。 ある人は、 年収 福利厚生 を重視するかもしれません。 別の人は、 技術力 最新技術 を重視するかもしれません。 私は、 プロ意識の高いチーム を最も重視するようになりました。 同じ会社を見ても、評価が違うのは、見ている会社が違うからではありません。 頭の中で作っているモデルが違うからです。 判断を誤る理由 では、なぜ人は判断を誤るのでしょうか。 私は、理由はいくつもあると思います。 例えば、 前提が曖昧だった。 重要ではないものを重要だと思っていた。 因果関係を誤解していた。 現実を十分に整理できていなかった。 つまり、 モデルそのものに問題があった。 ということです。 モデルが曖昧なら、そこから導かれる判断も曖昧になります。 逆に、モデルが整理されていれば、判断の根拠も明確になります。 私が設計から学んだこと 私は、設計とは、コードを書く技術ではなく、 現実世界をどう捉えるかを定義すること だと考えています。 だから設計では、 名前を付ける 責任を明確にする グループ化する 前提を確認する 違和感を大切にする といったことを繰り返します。 これらは、良いコードを書くためのテクニックではありません。 良いモデルを作るための思考法なのです。 判断とはモデルに対して行うもの ここまで考えて、私は一つの考えにたどり着きました。 ...

言語化とモデリングは何が違うのだろう 言語化とは何だろう 言語化していたつもりだった 言語化すること自体がモデリングだった 言語化とモデリングはほぼ同じだった なぜ様々な分野で成長できたのか あらゆる物事をモデルとして捉えるようになった 言語化とモデリングは何が違うのだろう 前回の記事では、「就職活動もモデリングだった」という話を書きました。 しかし、ここで一つの疑問が生まれました。 言語化とモデリングは何が違うのだろう。 これまで私は、「言語化できるようになったこと」が、判断力の向上につながったのだと考えていました。 しかし、前回の記事を書いている途中で、その考え方が少し変わりました。 言語化とは何だろう 一般的に「言語化」というと、 「考えを言葉として表現すること」 という意味で使われることが多いと思います。 もちろん、それも間違いではありません。 しかし、このシリーズでは、もう少し広い意味で考えています。 例えば、 言葉で説明する 図で表現する 表で整理する これらはすべて、自分の考えを他人と共有できる形にしたものです。 つまり、表現方法が言葉か図かという違いはありますが、本質的には同じことをしていると考えています。 言語化していたつもりだった 転職活動について考えていたとき、私は、 「プロ意識の高いチームであること」 という判断軸を言葉にしていました。 最初は、それを「言語化」しているだけだと思っていました。 しかし、改めて考えてみると、私は単に言葉を選んでいたわけではありません。 「プロ意識」とは何か。 その言葉は本当に適切なのか。 他の言葉では表現できないのか。 どのような現場経験がその根拠になっているのか。 こうしたことを繰り返し考えながら、一つの考え方を作り上げていました。 つまり、 言葉を選んでいたのではなく、捉え方そのものを作っていたのです。 言語化すること自体がモデリングだった ここで、ようやく気付きました。 私は、 言語化をしていたのではなく、 言語化しながらモデリングをしていたのです。 もっと正確に言えば、 言語化すること自体がモデリングだった。 言葉を書くことと、モデルを作ることは、別々の作業ではありませんでした。 同時に行われていたのです。 言語化とモデリングはほぼ同じだった ここまで考えて、私の中では、 言語化とモデリングは、ほとんど同じ意味になりました。 もちろん、厳密に区別することはできます。 例えば、頭の中だけで考えている状態でも、モデルは存在できます。 一方で、そのモデルを言葉や図、表などによって、他人にも理解できる形に表現したものを、言語化と呼ぶこともできるでしょう。 ただ、この違いは今回の記事で伝えたい本質ではありません。 私が重要だと思ったのは、 言語化しようとすると、自然とモデリングが始まる。 ということです。 なぜ様々な分野で成長できたのか 私はここ最近、 ソフトウェア設計がうまくなった。 要件定義がうまくなった。 UI設計がうまくなった。 転職活動でも以前より迷わなくなった。 そんな実感がありました。 最初は、 言語化能力が上がったからだ と思っていました。 しかし、今は少し違う考えになっています。 言語化しようとする過程で、自然とモデリングするようになっていた。 だから、判断の質も、設計の質も、説明する力も、一緒に向上していたのだと思います。 ...

「言語化できるようになった」と思っていた。しかし、本当に身に付いていたのは別の能力だった。 言語化自体は昔からやっていた 共通点を探してみた しかし、就職活動がモデリングというのは違和感があった そもそもモデリングとは何だろう なぜ就職活動はモデリングに見えないのか 自分でモデルを作る 就職活動もモデリングだった 「言語化できるようになった」と思っていた。しかし、本当に身に付いていたのは別の能力だった。 前回の記事では、設計を学んだことで、人生のさまざまな判断に自信が持てるようになったことを書きました。 私は、その理由を「言語化できるようになったから」だと考えていました。 実際、 転職活動 UI設計 要件定義 どれも以前より考えを整理し、他人にも説明できるようになっていました。 しかし、あるとき疑問が浮かびました。 本当に言語化がすごかったのだろうか？ 言語化自体は昔からやっていた よく考えてみると、 言語化そのものは昔からやっていました。 文章も書いていましたし、 技術記事も書いていました。 もちろん、多くの人も普段から言語化しています。 つまり、 言語化という行為そのものが新しかったわけではありません。 では、何が変わったのでしょうか。 共通点を探してみた そこで、 転職活動 UI設計 要件定義 ソフトウェア設計 これらを並べて考えてみました。 すると、 ある共通点が見えてきました。 私は、 どれも現実世界を整理し、 理解しやすい形に作り直していました。 設計でいうところの、 モデリング です。 しかし、就職活動がモデリングというのは違和感があった ここで私は引っ掛かりました。 設計はモデリングです。 要件定義も分かります。 UI設計も何となく分かります。 でも、 就職活動がモデリング？ 最初は違和感がありました。 就職活動でやっているのは、単に考えを言葉にしているだけではないか。 そう思っていました。 そもそもモデリングとは何だろう 改めて考えてみました。 私は、モデリングとは 現実世界をどう捉え、どう表現するか だと考えています。 その表現方法は、 図かもしれない クラス図かもしれない ドメインモデルかもしれない 日本語かもしれない つまり、 言葉で表現することも、モデリングの一つなのではないか。 そう考えるようになりました。 なぜ就職活動はモデリングに見えないのか ここでようやく違和感の理由が分かりました。 一般的な就職活動では、 すでに 仕事内容 年収 残業時間 福利厚生 というモデルが出来上がっています。 ...

転職活動で最も変わったこと 言語化すると、判断の理由を説明できる 他人との議論の質も変わった 言語化は、判断に自信を与えてくれる この記事シリーズは、すぐに使えるハウツーを書いたものではありません。 なぜなら、特定の状況に応じて特定の解決方法が存在するものではないと考えているためです。 この記事は、ハウツーではなく、認知方法を変化させることに価値がある内容となっています。 そのため、私の経験や思考を追体験できるように書いています。 なぜハウツーではないのかについて、詳しくは 良い設計は、なぜハウツー（How to）ではないのか で言及しています。 ここから本題に入ります。 私は以前から、設計とは「現実世界をどう捉えるか」を定義することだと考えています。 この考え方を用いることで、ソフトウェア設計だけではなく、UI設計や要件定義など、開発のさまざまな場面にも応用できると感じていました。 しかし、最近は、その考え方の応用範囲がさらに広がっていると感じます。 きっかけは転職活動です。 一見すると、ソフトウェア設計とはまったく関係のない分野ですが、転職活動を進める中で、自分の判断の質が以前よりも明らかに向上していることに気が付きました。 最初は「なぜだろう」と考えていましたが、振り返ると、その理由は言語化できるようになったことにあるのではないかと感じました。 転職活動で最も変わったこと 私は現在、転職活動で最も重視することとして、 「プロ意識の高いチームであること」 を第一に掲げています。 もちろん、 仕事内容 年収 残業時間 技術力の高いエンジニアがいること なども重要です。 しかし、それらは「第一に優先すべきこと」ではないという結論に至りました。 この考え方は、突然思いついたものではありません。 これまで経験してきた複数の開発現場を振り返り、 なぜその現場はきつかったのか 何が問題だったのか 何はそれほど重要な問題ではなかったのか を一つひとつ整理していくと、以下のような状況が重要な問題なのではないかと考えました。 建設的な議論ができない 先輩から言われたことしかやらない人がいる チームの利益より自己の利益を優先して行動していると感じる人がいる などでした。これらを一言で表現すると、彼らは「プロ意識に欠けていたのではないか」と感じました。 そこから 「プロ意識の高いチームであること」 を最優先にするべきだと考えました。 以前の私は、 現場のエンジニアのレベルが高いこと 仕事内容 年収 残業時間 といった、一般的な判断基準を中心に会社を選ぼうとしていました。 もちろん、それらは今でも重要です。 しかし、それらは本質ではなく、「プロ意識の高いチーム」という土台があってこそ価値を発揮するものだと考えるようになりました。 言語化すると、判断の理由を説明できる この変化で最も大きかったことは、 「なぜその判断をするのか」を説明できるようになったことです。 以前は、 「なんとなくこの会社が良さそう」 という感覚で判断していた部分がありました。 しかし今では、 「私はプロ意識の高いチームを最優先にしています。その理由は……」 と、その判断の背景まで説明できるようになりました。 自分自身に対しても、 「なぜこの会社を選ぶのか」 を説明できるため、判断に迷いが少なくなり、自分の選択に自信を持てるようになったと感じています。 他人との議論の質も変わった 言語化できるようになったことは、自分の中だけの変化ではありませんでした。 転職エージェントの担当者との面談でも、その効果を実感しました。 転職エージェントの担当者は、必ずしもエンジニアではありません。 そのため、現場で何が起きているのか、どのような組織であれば働きやすいのかは、私から説明しなければ伝わらないことが多くあります。 以前であれば、 「なんとなく違う気がする」 という感覚しか伝えられなかったかもしれません。 ...