エンジニアとして、注意することは結構人によって違うので、「いやいや、これ〇〇だよ？大丈夫？」みたいなのを案外と人が気がついていないとかはある。意外と設計や実装はよく知られた原則やプラクティス、考え方があったりして、それを引用したりすることができるが、その前段階の要求や仕様を受け取ったときに何に気をつけるかはビジネス的な部分とソフトウェア工学的な部分が混じっていて、これといった引用できるものがないので共通認識を作りにくい部分なのかなと思う。

こういったことに対して、起きたときにその問題自体の説明はするけれど、大きな枠組みとしての注意点を説明することは少ないなと思ったのと、自分の中でもまとまってないように感じたのでチェックリスト的な感じの箇条書き形式で書き出してみることにした。

大雑把な思考

空間的、時間的、心理的な距離の大小をある程度広く取って考えるようにする
- 思考の範囲を自分のすぐ近くのこと、人、直近のことだけに限定しすぎない
実行する物事よりも、達成したい目的から考えるようにする
結果につながらないことにコストを掛けすぎない
- 費用対効果の議論に時間を掛けすぎるより、評価のための実装してしまったほうが早い場合もある
意見を肯定/否定の二軸で判断しない
- その意見を肯定的/否定的に見るべきでないということではなく、そう見る理由をきちんと考える（単なる感情による決断にしない）
- 組み合わせ、飛躍、逆説、部分的変更を加える、部分的に削ることで良い意見とできないか考える

事前情報の整理

その要求や仕様が達成、解決しようとしていることはなにか
その要求、仕様によって影響を受ける機能はなにか、どのような影響を受けるか
- すでに実装済み、実装中、今後想定される機能から考える
- とくにネガティブな影響（制約等の追加など）を受けるものは注意する
- 開発中の実装や運用中などを問わず考える
その要求、仕様によって影響を受ける人は誰か
- ユーザーだけでなく、他エンジニア、デザイナー、QAなどサービスに関わる人全体を考える
コストや効果、リスクを見積もるために必要な情報が足りているか
- 必要な情報はリストアップして揃えられるようにする

設計、実装に入る前に確認すること

想定している効果を生むことが本当に必要なことか

機能を実装することが目的にならない

想定している効果を生む要求、仕様となっていると言えるか

評価できていないのなら、その要求と効果を簡単に評価できる方法が存在しないか（他サービスとの比較でも）
- 比較による評価の場合、比較対象との違いがあることを認識したうえで評価する
目的に沿っているかどうかはきちんと見定め、未然に防げるリスクを減らす
- 目的にそっていなかったが、それがたまたま良い結果をもたらすものもあるが、それは奇跡に近いことでビジネスとして良い方法とは言えない

実装のコストに対して、想定している効果が見合っているか

エンジニアとしては最も目が向きやすい場所だが、きちんと必要に応じて見積もりを出し、効果と比較する
効果の評価は実装するエンジニアでなく、プロダクトオーナーなどからの情報を重視する
- 単に鵜呑みにするのではない

保守、運用のコストに対して、想定している効果が見合っているか

保守や運用のコストを見積もっていないと、実際に運用や保守時に想定している効果を生むことができなくなる
リリース後ではなくても、開発中でも保守や運用があることを忘れない
- 開発中の環境や機能保守は存在する

同じような効果を生む、各種コストの低い方法が提案できないか

大胆なアイディアでなくとも、元の方法から多少の変更を加える、または削るといったことでもよい
ただし、提案時にきちんとセットで理由を説明できること

リスクはなにか、リスクを取り除く必要があるか

リスクは結果的に負債となり得る
早期に取り除くべきリスクがある場合、それも見積もるべきコストになる
実装可能な人員が限られていないか
実装後の機能に利用するサービス、ライブラリが利用できなくなる可能性はないか

思うままにつづる

※当ブログは個人の見解であり、所属組織とは関係なく、効果効能を保証するものではありません

【個人的】エンジニアの設計、実装前に注意することリスト