株式会社K.Platinum 清水洋太
新しいシステムが動き出す日、開発チームはどんな様子だと思いますか。歓声が上がって、拍手が起きて、写真を撮って──そんな場面を想像されるかもしれません。
でも実際のリリース当日は、驚くほど静かです。全員が黙って画面を見ている。何も起きないことを、ただ確認し続ける時間が流れます。
そして本当のことがわかり始めるのは、その静けさが明けた翌日からです。設計書のどこにも書いていない出来事が、そこから次々と現れます。
求人票でよく見かける「上流から下流まで一気通貫」という一行は、現場では何を意味するのか。この記事では、弊社のITコンサルティングでいちばん語られない「リリースから先」の数日間を、実際に起きたことベースで書きます。
リリースはゴールではなく、折り返し地点だった
弊社のメイン事業は、ITコンサルティングです。顧客のビジネス課題に対して提案活動から入り、課題の整理から業務改善、システム開発、リリースまでを一気通貫で支援しています。
この「一気通貫」という言葉、求人票でもよく見かけるようになりました。ただ、実際にどこからどこまでを指すのかは、会社によってずいぶん違います。要件定義から結合テストまでを一気通貫と呼ぶこともあれば、企画から運用までを指すこともある。
私たちの場合は、前も後ろも長いほうだと思います。前は「そもそも、このシステムは作るべきなのか」という問いから始まります。そして後ろは、リリースの日を越えて、そのシステムの使われ方が落ち着くところまで続きます。
エンジニアとして働き始めた頃、私はリリースをゴールだと思っていました。仕様どおりに動いて、テストが全部通って、本番環境に乗った。おつかれさまでした、と。
けれど、いくつかのプロジェクトをリリースの先まで見届けるうちに、順番が逆だと気づきました。リリースは、そのシステムが初めて「現実」と接触する日です。それまで私たちが見ていたのは、設計書と検証環境の中の世界でしかありません。実際の業務がその上を流れ始めた瞬間から、ようやく本当のことがわかり始めます。
だから弊社では、リリースを納品の締切ではなく、折り返し地点として扱っています。
リリース当日と、そのあとの数日に実際に起きていること
切替そのものは、たいてい前日の夜か当日の早朝に終えています。ですから当日の朝は、現場の担当者が最初の一件を登録するのを、チャットの向こうで静かに待つ時間になります。誰も余計なことを言いません。「登録できました」の一言が届いて、ようやく全員が息を吐く。
そこから数日で起きることは、だいたい設計書には書かれていません。たとえば、こんなことです。
- こちらが想定した画面の順番とは違う順番で、現場の人が入力していく
- 検索条件を、設計時に見込んでいた組み合わせでは使わない
- アクセスが集中する時間帯が、事前のヒアリングと少しずれている
- 「この項目、空欄のまま進めていいですか」という質問が、同じ日に何件も届く
最後の質問は、特に大事な合図です。同じ問いが複数の人から届くということは、その項目の意味が画面から伝わっていないということ。バグではありません。テストも通っています。でも、直したほうがいい。
こういう一つひとつは、検証環境では見つかりません。実際の業務が上を流れて、初めて姿を現します。だからこの時期のエンジニアは、コードを書く時間より、ログと問い合わせを読んでいる時間のほうが長くなります。
そして不思議なもので、この数日がいちばん記憶に残ります。何ヶ月もかけて設計したものが、自分の知らない誰かの一日の中に組み込まれていく。その手ざわりは、テストがすべて緑になった瞬間とは、まったく別の種類の実感です。

