【プログラマー編】設計書通りに作ったのに決まっていないことばかり。現場判断をゼロにする回避策とは

はじめに

「エンジニア」とひと口に言っても、ソフトウェア、フロントエンド、サーバーなど、その役割によって現場で直面するトラブルはさまざまです。 本連載では、PMO(Project Management Office)として多くの現場を経験してきた甲州が、それぞれのエンジニアが抱える課題の回避策を深掘りしていきます。

第3回目にスポットを当てるのは、開発工程の最下流でコードを紡ぐプログラマーです。この現場につきもののトラブルと言えば「仕様の穴」による手戻りと責任の押し付けあい。

最初は完璧に見えた設計書を手にスタートしたはずの実装が、いざプログラミングを始めると「200歳の申請者がいた場合は?」「クーポンとキャンペーンを併用したら料金がマイナスになるのでは?」などと、設計書に書かれていない例外パターンが次々と露呈し、現場は混乱。最終的には「上流の詰めが甘いせいでしょう」「いやいや、普通そんなの起こり得ないでしょ、現場で何とかしてくださいよ」と責任転嫁が始まってしまう…。

そんなとき、現場の責任感から「仕方ない」「どうするかは自分たちで考えなくては…」というプログラマーもいるかもしれませんが、実はこうしたトラブルを回避する鍵はプログラマー自身の意識や行動に隠されているのです。

仕様の穴を防ぎ、プログラマーが現場でやむを得ず行っている判断を正しく上流へ戻すにはどうすれば良いいのか。一緒にひもといていきましょう。

プログラマーの立ち位置(役割)と
プロジェクト体制の問題が「仕様の穴」を引き起こす

現場で「仕様の穴」が発生してしまう問題には、原因が2つあります。

プログラマーは「下りてきた設計書」から作業するという構造

1つ目は、開発工程の最下流というプログラマーの立ち位置(役割)です。

上流では、プロジェクトマネージャーやソフトウェアエンジニア、アプリケーションエンジニアが仕様を決めて設計書を作っており、プログラマーは、その設計書が下りてきてから作業を始めることになります。

そのため、プログラマーは「この通りに作ってください」と指示されるだけで、仕様書の作成工程やお客様との会話に入ることはほとんどありません。開発工程としてはごく一般的な流れですが、この作業構造によって「設計書に書いていない条件」が発生しやすく、プログラマー自身で判断せざるを得なくなる事態を引き起こしがちなのです。

複雑な条件が未整理のまま実装担当者へ移すという
プロジェクト体制の問題

2つ目は、仕様を決める際に要件定義や設計担当者側で複雑な条件を論理的に整理できていないまま、プログラマーに渡ってしまうことです。給付金申請システムを開発する場合で考えてみましょう。

「世帯収入がいくらで、子どもが何人で、年齢が何歳で…」といった条件は無数にあります。さらに、それらの条件を組み合わせて考えていくと、中には「現実に存在しない条件」が出てくることもあるのです。例えば、冒頭で例に挙げた「200歳の申請者」は現実に存在しませんが、プログラム上は「65歳以上」という条件を書くと200歳も300歳も該当するわけです(実際はこのような設計漏れは起きませんが、分かりやすい例として取り上げています)。

料金計算のシステムなども同様です。「ライト・スタンダード・プレミアムという3つのプラン」「クーポンコードやキャンペーンコード」「利用額によって手数料が無料になる」など条件が増えていくと、組み合わせによっては料金がマイナスになってしまうこともあります。そうした「例外」をどう処理するかまで仕様決定時にベンダー側できちんと整理できていないままプログラマーに渡ると、実装時につまずいてしまうのです。

プログラマーからすれば「少し考えれば分かるだろう」ということかもしれませんが、要件定義や設計担当者側からすれば「そんな問題にぶつかったことがないから、考えもしなかった」というのが本音でしょう。しかし、そのままプログラムを作ろうとすれば、当然その見落とされた「穴」が露呈してきてしまうのです。

【トラブル解決策】プログラマーが事前・事後に打つべき具体的なアクション

それでは、トラブルを防ぐ、あるいはスムーズに解決するために、プログラマーはどのような意識や行動をすれば良いのでしょうか。

事前対策1：AIと人の目で仕様の穴を洗い出す

トラブル防止策として最も効果的なのは、プログラマーが「仕様には何らかの穴がある」という意識のもと、着手前にAIを活用して仕様の穴を洗い出すことです。

具体的には、設計書が下りてきたら、すぐにプログラムを書き始めるのではなく、まずAIに確認します。「この仕様で考えられていない条件のパターンをすべて抜き出してください」などとプロンプトを投げると、AIが候補を出してくれます。ただし、AIの回答が正しいかどうかの判断はプログラマー自身が行わなくてはなりません。場合によっては自分で仕様を整理し直すことも必要でしょう。

