はじめに
私はSIer企業に勤める、新卒2年目のエンジニアです。
今回は、私一人だけが炎上してしまったPJを振り返り、そこで気づいたこと・学んだことをまとめます。
正直、記憶からは消し去りたい経験です。しかし、今後のエンジニア人生において「消し去ってはいけないこと」「二度とやってはいけなかったこと」が数多く詰まっているため、あえて言語化して記事に残すことにしました。
同じような立場の若手エンジニアの方や、これから設計・議事録・AI活用に向き合う方の参考になれば幸いです。
まず、今回の3つの失敗を一枚の図で俯瞰します。
失敗1：頭の中を、そのまま設計書に落とし込んでしまった
何が起きたか
本PJでは、初めて要件定義書や各種設計書の作成を任せていただきました。
過去の資料（第1弾・第2弾と、事前に開発が行われていたPJでした）や、私自身が過去に参加したPJの資料を参考にしながら、各種ドキュメントを作成していきました。
ここで私がやってしまったのは、フィジビリティ（実現可能性）を確認しないまま、頭の中の想像だけで設計書に起こしてしまったことです。
ボタンを押下したらダイアログがこのように開いて、そのダイアログで選択した項目は元の画面にセットされて……
このように、PJで使用している言語・フレームワークで本当に実現できるのか、実現した場合にどんな挙動になるのかをまったく確認せずに書き進めてしまいました。
結果として、大量のレビュー指摘を受け、最終的には設計書をほぼ一から作り直すことになってしまいました。
「本当に実現できるのか？」「どうやって実現するつもりなのか？」という問いに、私は何ひとつ答えられませんでした。
なぜ失敗したのか
- 参考資料の「見た目」だけを真似て、裏側の実装可能性を検証しなかった
- 既存改修なのに、他機能での実装状況を調べなかった
- 「たぶんできるだろう」という前提で設計を進めてしまった
学んだこと：ヒアリング時点でフィジビリティを確認する
顧客要件をヒアリングしたその時点で、フィジビリティを確認することが重要だと痛感しました。
特に既存改修の場合は、次の観点で確認すべきでした。
- 他の機能で、同じことがすでに実装されていないか
- 他機能の実装に機能を追加することで実現できないか
- 公式ドキュメントを確認し、実際にモックを作成して挙動を検証する
そして、確認した結果実現不可能だった場合は、代替案を複数提示する必要があります。その際も、代替案そのものの創出だけでなく、代替案のフィジビリティ確認までセットで行うべきです。
正しい進め方を図にすると、次のようになります。
「想像で書く」のではなく「検証してから書く」。 これが失敗1から得た最大の学びです。
失敗2：すべての発言を追って記録しようとしてしまった
何が起きたか
本PJで初めて任せていただいたタスクの一つが、会議に参加して議事録を作成することでした。
議事録のメインはMicrosoft 365 Copilotを利用しますが、決定事項や宿題事項は人間による修正が必要なこと、そして練習を兼ねて、自分でも議事録を作成することになりました。
初回のみ対面、2回目以降はオンラインでの会議でしたが、初回は事前準備も、会議中の議事メモも、すべてが失敗に終わりました。
そもそも事前準備の段階で、名刺交換の作法や挨拶のことばかり気にしてしまい、「何を議論し、何を決定すべき会議なのか」を理解せずに臨んでしまったのです。
その結果、以下のような状態に陥りました。
- 一人ひとりの発言を、すべて追ってメモしようとする
- 会議の内容そのものを理解できない
- 決定事項も宿題事項も曖昧なメモにしかならず、自分でも何を書いたのか分からないまま終了
学んだこと：議事録は「事前準備」がカギを握る
第1回の失敗を踏まえ、第2回以降は事前準備を徹底してから会議に臨みました。
具体的には、次の3点を事前に確認しました。
- おそらく決めるであろう事項
- 前回の宿題事項と、それに対するこちらの回答
- おおよその議論の展開
そして会議中は、決定事項や議論の流れに不要な会話は思い切って捨て、事前準備で用意した骨組みに沿って議事メモを取ることを心がけました。
その結果、第2回こそ「議論の内容をもう少し詳細に書いてほしい」といったレビュー指摘がありましたが、それ以降はほとんど指摘なく議事録を作成できるようになりました。
失敗前と失敗後で、アプローチは次のように変わりました。
「全部書く」のではなく「必要なものを書く」。 そのためには、会議前にゴールを描いておくことが不可欠でした。
失敗3：AIが書いたソースコードを、根拠なく使用してしまった
何が起きたか
PJに入る前から、私にはソースコードを読めない・書けないという課題がありました。
その課題を抱えたままPJに臨んでしまい、ソースコードの解析から機能の実装まで、ほとんどをAIに丸投げしていました。
「とにかく動けばいい」「動けば何とかなる」と思い込み、動くコードをAIに書かせることに躍起になっていました。
その結果、できあがったのは保守性のない、その画面・その機能がただ動くだけのコードです。その問題に気づかないままマージリクエストを投げ、レビュー指摘の山を築いてしまいました。
2画面目以降は「このままではダメだ」と認識し、理解するためにドキュメントを読んだり、PJのBP（ビジネスパートナー）さんに質問したりしました。それでも分からず、刻一刻と納期が迫るだけの日々の中で、またAIに手を出す——その繰り返しでした。
最終的には、コーディングよりもレビュー修正の方が多く、BPさんに付きっきりで修正してもらうことで、なんとか開発が終了しました。
正直、この開発工程で自分が成長した部分はなかったと思います。それほどまでに、AIに頼り、AIの出力するままにコードを貼り付ける日々を過ごしてしまいました。
学んだこと：AIの返答は「根拠を持って精査する」
ここから得た学びは、分からないことをAIに投げたとしても、返ってきた内容は根拠を持って精査すべきだということです。
現代の開発業務において、AIを使わないというのは悪手だと思っています。しかし、AIの返答をそのまま貼り付けているだけでは、人間がやる意味も、私がそこにいる価値もありません。
Claude Codeのような質の高いAIが登場したとしても、対顧客に納品するものには、人間の目とレビューが必要です。
一番の失敗は、「AIを使う」のではなく「AIに使われる」ような作業をしてしまったことだと考えています。
「AIに使われる」状態と「AIを使いこなす」状態の違いを整理すると、次のようになります。
まとめ
今回は、私一人だけが炎上してしまったPJでの失敗と、そこから得た学びをまとめました。
3つの失敗を振り返ると、共通しているのは「確認・準備・精査というワンステップを飛ばして、いきなりアウトプットしてしまった」という点でした。
| # | 失敗したこと | 根本原因 | これからの行動 |
|---|---|---|---|
| 1 | 頭の中を、そのまま設計書に落とし込んだ | 実現可能性を検証しなかった | ヒアリング時点でフィジビリティを確認し、モックで検証してから設計する |
| 2 | すべての発言を追って記録しようとした | 会議のゴールを理解していなかった | 事前準備で決定事項・宿題・議論展開を把握し、必要な情報だけ記録する |
| 3 | AIのコードを根拠なく使用した | AIの出力を精査しなかった | AIの返答は根拠を持って精査し、人間のレビューで品質を担保する |
炎上は本当に辛い経験でしたが、こうして言語化してみると、いずれも一手間を惜しんだこと」が原因だったと気づきます。
同じ失敗を繰り返さないために、この記事を自分への戒めとして残しておきます。最後まで読んでいただき、ありがとうございました。