kenju's blog

About Programming, Mathematics, Security and Blockchain

ソフトウェア設計時に押さえておきたいポイント

現場の先輩エンジニアから教えてもらったことをもとに、ソフトウェア設計時に押さえておきたいポイントを自分なりにまとめて見ました。 非常に学びが多いアドバイスで、今後も事あるごとに思い出したいと感じたので、よかったら参考にしてください&フィードバックウェルカムです。

  1. 実装の選択肢はMECEで上げきる
  2. 実装の選択肢を判断する比較軸を明確にする
  3. その比較軸を持って利点・欠点をまとめる
  4. 「選択と集中」

実装の選択肢はMECEで上げきる

MECE principle - Wikipedia

設計をする際、まずいくつかの選択肢をあげるかと思います。このとき、「MECE」であることは非常に大事です。

そもそも知らなかったり、その分野での経験が浅かったりするとMECEにあげきるのは難しいかもしれません。その場合は、最初のステップでもあるので、早め早めのフィードバックを心がけます。逆に言うと、「MECEにあげきった」と納得がいった上で次以降のプロセスに進まないと、またこの「実装の選択肢をMECEで上げきる」ステップに逆戻りしてしまいます。

実装の選択肢を判断する比較軸を明確にする

次に、実装の候補としてあげたそれぞれの選択肢を比較するための、「比較軸」を明確にします。私の場合は、↓をテンプレートとして心がけています。

  • 開発時
    • 保守性・可読性
    • エラー発生リスク
    • 実装コスト
    • 拡張性・変更に対する柔軟性
  • 実行時
    • メモリ消費量
    • オーダー(計算量)
    • 実行時間
  • 実際の挙動
    • 仕様に沿っているかどうか
    • エンドユーザーの使い勝手はどうか
  • その他
    • 金銭面でのコスト

その比較軸を持って利点・欠点をまとめる

選択肢をMECEにあげきり、複数の比較軸を明確にして初めて、利点・欠点をまとめることができます。そのようにしないと、論理的に利点・欠点をまとめることができず、恣意的な利点・欠点を意識的・無意識的にあげてしまったりしてしまいます。

「選択と集中」

「設計のコアとなる部分。一旦実装を始めたときに、この部分が間違っていたら大きな手戻りとなる部分」と、「設計の選択肢の判断材料としては軽微な問題で、実装途中でツッコミが入ってもその場の修正で済む部分」とは、分けましょう。特に、設計レビューを行う場合、「選択と集中」のプロセスを通して、本当にレビューすべき観点に注力するのは大事です。

設計プロセスアンチパターン

  • 「とりあえず週末に実装して見たパターンがうまくいったので、そのままの設計で押し切る」
    • メモリ消費量・セキュリティリスク・設計の柔軟性など、見逃していることは本当にないか?選択肢を比較する中で生まれる案や考慮ポイントも存在するので、必ず「選択肢をあげ、比較軸を持って比較する」というプロセスを踏むようにしましょう
  • 「いくつか選択肢をあげたけど、全くMECEになっていない」
    • せっかく時間をかけて選択肢をあげ比較したとしても、そもそもの土台が間違っていたら、無駄な労力となってしまいます。経験が浅かったり、知識がない場合は"しょうがない"と言い訳をできるかもしれませんが、選択肢をあげ切った時点で早め・早めのフィードバックループを回しましょう