はじめに
こんにちは。
プロダクト開発組織・人材を対象に、開発パフォーマンス・生産性の最大化インフラ Offers MGR と副業転職プラットフォーム Offersを運営する株式会社 overflow のエンジニアの藤井です。
みなさま、実装の前にきちんと設計のドキュメントを作成していますでしょうか？
昔、私が働いていた大手 SIer の現場では、
・・・といったように、じつに事細かな設計工程が組まれておりました。
しかし事業会社の開発組織で、このような工程を採用している現場は稀でしょう。
特にスタートアップの、ごく少人数でビルド＆スクラップを繰り返す製品のローンチ段階では、"<b>実装こそ仕様！ ドキュメントなどない！</b>"というストロングスタイルが必要だったりします。
そのため、その後もドキュメントを残す文化が根付きづらい、という話もよく聞きます。
(その点、弊社はドキュメンテーションの文化が最初からインストールされていたので、入社時にいい意味でびっくりしました w)
しかし当然ですが、事業が進展していくにつれて、そのままのスタイルで貫き通すことは現実的には難しくなっていきます。
製品ローンチ直後は事業規模も小さいため、製品に多少の瑕疵があっても問題にならないことも多いものです。
(ユーザが存在しないのなら、バグもまた存在しない)
しかし事業規模が拡大すれば、各種のトラフィックもまた増大するため、徐々に問題が顕在化していきます。
そこで事前に製品の品質を担保するための活動として、設計という工程の重要性が高まっていくことになります。
設計と暗黙知
設計は暗黙知の占める割合が非常に大きい作業でもあります。
暗黙知に依存したスキルは、当然、学習者にとって大きな障壁になり得ます。
そのため、特に若手のエンジニアにとってはハードルが高く感じやすいのではないでしょうか？
設計の定義について コトバンクの記述 を見ると、以下のようにあります。
構造物の構造を、実際の生産に必要かつ十分な程度に決定し、その結果を設計図、仕様書、取扱い説明書などとして表現する営為をいう。
上記の定義に従えば設計の目的には、必ず何らかのドキュメント(=形式知)を作成することが含まれています。
(「設計はおれの頭の中にある！」という人がいても、決して信用しないようにしましょう。アイデアと設計は別物です)
ドキュメント(形式知)を作成する前に、設計の頭脳労働(暗黙知)が存在します。
設計は与えられた要件やアイデアに対して、最適な解法を与えるもの、とも言えますが、単純なアルゴリズムとは大きくちがう点があります。
それは、必ず"現実"という制約条件がつきまとう、ということです。
要件そのものに複雑性は存在することもありますが、現実の制約条件がさらに輪をかけて問題を複雑にし、多くの変数を生み出すことになります。
こういった変数の多さが、設計を暗黙知化しやすい原因と考えられます。
ソフトウェア設計で使う道具と言えば、シーケンス図や ER 図などが有名ですが、それらはあくまで道具であって、それ自体で設計にはなり得ません。
(適切な問題に対し、適切な道具を選ぶこともまた技術)
結局、習得にはひたすら実践を繰り返すしかないのですが、若手のエンジニアがつまずきやすいポイント、というのがあります。
今回は、そんなときにあらかじめ知っておくと少し楽になる設計のノウハウ 3 つをご紹介します。
設計の三つのノウハウ
イシューを見つけ、分解する
設計の際、まず最初にすべきことは"何について考えるか"を考える、つまり、イシュー(論点、課題)を考えることです。
私は設計のドキュメントを書き起こす際は、いつも最初に全体の見出しを考えることから始めます。
(最近は Notion で書くことが多いので、"見出し 1"のブロックコードをずらずらと書き並べます)
見出しがそのまま設計のイシューになるので、そのイシューを分解できるようなサブイシューを考え、それを小見出しにして書き出します。
このあたりの思考技術については、設計技術とも親和性が高いため一冊くらいロジカルシンキング系の本を読んでおくと良いでしょう。
おすすめの本を二冊ほど紹介しておきます。
(個人的にはグロービスの本が読みやすかったです)
-
ロジカル・シンキング ~ 論理的な思考と構成のスキル ~
https://amzn.asia/d/cOgrDb6 -
改訂 3 版グロービス MBA クリティカル・シンキング
https://amzn.asia/d/aXsyAA6
また基本的に、設計のイシューに発明はないことも事前に知っておくと良いでしょう。
ほとんどの場合、経験則からイシューが発見されるため、経験が不足しているうちは素直に有識者に頼るのが一番の近道です。
複数の選択肢から、意思決定(トレードオフ)をする
まず前提として、各イシューについて実現方法を考えるとき、必ず複数の選択肢を出すように心がけるべきです。
昔、私自身、とあるトレーナーからメンタリングを受けた際「いついかなる時も常に最低 5 個の選択肢を挙げることを習慣にせよ」と言われて気が遠くなりました。
(どんな馬鹿げた案でもいいから、まずは俎上に上げることが重要、とも言われました)
さすがに 5 個は多すぎると思うので、まずは 3 個くらいを目標にするのが良い、と個人的には思います。
程度によりますが、イシューを特定できれば技術的な選択肢を見つけ出すことはそれほど難しくありません。
自分一人の頭で考えるのではなく、ネットからチームの仲間、あらゆる情報資源を活用すれば良いだけです。
複数の選択肢を上げることができれば、各選択肢のメリット/デメリットを整理します。
必要に応じて、メリデメ表などの中間ドキュメントを作成するのも良いでしょう。
設計のためには、大小様々な意思決定をしていく必要があります。
すべての基準で完全な選択肢など、この世に存在しません。
そのため、意思決定とはメリットのために一定のデメリットを選択(=トレードオフ)することでもあります。
意思決定の中には、自明であったり、影響が軽微であるため設計者の独力で解決できるものもありますが、自分以外のステークホルダーの決裁を仰ぐ場合もあるでしょう。
どちらの場合も、事前に複数の選択肢を用意しておくことが役立つはずです。
この「設計には意思決定が必要」という点は、特に若手のエンジニアが重圧を感じやすく、尻込みしてしまう一因ではないか、と感じます。
しかし、まずは知っておくべきは、もとより完璧な意思決定は存在しない、ということです。
また、こういった入念なステップを踏んでおくことで意思決定の品質に貢献することにもなり、何かしら問題が発生した時も自分やチームを救うことにつながります。
その上で大事なのは、設計者とは意思決定を導く当事者である、という認識を強く持つことです。
「不安」を利用して、必要十分を判断する
よく若手のエンジニアが悩むポイントのひとつに、どこまで事前に、かつ詳細に設計しておくべきなのか、という問題があります。
前述で紹介した SIer の現場では、関数単位でのプログラム設計書を作成し、それを見ながら作業者がコーディングをしていく、というようなことをしていました。
これは「大人数開発での品質保証 + 不具合に対する無限責任 + 設計書も納品対象」というビジネス上の制約から生み出されたもので、あくまで特殊な例です。
当然ですが本来、設計は計画でしかなく、それ自体は一切の利益を生みません。
そして、どのような開発現場であっても、製造にかけられるコスト(人的、時間的、金銭的)は有限です。
そのため設計作業は必ずどこかで終えなければなりませんが、その終了条件は以下の問いに答えられるかどうかとなります。
- 次の工程が開始できるか？
- そして、問題なく完遂できるか？
先ほどのコトバンクの定義をもう一度、振り返ってみましょう。
構造物の構造を、実際の生産に必要かつ十分な程度に決定し、その結果を設計図、仕様書、取扱い説明書などとして表現する営為をいう。
この「必要かつ十分」を見極めるために有効な判断材料のひとつは「不安」です。
書くべきプログラムのロジックは、イメージできそうでしょうか？
製品をリリースしたとき、致命的なバグが発生しないでしょうか？
不安のひとつひとつを言語化しましょう。
もしかしたら、そこに未発見のイシューが隠れているかもしれません。
イシューが発見できれば、設計して備えることができます。
あらかたの不安が片付いたのなら、それこそ設計が完了した合図になるでしょう。
まとめ
いかがでしたでしょうか？
今回は、若手エンジニアが悩みがちな設計について、3 つのノウハウをご紹介させていただきました。
- イシューを見つけ、分解する
- 複数の選択肢から、意思決定(トレードオフ)をする
- 「不安」を利用して、必要十分を判断する
ソフトウェアの設計は奥が深く、習得には実践を伴った長い年月が必要です。
本来、ブログの一記事で語り尽くすことなど到底不可能ですが、本記事がその糸口にでもなれば幸いです。
関連記事
副業転職の Offers 開発チームがお送りするテックブログです。【エンジニア積極採用中】カジュアル面談、副業からのトライアル etc 承っております💪 jobs.overflow.co.jp
Discussion
関連記事、URLに「.md」が入っているので404になってしまっているようです！
ご指摘ありがとうございます！修正いたしました🙇