None

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

判断軸1：オフラインでも利用したいか Webアプリの場合 ネイティブアプリの場合 判断軸2：端末機能をバックグラウンドで利用したいか Bluetoothを例に考える ネイティブアプリの場合 Webアプリの場合 Webアプリでもバックグラウンド処理が全くできないわけではない Webアプリとネイティブアプリの本質的な違い まとめ アプリ開発では、「Webアプリで作るべきか」「ネイティブアプリで作るべきか」という判断が必要になります。 近年ではWeb技術でも高度なUIを実現できるようになり、PWA（Progressive Web App）なども登場しています。 そのため、単純に「ネイティブアプリのほうが優れている」というわけではありません。 重要なのは、ユーザーが求める価値を実現するために、どちらの技術が適しているか判断することです。 Webアプリとネイティブアプリを選択する際には、様々な点を考慮する必要がありますが、この記事では、主に実現できる機能の違いにフォーカスをあてて、2つの判断軸について整理します。 判断軸1：オフラインでも利用したいか Webアプリとネイティブアプリの大きな違いの1つが、通信できない環境への対応です。 Webアプリの場合 Webアプリは基本的に、サーバーと通信しながら動作します。 ユーザー ↓ ブラウザ ↓ インターネット ↓ サーバー 例えば、データを登録する場合、 入力 ↓ サーバーへ送信 ↓ 保存完了 という流れになります。 そのため、通信できない環境では利用できない、または利用できる機能が制限されることが多いです。 ネイティブアプリの場合 ネイティブアプリでは、端末内部にデータを保存できます。 例えば、 ユーザー入力 ↓ 端末内へ保存 ↓ 通信復旧後にサーバー同期 という設計が可能です。 そのため、 電波の届かない場所での作業 災害現場での利用 航空機内での利用 山間部での作業記録 など、通信が不安定な環境ではネイティブアプリが有利になります。 判断軸2：端末機能をバックグラウンドで利用したいか スマートフォンには、 GPS Bluetooth NFC カメラ 各種センサー など、多くの端末機能があります。 Webアプリでも、ブラウザが提供するAPIを利用することで、一部の端末機能を利用できます。 例えば、 カメラでQRコードを読み取る 現在位置を取得する NFCタグを読み取る といった処理は、Webアプリでも実現できる場合があります。 しかし、Webアプリには大きな制約があります。 それは、ブラウザ上で実行される処理であるため、バックグラウンドで継続的に動作することが難しいことです。 Bluetoothを例に考える 例えば、温度センサーとBluetoothで通信するアプリを考えます。 ネイティブアプリの場合 アプリ起動 ↓ Bluetooth接続 ↓ アプリがバックグラウンドになる ↓ 継続的にデータ取得 ↓ サーバーへ送信 という設計が可能です。 ...

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

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

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

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

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

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

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