この「リリースのあと」まで含めて、一つの仕事として担当したい方へ。K.Platinumでは提案から運用後の観察までを一人のエンジニアが通しで見ます。→ エンジニア募集中! 詳しい条件を見る
30分の手作業を消したら、10分の確認作業が生まれた
リリース後に集まってくる情報は、そのまま次の仕事の材料になります。
弊社が提供している価値を一言でいうと、「業務整理 → 業務改善 → システム化 → AI導入」を、業務・IT・マネジメントの三位一体で一貫して見ることです。一般的には、業務コンサルは戦略提案まで、システム会社は開発から、と役割が分かれがちな領域を、分けずに引き受けています。
そしてこの四つは、直線ではなく円としてつながっています。システム化した結果を観察すると、次に整理すべき業務が浮かび上がってくるからです。
たとえば、毎朝30分かけて手作業でデータを整えていた作業をシステム化したとします。その30分は消えます。ところがリリース後に現場を見ると、今度は出力結果を目視で確認する新しい10分が生まれていた、ということが起こります。作業が減ったのではなく、形を変えて残っていた。
ここで「では、その確認作業は何を見ているのか」と一段掘れると、次の改善提案になります。ルールで判定できるならロジックにすればいい。人の判断が要るなら、判断しやすい見せ方に変えればいい。曖昧な基準を大量に捌いているなら、AIの出番かもしれません。
弊社は生成AIを、顧客への提案だけでなく自分たちの開発プロセスの中でも使っています。設計ドキュメントの作成、コードの生成、コードレビューをそれぞれ別のAIに役割分担させる三段階のワークフローで、従来と比べて生産性は大きく変わりました。自分たちで日常的に使い倒しているので、顧客に対しても「ここは任せられます」「ここは人が判断すべきです」と、実感を持って線を引けます。
提案から入っている強みが、ここで効いてきます。最初のヒアリングで「本当は何に困っていたのか」を聞いているので、リリース後に観察したことを、次の課題として言語化しやすい。開発工程だけを切り出して請け負っていたら、この会話はそもそも生まれません。
「後半戦」を何度も経験したエンジニアに、何が残るか
弊社は設立から2年ほどで、20件を超える開発プロジェクトに関わってきました。金融、製造、流通といった領域で、AWSやAzureの上にJavaで作ることが多く、認証基盤のように利用者が百万人規模になるものもあれば、数十人が毎日使う業務システムもあります。
社員は十数名です。人数が多くないぶん、一人が担当する範囲は自然と広くなります。提案の場に同席し、業務の話を聞き、設計して、実装して、リリースに立ち会い、その後の反応まで見届ける。分業が進んだ大規模な現場では、このうちの一区間だけを数年担当することも珍しくありません。どちらが良い悪いではなく、身につくものが違います。
自分が作ったものが、誰に、どんな順番で、どんな顔で使われたのか。それを最後まで見た経験は、次の設計の質を確実に変えます。「この項目、たぶん空欄のまま出す人がいますよ」と設計段階で言えるようになる。それは知識ではなく、後半戦を何度も経験した人だけが持てる感覚だと思っています。
働き方の面では、フルフレックス(コアタイムなし)で、原則リモート、完全週休2日で年間休日は123日、残業もほとんどありません。リリース直後の張り詰めた数日も、生活のリズムを崩さずに越えられるようにしています。緊張感が必要な時期があるからこそ、それ以外の時間は静かに整えておく。そういう考え方です。
作って終わりにしたくない人へ
リリースの日は、これからもきっと静かなままだと思います。歓声も拍手もなく、「登録できました」の一言に全員がほっとする、あの数分。
でも私たちにとって、そこは終わりではありません。作ったものが現実と混ざり始めて、次に何を直すべきかが見えてくる、いちばん学びの多い時間の入口です。提案から入り、リリースの先まで見届ける。その全部を一つの仕事として引き受けられるのが、弊社で働く面白さだと思っています。
作って終わりではなく、使われ方まで見届けたい。設計書の外側で何が起きているのかを知りたい。そんな方には、きっと合う環境です。ご興味を持っていただけたら、まずはお気軽にお話しできればうれしいです。
清水洋太(しみず・ようた)
株式会社K.Platinum所属。エンジニアが力を発揮できる環境づくりを大切にしている。
K.Platinumでは一緒に働くエンジニアを募集しています。「実力で正当に評価される環境」に興味がある方は、ぜひ採用ページをご覧ください。

