株式会社K.Platinum 清水洋太
「もし失敗したら、どうなるんですか」
面接で、ときどきこう聞かれます。給与や勤務時間は求人票に書けますが、この質問への答えは書けません。けれどエンジニアとして働くうえで、本当はいちばん知りたいことなのではないかと、私は思っています。
システム開発の現場では、うまくいかない日が必ず来ます。想定どおりに動かない。要件の解釈がずれていた。リリース直前に前提そのものが変わった。問題は、それが起きるかどうかではありません。起きたあとに、何が起こるかです。
この記事では、K.Platinumが「うまくいかなかった日」をどう扱っているかを、できるだけ具体的にお話しします。
「うまくいかない」は、来る前提で組み立てる
弊社のメイン事業はITコンサルティングです。お客様のビジネス課題に対して提案の段階から入り、業務整理から業務改善、システム化、そしてAI導入まで、一気通貫でご支援しています。
この「一気通貫」という言葉、響きは整っているのですが、実務はかなり泥くさいものです。
仕様書が完成した状態で受け取って、そのとおりに作る仕事ではありません。多くの場合、お客様自身もまだ言葉にできていない課題を、一緒に輪郭から描いていくところが出発点になります。現場の業務フローを整理してみたら、手元の資料に書かれた手順と、実際の運用がまったく違っていた。そんなことは珍しくありません。
つまり、途中で前提が変わるのは事故ではなく、この仕事の性質そのものです。
だから私たちは、「想定外が起きない計画」を立てることに時間を使いません。代わりに、「想定外に早く気づける進め方」に時間を使います。小さく作って早めに見ていただく。週の途中で認識をすり合わせる。迷ったら、作り込む前に確認する。
どれも地味です。派手な打ち手ではありません。ただ、ズレに気づくのが3日後か3週間後かで、やり直しのコストは何倍にも変わります。3日で気づけたズレは軌道修正で済み、3週間放置したズレは作り直しになる。この差を生むのは技術力よりも、進め方の設計だと思っています。
そして進め方をどれだけ工夫しても、うまくいかない瞬間はゼロにはなりません。だから次に効いてくるのが、そのときにチームがどう振る舞うかです。
報告が遅れるのは、性格の問題ではありません
トラブルが大きくなる原因は、トラブルそのものよりも「報告が遅れること」にある。これは、多くのエンジニアが経験的に知っていることだと思います。
では、なぜ遅れるのでしょうか。
たいていは、こう考えるからです。「もう少し粘れば、自分で直せるかもしれない」。その裏側にあるのは、技術的な判断というより「できないと思われたくない」という気持ちです。私自身にも覚えがあります。
ここを「勇気を出して早めに報告しよう」という精神論で解こうとすると、だいたい失敗します。言い出しやすさは、個人の性格や根性の問題ではなく、環境の設計の問題だからです。
K.Platinumでやっていることは、たとえばこんなことです。
働き方はフルフレックス（コアタイムなし）で、原則リモートです。相談は「その場に居合わせたときに声をかける」のではなく、テキストで非同期に投げるのが基本になります。話しかける隙をうかがう必要がないので、詰まった瞬間にそのまま書けます。
そのうえで、「解決した状態」ではなく「詰まっている状態」を共有していい、という前提をチームで揃えています。整理しきれていなくても、「ここでハマっていて、原因の見当がついていません」と書ける。この一行が出るまでの時間が短いチームは、驚くほど事故が小さく収まります。
入社直後はOJTで伴走します。最初の数週間で覚えてもらいたいのは、技術そのものよりも「これは聞いていいことなんだ」という感覚の範囲です。ここが曖昧なままだと、人は安全側に倒れて黙ってしまいます。
オンラインの勉強会やLT会を定期的に開いているのも、実は同じ文脈です。まだ整理しきれていない話を人前に出す機会が日常にあると、未完成のものを差し出すことへの心理的なハードルが下がっていきます。
「詰まっている状態」をそのまま出せる環境で力を発揮したい方は、エンジニアの募集要項もあわせてご覧ください。
原因は、人ではなく手順に置く
何かがうまくいかなかったとき、私たちが最初に確認するのは「誰がやったか」ではありません。「どの手順まで戻れば、これに気づけたか」です。
これは優しさの話ではなく、実利の話です。
原因を人に置くと、対策は「以後、気をつけます」になります。これは対策ではなく決意表明なので、しばらくすると同じことが起きます。しかも、次に同じ場所でつまずいた人は、前回の件を見ているので、さらに報告しづらくなります。悪循環です。
一方で原因を手順に置くと、対策の形が変わります。確認のタイミングを一つ増やす。レビューの観点に一行足す。テストのケースを追加する。どれも、次に別の人が同じ道を通ったときに効きます。個人の反省で終わらせず、チームの資産にできるかどうかの分かれ目です。
生成AIの使い方についても、考え方は同じです。弊社では下書きを作り、生成させ、レビューするという流れで生成AIを日常的に使っています。書くスピードが上がった分、相対的にレビューの比重が上がりました。
このとき大事にしているのは、「誰が書いたか」で扱いを変えないことです。AIが出力したものも、経験の長いメンバーが書いたものも、入社したばかりのメンバーが書いたものも、同じ観点で読みます。出どころで信頼度を変えると、レビューは形式的な儀式になってしまいます。
そして、つまずいた経緯と、そのとき何を根拠にどう判断したのかは、できるだけ記録に残します。結論だけを残しても再現できません。判断の材料まで残っていると、半年後にまったく別の案件で、同じ構造の問題に出会ったときに効いてきます。
判断する回数が多いほど、外さない感覚が育つ
ここまで読んで、「失敗に寛容な、ゆるい会社」という印象を持たれたかもしれません。実際は少し違います。
弊社は設立から2年ほどで20以上の開発プロジェクトに関わってきました。従業員は12名前後、平均年齢は27.5歳です。人数に対して扱う案件の幅が広いので、一人が担当する範囲は自然と広くなります。
しかも提案の段階から入る仕事なので、「この機能はなぜ必要なのか」を自分の言葉で説明する場面が、かなり早い時期に訪れます。言われたものを作るのではなく、何を作るべきかから関わる。裁量が大きいというのは、要するに判断する回数が多いということです。
判断の回数が多ければ、当然、外すこともあります。ここで外したことを責められる環境だと、人は判断を避けるようになり、指示を待つようになります。逆に、外したときに「どこで気づけたか」を一緒に見てもらえる環境なら、次の判断の精度が上がります。
20代でリーダーを任されるメンバーが多いのは、才能の差というより、この「判断して、外して、修正する」回数の差だと私は思っています。安全に失敗できる場所は、結果としていちばん速く伸びる場所でもあります。
まとめ
うまくいかない日は、必ず来ます。それをゼロにする方法を、私たちは知りません。
その代わりに、ズレに早く気づける進め方を選ぶこと、詰まっている状態をそのまま出せる環境を用意すること、原因を人ではなく手順に置くこと。この3つに、地味ですがこだわり続けています。
「失敗したらどうなるんですか」という質問に、私はこう答えたいと思っています。一緒に、どこで気づけたかを探します。そして次に同じ道を通る人のために、手順を一つ足します。それだけです。
自分の判断で仕事を進めたい方、そして詰まったときに一人で抱え込まずに済む場所を探している方にとって、K.Platinumは相性の良い環境だと思います。少しでも気になった方は、ぜひ一度お話ししましょう。
清水洋太（しみず・ようた）
株式会社K.Platinum所属。エンジニアが力を発揮できる環境づくりを大切にしている。
K.Platinumでは一緒に働くエンジニアを募集しています。「実力で正当に評価される環境」に興味がある方は、ぜひ採用ページをご覧ください。