実務で一番辛かったのは実装ではなく仕様認識ズレだった

はじめに

エンジニアになったばかりの頃、私は

「難しい実装が一番大変なんだろう」

と思っていました。

例えば、

• 複雑なアルゴリズム
• AWS構築
• 大規模データ処理
• パフォーマンス改善

などです。

もちろん技術的に難しい作業はあります。

ただ、実際に現場で働く中で感じたのは、「本当に辛いのは実装そのものではない」ということでした。

実務で特に苦労したのは、“仕様認識ズレ”です。

つまり、

「思っていた仕様と違った」

「相手と認識がズレていた」

という問題です。

しかも厄介なのが、コード自体はちゃんと動いていることも多い点です。

今回は、実務で感じた「仕様認識ズレの怖さ」について書いてみたいと思います。

実装が正しくてもダメなことがある

新人時代、私は

「要件通り実装すればOK」

だと思っていました。

ただ実務では、

• 認識違い
• 解釈違い
• 前提違い

がかなり発生します。

例えば、

「郵便番号が無い場合は空文字で返してください」

という仕様があったとします。

私は最初、

return ""

で良いと思っていました。

しかし後から、

• Noneを返す想定だった
• 項目自体を出力しない想定だった
• エラー扱いだった

などが判明することがあります。

つまり、コードは動いていても、“期待されている動き”と違うことがあります。

これがかなり難しかったです。

“言葉”がかなり曖昧だった

実務で驚いたのが、仕様書や会話の言葉が思った以上に曖昧だったことです。

例えば、

• 「いい感じに」
• 「通常通り」
• 「今まで通り」
• 「基本的には」
• 「必要に応じて」

など。

新人時代は、

「なんとなく分かった気になる」

ことが多かったです。

ただ、後から認識ズレになるケースがかなりありました。

特に辛かったのが、

“全員理解しているつもり”

な状態です。

会議中は誰も疑問を持っていないように見えても、実際には各自が違う解釈をしていることがあります。

これは実務に入ってかなり怖いと思った部分でした。

実装後に仕様変更のような話になる

仕様認識ズレで辛いのが、かなり後工程で発覚することです。

例えば、

• 実装完了
• テスト完了
• レビュー完了

した後に、

「想定と違いました」

となるケースがあります。

しかも実装側からすると、

「最初にそう言ってほしかった…」

と思うこともあります。

ただ実際には、相手側も悪意があるわけではないことが多いです。

• イメージで話していた
• 前提が共有されていなかった
• 既存仕様を当然だと思っていた

などです。

そのため、単純に“誰が悪い”で終わらない難しさがあります。

実務では“確認力”がかなり重要だった

実務を通してかなり変わったのが、「確認する意識」です。

新人時代は、

「分からないことだけ質問する」

感じでした。

ただ経験を積むと、

“分かっているつもりの部分ほど確認する”

ようになりました。

例えば、

• 空文字ですか？Noneですか？
• 異常系時どうしますか？
• この項目は必須ですか？
• 既存仕様に合わせますか？
• このケースは対象外ですか？

などです。

最初は、

「細かすぎるかな…」

と思っていました。

ただ、実際には確認不足の方が後でかなり大変になります。

特に運用中システムでは、認識ズレが障害につながることもあります。

“認識合わせ”が上手い人はかなり強かった

実務で見ていてすごいと思ったのが、認識合わせが上手い人です。

例えば、

• 図を書く
• 具体例を出す
• 入出力例を見せる
• パターン分けする

などを自然にやっていました。

特に印象的だったのが、

「つまり○○という認識で合っていますか？」

をかなり丁寧にやる人です。

これによって、曖昧な部分がかなり減ります。

逆に、

「多分こうだろう」

で進めると、後からズレやすいです。

私は最初、この“認識合わせ”を軽視していました。

しかし実務では、ここがかなり重要だと感じるようになりました。

実装力だけでは解決できない

仕様認識ズレの厄介なところは、「技術力だけでは防げない」ことです。

どれだけ実装が上手くても、

前提がズレていたら意味がありません。

そのため実務では、

• 質問力
• 整理力
• 説明力
• 確認力

もかなり重要になります。

実際、仕事ができる人ほど、

「認識ズレを減らす動き」

がかなり上手かったです。

まとめ

エンジニアになる前は、

「難しい実装が一番大変」

だと思っていました。

ただ実務では、それ以上に、

“仕様認識ズレ”

で苦労することがかなり多かったです。

特に怖いのが、

• コードは動いている
• 実装ミスではない
• でも期待と違う

という状態です。

私自身、最初は

「ちゃんと実装すれば大丈夫」

と思っていました。

しかし実務を通して、

「まず認識を揃えること」

の重要性をかなり感じるようになりました。

今では、実装そのものより、

「相手と同じイメージを持てているか」

を意識する時間の方が増えた気がします。