ブログ一覧へ戻る

業務改善

開発日記

システム開発に「外の人」が入ると、うまくいくことがある

ぴーす君

2026/9/18

システム開発というと、「システムを作る人」と「システムを使う人」が話し合って、必要なものを決めていく。

そんなイメージがあるかもしれません。

もちろん、それでうまくいくこともあります。

でも、実際には「社内で意見がまとまっていない」ということも、意外とあります。

今回は、実際にあったやり取りをご紹介します。

「中断」は使わない、と聞いていた

あるシステムの開発で、「ステータス」項目にある、各ステータスの内容を確認することになりました。

打ち合わせのときにそのことを伝え、回答はメールで他の質問と一緒に教えてほしいとお願いしました。

数日後、他の質問への回答とともに、ステータスについても回答が届きました。

ステータスのひとつに「中断」というものがあったのですが、

「中断は今後使わなくてよい」

とのことでした。

回答書は担当者2名で作成した形跡があったため、私は「社内で検討した結果」として受け取っていました。

ところが、打ち合わせで最終確認をしたときのことです。

担当者のひとりから、こんな質問が出ました。

「中断を使わないとして、君はどうやってそのことを表現する気だ?」

……え?

寝耳に水でした。

「中断は使わない」と聞いていたので、私はその前提で考えていたからです。

実は、社内でも認識が違っていた

話を整理していくと、どうやら、

「中断はレアケースだから、わざわざステータスとして持たなくてもいい」

という考えと、

「レアケースであっても、中断という状態が発生するなら、それをシステム上どう表現するのか考える必要がある」

という考えがあったようです。

最終的には、

「レアケースであっても、発生するのであれば考慮しておこう」

ということで話がまとまりました。

ここで私が面白いと思ったのは、「システムの仕様が難しかった」ということではありません。

社内で回答をまとめたつもりでも、必ずしも全員の認識が同じとは限らない。

ということです。

社内の人同士だからこそ、話しにくいこともある

今回の担当者のお二人は、同じ会社の方です。

ただ、仕事をしている場所は異なり、建物も違います。

質問への回答も、まず実務を担当している方が回答を書き、それをもう一人の方が確認・追記する、といった形で進めていたようでした。

こうしたやり方自体は、決して珍しいことではありません。

できれば、社内でも別途打ち合わせをして欲しかった、という思いはあります。

ただ、打ち合わせをすれば、それですべてがうまくいくわけでもありません。

会議を設定して、参加者から意見を引き出し、話を整理して、最終的に結論まで持っていく。

こうした「ファシリテーション」は、誰でも簡単にできるものではないと思います。

まして、社内の人同士であれば、それぞれの立場や関係性があります。

話しているうちに熱が入ってしまうこともあるでしょう。

その場では結論が出ても、後になって「あのとき、あんな言い方をされた」といった別の問題につながってしまうこともあります。

だからこそ、社内の人だけで話し合うのではなく、第三者が間に入る意味があるのだと思います。

そこで「外の人」が入る

外部のシステム開発者は、その会社の社員ではありません。

社内の立場も、人間関係もありません。

だからこそ、

「では、実際に中断が発生した場合は、どういう状態にしますか?」

と確認することができます。

どちらの意見が正しいかを決める必要もありません。

「システムとしては、どうする必要がありますか?」

という視点で確認していけばいいのです。

今回も、私が「中断を残しましょう」と判断したわけではありません。

「中断を使わないのであれば、その状態はどう表現するのか?」

と確認したことで、担当者の方から別の視点が出てきました。

そして、そこで改めて話を整理することができました。

外部の人間が「潤滑剤」になることもある

システム開発を外部に依頼するメリットは、プログラムを作ってもらえることだけではありません。

社内の人だけでは話しにくいことや、曖昧なままになっていることを、第三者が質問することで整理できる場合があります。

「どちらが正しいですか?」

ではなく、

「実際の業務では、どうなっていますか?」

「その状態になった場合、システムではどうしますか?」

と聞いていく。

そうすることで、社内ではあえて触れずに済ませていた部分が見えてくることがあります。

もちろん、第三者が入れば必ず話がまとまるわけではありません。

それでも、社内の人同士が直接ぶつからなくても済むように、間に入って話を整理することはできます。

システム開発者は、プログラムを書く人です。

でも、それだけではありません。

ときには、社内の意見を整理する「潤滑剤」のような役割をすることもある。

今回の出来事を通して、そんなことを改めて感じました。