エンジニアとして客先に常駐していたころ、ふとした瞬間に「これ、何のために作ってるんだっけ」と思うことが何度もありました。

仕様書には、画面の項目とボタンの動きが細かく書いてある。その通りに実装すればテストは通るし、レビューも問題なく抜ける。でも、その機能が誰のどんな困りごとを解いているのか、私は知らないまま手を動かしていました。

気になって聞いてみても、はっきりした答えは返ってきません。隣の席のリーダーも知らない。リーダーが確認している元請けの担当者も、本当の発注元から又聞きで指示を受けているだけ。たどっていくと、「なぜ作るのか」を本当に知っている人まで、何階層も離れていました。

当時はそれが当たり前だと思っていました。今、会社をやる立場になって振り返ると、あのとき感じていた距離こそが、私が一番なくしたかったものだったと思います。

多重下請けで、私が一番きつかったこと

日本のIT業界の多重下請け構造は、もう何度も語られてきた話です。元請けがいて、一次請けがいて、二次請けがいて、その先に常駐するエンジニアがいる。図にすると縦に長い、あの構造です。

構造の話になると、たいてい中間マージンや契約の積み重なりに向かいます。それも大事な論点だとは思います。ただ、現場にいた私が一番きつかったのは、契約や条件の話よりも、「自分が何のために作っているか分からない」という状態そのものでした。

作るものの背景が分からない。使う人の顔が見えない。要望が変わった理由も、なぜこの仕様に落ち着いたのかも、説明されないまま「これで実装してください」とだけ降りてくる。

言われた通りに作れば、ちゃんと評価はされます。納期を守って、バグを出さなければ、現場での信頼も積み上がる。でも、そこに自分の判断が入る余地は、ほとんどありませんでした。決められたものを、決められた通りに作る。その役割からはみ出す機会が、構造的に少なかったのです。

「決める人」と「作る人」が、何階層も離れていく

多重下請けの現場で何が起きているのかを、私なりに整理するとこうなります。

意思決定をする人と、実際に手を動かす人が、何階層も離れてしまう。これに尽きると思っています。

発注元には「こういう課題があって、こう解きたい」という意図があります。ところが、その意図は契約の階層を一段下りるたびに、少しずつ削られていきます。一次請けに渡るときには「この機能を作る」に変わり、二次請けでは「この画面を実装する」になり、末端に届くころには「この項目をこう動かす」だけが残る。

背景や目的は、伝言ゲームの途中で落ちていきます。誰かに悪意があるわけではありません。各社が自分の請けた範囲を確実にこなそうとすると、伝える情報は自然と「やること」だけに絞られていく。なぜそれをやるのかは、それぞれの階層で「うちが知っていればいい」と止まってしまう。

結果として、一番下で作っている人ほど、「なぜこれを作るのか」から遠ざかります。手は動かしているのに、肝心の判断はどこか上の階層で済んでいる。指示が来た時点で、考える部分はもう終わっている。この感覚を、私は長いあいだ引きずっていました。

誤解してほしくないのは、これは誰か特定の会社が悪い、という話ではないことです。それぞれの会社は、自分の役割をまっとうしているだけです。元請けは元請けの責任を果たし、間に入る会社も決められた範囲をきちんとこなしている。一人ひとりは真面目に働いている。それでも、階層が重なるほど目的が薄まっていくのは、構造がそうさせているからです。だからこそ、個人の頑張りだけで抜け出すのは難しいのだと思います。

理由が見えないと、人は工夫をやめていく

「なぜ作るのか」が見えないことの何が問題なのか。

一番大きいのは、工夫が生まれなくなることだと思っています。

目的が分かっていれば、エンジニアは「だったら、こっちの作りのほうがいいのでは」と提案できます。仕様の矛盾に気づいて、手前で止めることもできる。実際に使う人を想像して、画面の細部を詰めることもできる。判断の材料が手元にあるからこそ、手を動かしながら頭も動く。

でも、目的が分からないと、できるのは「言われた通りに、正しく作る」ことだけになります。仕様書が間違っていても、その通りに作る。明らかに使いにくい導線でも、指示だからそのまま実装する。違和感に気づいても、確認するルートが遠すぎて、結局は飲み込む。

これを何年も続けていると、だんだん考えること自体をやめてしまいます。本人の能力の問題ではありません。考えても反映されない場所に長くいれば、考えないほうが消耗しない、と体が覚えていくからです。

私が現場で見てきた、伸び悩んでいるように見えるエンジニアの多くは、力がないわけではありませんでした。判断する経験を、構造の側から少しずつ奪われ続けてきただけだと思っています。逆に、同じ年数でもぐんと伸びる人は、たいてい目的に近い場所で仕事をしていました。

やっかいなのは、これが本人にもなかなか気づけないことです。毎日きちんと働いて、指示にも応えている。評価も悪くない。それなのに、何かが積み上がっていない感じだけが残る。原因が構造の側にあると、自分の努力が足りないせいだと思い込んでしまいがちです。私も当時、しばらくそう感じていました。

ただ、現場で得られるものもある

ここまで読むと、SESの現場はだめなことばかりだと言っているように聞こえるかもしれません。そういうつもりはありません。

客先の現場では、自分一人では出会えない規模のシステムに触れられます。金融や通信のように、止まると社会が困るものを支える緊張感も、現場でしか学べないものです。納期や品質に対する厳しさ、チームでの動き方、報告や相談のしかた。こうした力は、現場で揉まれて初めて身につきます。