仕様書と照らし合わせながら「これは例外処理」「これは共通処理」と振り分けていきます。文章でバラバラに書かれている条件があれば「ベースの3つのプランがあって、あとはオプションが並列に並ぶだけ」というようにシンプルに整理できないかも考えます。この整理ができると、プログラムもよりシンプルになります。より噛み砕いて表現すると、計算をするときに足し算を「3+3+3+3…」のように延々と書くのではなく「3×10」という掛け算を使って表現できるようになるのです。

足し算と掛け算で考えると「そんなこと実際にはないでしょ?」と思うかもしれませんが、プログラムコードを書いたことがある人、あるいは他の人のプログラムコードを見たことがある人であれば理解できると思います。

私自身、ループ処理をすれば良いところを、ループの回数分だけプログラムコードを何行も書いているプログラムを見て愕然とした経験が幾度となくあります。同じ動作をするプログラムでも、無駄な処理が多いプログラムコードと最適化されたプログラムコードでは後者のほうがテストもシンプルになり、メンテナンスも容易になり、良いことばかりです。

現場によってはセキュリティや環境制限でAIを使えない、ということもあるかもしれません。そんなときは、先輩や周りのエンジニアに遠慮なく相談するのが一番早いです。ペアワークや相談をしながら、整理していきましょう。そして、現場環境でAIを使えないとしても、自分個人のAI環境であれば論理的に整理するための整理術やまとめ方などの知識を得るような学習はできるはずです。

仕様書そのものや実際の現場の情報をAIに投げるのではなく、問題や仕様を抽象化(固有名詞を取り除き、一般的なパターンにするなど)してAIに聞き、仕様の穴を見つけるトレーニングをすることは個人でもAIを活用してできることです。

事後対策1：実装中に「穴」が見つかったら仮コードでまとめて確認

とはいえ、実装中には必ずと言っていいほど「仕様書には書いていない条件」が見つかるものです。それらを都度確認していたら、作業が一向に進みません。そこで使うのが「仮コード」です。条件が決まっていない部分は、とりあえず一般的なエラー処理で仮プログラムを作っておきましょう。仮コードでもシステムは動きますが「ここは仮で作った」という記録はきちんと残しておきます。

そして、仮の部分がある程度蓄積された段階でまとめて上流に確認します。このとき重要なのが「確認の仕方」です。「ここが決まっていないので決めてください」と端的に、しかも曖昧な確認は典型的な「NG」の確認方法です。そもそも上流の人たちにはなぜ仮になっているかも分からないため「何を決めれば良いのですか?」と困ってしまうからです。具体的に決めてほしいあなたが曖昧な質問の仕方をすれば、曖昧な回答しか返ってきません。

それでは、どのように確認するのが正解かというと、選択肢を具体的に提示し、推奨案を示す形で聞きます。

これが、プログラマーとして「判断の責任を上流に戻す」正しい方法です。もちろん、作業をしていて複数箇所の確認項目が出てきた場合はチケット管理システムやスプレッドシートを使って仕様確認を行い、設計書に反映するまでの管理ができていれば理想的です。

プロとして押さえたいチェックリスト

プログラマーとして、現場の責任を果たすためのチェックポイントをまとめました。実装工程での「迷い」をなくし、上流工程と対等に渡り合うための指標として活用してください。

• 設計書が下りてきたら、着手前にAIで仕様の穴を確認したか
• 自分で仕様を論理的に整理し、共通処理と例外を振り分けたか
• 仮コードで作業を進め、確認事項をリスト化したか
• 上流への確認は「どうしますか?」ではなく、選択肢を提示したか(複数の推奨または前提条件によって推奨が変わる場合はメリット・デメリットを追加したか)
• AIが出した答えを理解できる基礎知識を持っているか

これらを押さえていれば、プログラマーとしての責任は果たせていると考えて良いでしょう。

おわりに

プログラマーは開発工程の最下流にいます。 だからこそ仕様の穴が最も見える立場であり、仕様の穴によって負担を受けやすい立場でもあります。責任感の強いプログラマーはその穴を「自分で判断して埋めなければ仕方ない」と背負ってしまいがちですが、本来、その判断は上流工程で行うべきものです。

少し手間はかかりますが、仕様書に書かれていない条件を整理して、判断の責任を正しいポストへ戻す。その際、相手が理解しやすいよう「この条件ならこう、この条件ならこうなります。推奨はこれです」といった建設的なコミュニケーションを取る。

こうしたアクションによって、仕様の穴によるトラブルや判断負担を抑えることができます。そして、実はこうした行動はプロジェクトにおけるPMOの動きとも重なります。「いつも仕様の穴のトラブルに悩まされている」というプログラマーは、ぜひ今回紹介したようなPMO的視点を持ってみてください。

上流からの指示を受けて設計書通りに作るだけがプログラマーの仕事ではありません。もっと視座を上げ、上流に提案できるプログラマーになれば、あなたの能力はもっと評価され仕事の幅も広がることでしょう。