株式会社K.Platinum 清水洋太
「要件定義書はありますか」と聞いて、「まだないんです」と返ってくる打ち合わせがあります。
正確に言うと、要件がないわけではありません。お客さまの頭のなかには「この作業がしんどい」「月末になると誰かが必ず残業している」という実感がある。ただ、それが仕様書の形になっていないだけです。
K.Platinumのエンジニアは、この状態の打ち合わせから入ります。設計書どおりに作るのではなく、何を作るべきかがまだ決まっていない場所に立つ。設立から二年で二十件を超える開発プロジェクトに関わってきましたが、その多くがこの入り方でした。
上流工程に関わりたい、要件定義から携わりたい──そう考えている方に、その「上流」が実際にはどんな作業なのかを、今日は実際の進み方に沿って書いてみます。
最初の数週間、私たちはコードを書いていません
最初にやるのは、業務を書き出すことです。誰が、いつ、何を使って、どんな順番で仕事をしているのか。画面の設計を考える前に、まずその一枚を作ります。
現場に入ると、一つの業務がきれいに一本の線で流れていることは、ほとんどありません。システムに入力したあと、担当の方がご自身のExcelに転記して、それをメールで送り、受け取った側が別の台帳に写す。途中に紙の帳票が一枚だけ挟まっていて、その紙が回ってこないと次の工程が動かない、ということもあります。
こうした流れは、誰か一人に聞いても全体像が出てきません。前の工程の方は自分が渡したあとを知らないし、後ろの工程の方は自分に届く前を知らない。だから関係する部署の方に一人ずつ話を聞いて、聞いたそばから図にして、「この理解で合っていますか」と確かめながら進めます。
この作業をしていると、お客さま自身が「あれ、この転記って要るんでしたっけ」と言い出す瞬間があります。私は、ここがプロジェクトのなかで一番価値の出ている場面だと思っています。まだ一行もコードを書いていないのに、業務が一つ減る可能性が見えているからです。
そして、これをエンジニアがやることに意味があります。業務の話を聞きながら、頭のなかでは「ここは自動化できる」「ここはシステムにするより運用を変えたほうが早い」という仕分けが同時に進んでいる。作れるかどうかを知っている人が聞き役をやると、提案が絵に描いた餅になりにくい。逆に言えば、聞く会社と作る会社が分かれていると、この仕分けは誰もやらないまま先に進んでしまいます。
「この作業、なぜ必要なんですか」と聞ける立場にいること
弊社の支援は、業務整理 → 業務改善 → システム化 → AI導入、という順番で進みます。この順番そのものが、私たちの提供している価値だと思っています。
世の中の分担でいうと、業務コンサルティングは戦略や提案までを担い、システム開発会社は決まった仕様を受け取って作る。あいだに一本、線が引かれています。K.Platinumはその線をまたいでいるので、「なぜこの作業が必要なのか」と聞く役と、「ではこう作りましょう」と決める役が、同じチームのなかにいます。
聞ける立場にいると、作らない判断ができます。たとえば、承認のステップが三段階あるという話を聞いたとき、「三段階ぶんの承認画面を作る」のは一つの答えですが、「そもそも三段階とも必要ですか」と聞くのはもう一つの答えです。後者が通れば、画面は一つで済みます。使う人の手間も、作る手間も、あとで直す手間も一緒に減ります。
システム化を順番の後ろに置いているのも、同じ理由です。無駄を含んだ業務をそのままシステムにすると、無駄のほうが固定されてしまう。紙でやっていた非効率は紙をやめれば消えますが、システムに埋め込まれた非効率は、改修しないともう消えません。だから、直せるものを先に直してから作ります。
AI導入を最後に置いているのも同じです。整理されていない業務にAIを載せても、何を任せているのかが誰にも説明できません。人が何を見て判断しているのかを言葉にできて初めて、任せる範囲を決められます。
この順番を最初から最後まで引き受ける会社は、それほど多くないというのが私たちの実感です。だからこそ、ここを自社で通しでやれることを強みだと考えています。
作るものが決まってから、ようやくJavaとクラウドの話になります
ここまで来て、ようやく一般的な意味での「開発」が始まります。
技術の選び方は案件によりますが、中心にあるのはJavaで、必要に応じてTypeScriptやPythonを使います。クラウドはAWSとAzureの両方を扱っていて、どちらかに寄せているわけではありません。お客さまがすでに使っている環境に合わせられるほうが、動き出したあとの運用が楽になるからです。
もう一つ、いまの開発で大きいのが生成AIの使い方です。弊社では、整理や下書きにChatGPT、コードの生成にClaude Code、レビューにCopilotという三段構えで日常的に使っています。体感では、従来のやり方の五倍から二十倍の速さで進んでいる場面があります。
ただ、速くなったぶんをそのまま納期の短縮だけに使ってしまうのは、もったいないと思っています。浮いた時間を業務の理解や、設計の作り直しに回せることのほうが価値がある。コードを書く時間が減るほど、「何を作るか」を考える時間が増える。一気通貫でやっている会社にとって、生成AIはそこに効いてきます。
リリースして終わりにならないのも、この入り方の特徴です。業務整理からやっていると、システムが動き始めたあとに「思っていたより使われていない画面」や「結局まだExcelでやっている作業」が見えてきます。最初の業務フローを自分たちの手で書いているので、どこが変わってどこが変わっていないのかを、同じ紙の上で比べて話すことができます。
この入り方は、入社の時点でできる必要がありません
ここまで読んで、「業務を聞き出すなんて、経験がないと無理では」と思われたかもしれません。私も最初はそう思っていました。
弊社は社員十数名、平均年齢27.5歳の会社です。二十代でリーダーを務めているメンバーもいます。冒頭に書いた二十件あまりのプロジェクトを、ベテランだけで回してきたわけではありません。
入社後はOJTが中心で、先にお客さまの前に出る人の隣に座るところから始まります。聞いた内容を図にするのは、新しく入った方の役目になることが多い作業です。これは雑用ではなく、業務を一番早く覚えられる席だと思っています。書いてみると、自分がどこを分かっていないかが、その場ではっきりするからです。
コードのほうも、レビューでは「なぜこの書き方なのか」まで書くようにしていますし、オンラインの勉強会やLT会も定期的に開いています。資格取得の支援もあります。働き方は原則リモート、フルフレックスでコアタイムはありません。
「上流から関わりたい」を、実際の仕事にしませんか。
K.Platinumはアプリ開発エンジニアを募集しています。扱う技術・報酬・選考の流れは採用ページに載せています。まずはカジュアル面談だけでも歓迎です。
まとめ
何を作るかが決まっていない場所に立つのは、正直に言えば不安もあります。仕様書があったほうが、その日にやることははっきりします。
それでも私たちがこの入り方を続けているのは、お客さまの困りごとが、いつも仕様書の手前にあるからです。そこに立ち会えるエンジニアは、自分の書いたコードが誰の何を軽くしたのかを、最後まで見届けることができます。
未経験からでも、業務の話を面白がれる方なら、この仕事は向いていると思います。「コードだけ書いていたい」よりも「なぜこれを作るのかを知りたい」に近い方と、一度お話ししてみたいです。
清水洋太（しみず・ようた）
株式会社K.Platinum所属。エンジニアが力を発揮できる環境づくりを大切にしている。
K.Platinumでは一緒に働くエンジニアを募集しています。「実力で正当に評価される環境」に興味がある方は、ぜひ採用ページをご覧ください。