私自身、現場で過ごした年月を後悔しているわけではありません。あそこで覚えたことが、今の仕事の土台になっています。

だから問題は、現場に入ること自体ではなく、入ったきり「なぜ作るのか」が見えない状態に置かれ続けることだと思っています。経験を積みながら、少しずつ目的に近づいていけるなら、現場は学びの宝庫です。逆に、何年いても指示の受け手のままなら、得られるものはどこかで頭打ちになります。

目的が見えた現場で、起きたこと

一度だけ、目的がきちんと共有された現場に入ったことがあります。

案件の初日に、発注元の担当者が時間を取って、「この機能を使うのはこういう人で、今こういうことに困っている」と話してくれました。普段の現場では省かれてしまう部分です。たったそれだけのことなのに、その後の進み方がまるで違いました。

仕様の表現で迷ったとき、「使う人はこういう状況だから、たぶんこっちのほうが分かりやすい」と、自分で判断できる。レビューで指摘を受けても、なぜそう直すのかが腹落ちする。気づいた違和感を、ためらわずに相談できる。手を動かしながら、ずっと頭が働いている感覚がありました。

このとき、はっきり分かったことがあります。エンジニアが力を出せるかどうかは、本人のスキルだけで決まるわけではない。「なぜ作るのか」が見えているかどうかで、同じ人でも出せるものが変わる。構造の話に聞こえるかもしれませんが、現場で起きているのは、こういう具体的な差です。

経営者になって、この距離を縮められないか考えた

会社を始めてから、この距離をどうにかできないかと、ずっと考えています。

正直に言うと、私たちもまだSESの現場が中心です。多重下請けの構造の中にいることに変わりはありません。構造を外から批判できるほど、きれいな立場にいるわけではない、というのは自覚しています。

それでも、自分の手が届く範囲でできることはあると思っています。

ひとつは、案件に入ってもらうときに、「何を作る現場で、その先に誰がいるのか」を、分かる範囲できちんと共有することです。商流のどのあたりにいて、どこまでが見えて、どこからが見えないのか。それを曖昧にせず、最初に話します。見えないものは見えないと正直に伝える。期待だけ持たせて現場に送り出すより、そのほうが本人も心の準備ができます。

もうひとつは、月に一度、現場から少し離れて話す時間をつくることです。今の案件で何を任されていて、何にもやもやしているのか。それを聞いて、次にどんな現場へ動くかを一緒に考える。現場の中だけにいると、自分がどこにいるのかは見えなくなります。意識して外から眺める時間が、構造の中で立ち位置を見失わないために要ると思っています。

派手な仕組みではありません。それでも、「自分は今どこで、何のために働いているのか」を本人が言葉にできるかどうかは、長く働くうえで大きく効いてくると感じています。言葉にできれば、次に何を学べばいいかも見えてくる。目的との距離は、少し意識するだけでも縮められると思っています。

「なぜ作るのか」が見える場所を、自分たちで作る

そしてもうひとつ、いま準備を進めているのが受託開発です。

SESで現場に入るのとは違って、受託は発注してくれた相手と直接やり取りします。何に困っていて、何を解きたいのか。それを自分たちで聞いて、設計から考える。「なぜ作るのか」が、ようやく自分の手元にある状態です。

これは、私がエンジニア時代にずっと欲しかったものでした。言われた通りに作るのではなく、理由から関わる。仕様の前段にある「そもそも何を解くか」に、自分の判断で踏み込める。完成したものを、使う人の反応まで含めて見届けられる。

立ち上げの途中なので、まだ整っていないことだらけです。技術の標準も、進め方も、これから一緒に決めていく段階です。裏を返せば、決め方そのものに関われるということでもあります。意思決定との距離が近い、というのは、こういう場面のことを指しているのだと思います。

もちろん、受託に移れば全部が解決する、という単純な話ではありません。直接やり取りするぶん、相手の事情に向き合う難しさも増えます。要望が固まっていないところから一緒に考えるのは、指示通りに作るより手間がかかる。それでも、その手間は「なぜ作るのか」と引き換えに引き受けるものだと思っています。理由が分かったうえで悩むのと、理由が分からないまま手を動かすのとでは、同じしんどさでも質がまるで違います。

創業して間もない会社なので、最初から用意された制度や安定を期待されると、応えきれない部分はあります。そこは先に正直に伝えておきたい。ただ、「自分が何を作っているか分からない」あの感覚から抜け出したい人にとっては、合う場所になりうると思っています。

最後に

多重下請けの構造そのものを、私たちがすぐに変えられるわけではありません。それは正直に認めます。

それでも、自分の手が届く範囲で、「なぜ作るのか」が見える現場を少しずつ増やしていきたい。エンジニア時代の自分が感じていた、あの遠さを、これから一緒に働く人にはなるべく感じてほしくない。そう思いながら、日々の案件と、受託の準備を進めています。

今このストーリーを読んでくれている人の中にも、あの「これ、何のために作ってるんだっけ」という感覚に、心当たりのある人がいるかもしれません。それは、あなたの力が足りないからではないと、私は思っています。

もし、「言われた通りに作る」ことに息苦しさを感じていて、理由から関わる開発に戻りたいと思っているなら、一度カジュアルにお話しできればうれしいです。すぐの転職を考えていなくても構いません。受託開発の立ち上げに、創業期から関わってくれる仲間を探しています。下の募集から、気軽にのぞいてみてください。