納品されたシステムを開いた瞬間、担当者は言葉を失った。ログイン画面でパスワードを間違えても何のエラーメッセージも出ない。会員登録フォームに同じメールアドレスを二度入力すると、データベースの中に同じ顧客が二人分登録される。注文確定ボタンを二回連続で押すと、注文が二重に処理される。どれも公開前に誰か一人が画面を触っていれば、五分で気づけたはずの不具合だった。
この会社の担当者が後から聞いた話はさらに重かった。プロジェクトを受注した開発会社は、要件定義から実装までのすべてを、入社二年目の一人のエンジニアに任せていた。納期が迫る中、そのエンジニアが書いたコードを他の誰かが確認する工程は、契約書のどこにも、社内のどの会議体にも存在しなかった。担当者は専門用語が並ぶ見積書と、綺麗に整えられた進捗報告のスライドだけを信じて、開発の中身そのものには一度も踏み込んでいなかったのだ。
この話は特別な事故ではない。中小企業がシステム開発を発注するとき、最も見えにくいリスクは価格でも納期でもなく、成果物が世に出る前に誰かの目でちゃんと確認されているかどうかという、地味で見落とされがちな工程にある。そしてこの工程は、コードが読めない発注担当者であっても、質問の仕方さえ知っていれば十分に確認できるものだ。壁の向こう側で何が起きているか分からないまま任せきりにするのではなく、越境して確認しにいく担当者を、この記事は応援したい。
コードレビューとは何か、専門用語なしで説明する
コードレビューという言葉を聞いたことがある経営者は多いだろう。だが実態を尋ねると、正確に説明できる人は驚くほど少ない。難しい話ではない。一人のエンジニアが書いたプログラムを、別のエンジニアが公開前に読んで確認する仕組み、それだけのことだ。
例えるなら、経理担当者が作った決算書を、そのまま外部に出す会社は存在しない。必ず上司や別の担当者がダブルチェックをして、数字の整合性や記載漏れを確認してから提出する。コードレビューはこれとまったく同じ発想だ。書いた本人には見えない思い込みや見落としが、必ず一定数存在する。だからこそ、書いた人とは違う視点を持つ第三者が、公開前に目を通す。この当たり前の仕組みが、ソフトウェア開発の世界では驚くほど省略されがちだ。
なぜ省略されるのか。理由は単純で、レビューには時間がかかり、見た目の進捗には表れないからだ。納期に追われる現場では、動くものを早く出すことが優先され、確認の工程が真っ先に削られる。発注する側から見れば、レビューをしてもしなくても、納品されるファイルの数も画面の見た目も変わらない。だからこそ、この工程の有無は、価格や見積書の項目には決して出てこない。見えない部分にこそ、品質の差が集約されている。
コードの中身が読めなくても、体制は確認できる理由
ここで多くの発注担当者が誤解していることがある。品質を確認するために、プログラミング言語を学ぶ必要はない。確認すべきは書かれたコードの中身ではなく、その中身を誰がどう確認しているかという体制そのものだからだ。
これは建築に例えるとわかりやすい。施主が構造計算書の数式を読み解けなくても、第三者機関による構造検査が行われているか、施工中に現場監督以外の検査員が入っているかは確認できる。建築確認申請という制度があり、設計者以外の目が必ず入る仕組みが法律で定められているからこそ、施主は安心して発注できる。ソフトウェア開発には建築確認申請にあたる法的な強制力はない。だからこそ、発注する側が自らその仕組みの有無を尋ねる必要がある。
体制を確認するということは、次の三つを尋ねるということだ。一つ目は、誰が書いたコードを誰が確認しているか。二つ目は、確認する人は書いた本人と違う人物か。三つ目は、確認した記録がその都度残っているか。この三つさえ押さえれば、専門知識がなくても品質管理の実態にかなり近づける。逆に言えば、この三つに明確に答えられない開発会社は、体制そのものが存在しない可能性が高い。
非エンジニアでも聞ける、具体的な質問リスト
実際の商談や契約前の打ち合わせで、次のような質問をそのまま投げかけてみてほしい。回答の内容だけでなく、即答できるかどうか、資料をその場で見せられるかどうかも重要な判断材料になる。
- このプロジェクトは何人体制で、実装担当と確認担当は別の人ですか
- 一人のエンジニアがコードを書いた後、公開前に別の人がレビューする工程はありますか。それは口頭確認ですか、それとも記録が残る仕組みですか
- レビューで指摘が出た場合、修正されたことを誰がどう確認していますか
- テストは自動化されていますか。それとも毎回人が手作業で画面を確認していますか
- もしそのエンジニアが急に休んだり退職したりしても、他の人が引き継いでコードを理解できる状態になっていますか
- 過去にレビュー体制があったことで防げた不具合の具体例を教えてください
- 納品前の最終確認は誰が、どのタイミングで行いますか
- コードの変更履歴は記録されていて、後から誰がいつ何を直したか追跡できますか
これらの質問に対して、担当者名や具体的な仕組みの名前がすらすらと出てくる会社は、日常的にこの工程を回している証拠だ。逆に「基本的には信頼して任せています」「うちのエンジニアは優秀なので」といった、人柄への信頼だけで答えようとする会社には注意が必要だ。優秀さと、確認の仕組みがあることは、まったく別の話だからだ。
特に五番目の質問は重要だ。属人化していないかどうかを問う質問であり、これに明確な答えが返ってこない場合、その担当者が抜けた瞬間にプロジェクトが止まるリスクを抱えていることになる。中小企業の発注担当者が最も避けたいのは、まさにこの状況だ。
品質管理がしっかりしている開発会社の見分け方
質問への回答以外にも、いくつかの兆候から品質管理の実態を推し量ることができる。一つは、見積書や提案書に「レビュー工数」や「テスト工数」が独立した項目として明記されているかどうかだ。これらが実装工数にどんぶり勘定で含まれている会社よりも、別立てで見積もりに載せてくる会社の方が、日頃からこの工程を当たり前のものとして扱っている可能性が高い。
もう一つは、進捗報告の中身だ。「順調です」「問題なく進んでいます」という言葉だけの報告に終始する会社よりも、「先週はレビューで三件の指摘が出て、うち二件を修正済みです」といった具体的な数字や事実を交えて報告してくる会社の方が、実際に工程が動いている証拠を握っている。数字が出てくるということは、記録している仕組みがあるということだ。
さらに、複数人での開発体制を組んでいる会社は、構造的にレビューを組み込みやすい。逆に「弊社の看板エンジニアにお任せください」という一人の技術力を前面に押し出す説明を受けた場合、その人がどれだけ優秀であっても、確認の仕組みがあるかどうかは別途必ず尋ねるべきだ。優れた個人の技術と、組織としての品質管理体制は、両立していることもあれば、片方しか存在しないこともある。
壁を越えて働く人たちの現場では、一人の力に頼りきることの危うさを、誰よりも本人たちがよく知っている。だからこそ、信頼できる開発会社ほど、自分たちの体制を包み隠さず語ってくれる。そこに誇りを持っている会社は、聞かれる前から自ら説明を始めることさえある。
よくある失敗パターン
実際に発注担当者から聞こえてくる失敗の多くは、いくつかの典型的なパターンに収まる。
一つ目は、冒頭で紹介したような、一人の担当者にすべてを丸投げされていたケースだ。契約時には「弊社のエンジニアチームが対応します」と説明されていたにもかかわらず、実際には一人が要件定義から実装、テストまでを一貫して担当し、誰の確認も入らないまま納品されていた。担当者が体調を崩した数週間、プロジェクトはまったく身動きが取れなくなった例もある。
二つ目は、レビューの工程自体は存在するものの、形だけで終わっているケースだ。レビュー担当者がコードに目を通してはいるものの、忙しさを理由に「特に問題ありません」という一言だけで承認してしまい、実質的なチェックになっていない。この場合、外形上はレビュー体制ありと説明されるため、発注担当者が質問しても「レビューはしています」という回答が返ってきてしまう。だからこそ、指摘の具体例や修正の記録まで踏み込んで尋ねる必要がある。
三つ目は、テストがすべて手作業に依存しているケースだ。機能を追加するたびに、以前は正常に動いていた別の機能が壊れてしまう、いわゆる想定外の不具合が繰り返し発生する。自動化されたテストの仕組みがあれば、変更のたびに機械的に確認できる部分を、毎回人の目と勘に頼ってしまっているため、確認漏れが起きやすい。
四つ目は、発注担当者自身が契約時にこれらを確認せず、トラブルが起きてから初めて体制を尋ねるケースだ。このタイミングでは既に手遅れであることが多い。品質管理の体制を確認するのは、契約前の商談の場でこそ意味を持つ。
まとめ
システムの中身を判断できないという不安は、中小企業の発注担当者にとって、決して恥ずかしいことでも特殊なことでもない。専門領域の壁を越えて、自分の会社の未来を託す相手を見極めようとする姿勢そのものが、既に十分な仕事だ。
大切なのは、コードを読めるようになることではない。誰が書き、誰が確認し、その記録がどう残っているのかを尋ねる勇気を持つことだ。この記事で紹介した質問リストを、次の商談でそのまま使ってほしい。即答できる会社、具体的な数字で語れる会社、包み隠さず体制を説明してくれる会社こそが、これから長く付き合っていける相手になる。
納品されたシステムを開いたときに言葉を失うのではなく、安心して次の一歩を踏み出せるように。壁の向こうを見えないままにしないための質問は、もう手の中にある。