株式会社K.Platinum 清水洋太
「上流工程から関われます」。求人票でよく見かける一文です。ただ、その「上流」がどこから始まるのかは、会社によってずいぶん違います。要件定義書を渡されるところからなのか、それとも、お客様がまだ「何を作るか」を決めていないところからなのか。弊社は後者です。
同じ「上流」でも、この二つは仕事の中身がまるで違います。前者は決まったものをどう作るかを考える仕事で、後者は何を作るかを決める仕事です。この記事では、K.Platinumのエンジニアがお客様との最初の打ち合わせに同席してから、提案として形になるまでの「前半戦」で何をしているのかを書きます。開発が始まる前の時間に、どんな仕事があるのかという話です。
最初の打ち合わせに、要件定義書はありません
弊社のITコンサルティングは、提案活動から始まります。つまり、まだ案件になっていない相談から入るということです。
最初の打ち合わせでお客様から出てくるのは、仕様ではなく困りごとです。「毎月の締め作業に3日かかっていて、担当者が残業前提になっている」「見積りの精度が上がらず、案件ごとの採算が後から分かる」。粒度としてはこのくらいで、システムの話はまだ一言も出てきません。
ここで私たちがやるのは、質問することです。その3日は誰が何をしている時間なのか。どこで手が止まるのか。止まる原因は、データが揃っていないからなのか、承認を待っているからなのか、それとも転記に時間がかかっているからなのか。話を聞きながら、その場で業務の流れを図にしていきます。図にすると、お客様自身が「ここ、実は二重に確認してますね」と気づくことがよくあります。
この場にエンジニアが同席する理由は、実現可能性とコストの土地勘をその場に持ち込むためです。業務の話だけを聞いて持ち帰り、社内でエンジニアに相談してから回答する——という進め方だと、往復のたびに1週間が溶けます。同席していれば、「それは今お使いの仕組みを大きく触らずにできそうです」「逆にそこは作り替えが必要で、期間もそれなりにかかります」を、その場で言えます。
言えないときは、言えないと伝えます。「持ち帰って調べます」と正直に返したほうが、後で見積りが二倍になるより、はるかに信頼されます。前半戦で大事なのは、答えを持っていることより、何が分かっていて何が分かっていないかを切り分けられることです。
提案書を書くのは、営業だけの仕事ではありません
課題が見えてきたら、提案書やRFPへの回答という形にまとめていきます。弊社ではこの工程を「提案支援」と呼んでいて、エンジニアもしっかり手を動かします。
エンジニアが担当するのは、主に三つです。ひとつめは現行調査。今どんな仕組みが動いていて、どこにデータがあり、何と何がつながっているのかを洗い出します。ふたつめはアーキテクチャ案。クラウドをどう使うか、既存資産をどこまで活かすか、段階的に進めるならどこで区切るか。みっつめは概算工数とリスクです。
このみっつめが、いちばん胃が痛い仕事かもしれません。まだ仕様が固まっていない段階で、期間と規模の見当をつけて数字を置くわけですから。だから弊社では、概算には必ず前提条件を添えます。「この前提が崩れるとここが伸びます」を先に書いておく。数字だけを置いて後で揉めるより、幅と条件をセットで示したほうが、お客様も社内で説明しやすくなります。
提案書を書く過程には、副産物があります。書こうとすると、自分の理解の穴が見つかるのです。「このデータって、誰がいつ登録しているんだっけ」と手が止まる。その瞬間が、次の打ち合わせで聞くべきことのリストになります。頭の中で分かったつもりだったことが、文章にした途端に分かっていなかったと判明する——この経験は、後の設計フェーズでもそのまま効いてきます。
出来上がった提案は、社内で相互にレビューします。技術的に正しいかだけでなく、「この提案書、お客様の言葉で書けているか」を見ます。専門用語で埋めた提案書は、読む人が意思決定できません。
「作らない」提案をすることもあります
提案の結論が、いつもシステム開発になるとは限りません。
以前、ある製造業のお客様から工数管理まわりの相談をいただいたことがあります。話を聞いていくと、詰まっていたのは集計そのものではなく、各拠点から上がってくるデータの形式がばらばらで、担当者が毎回手作業で整えているところでした。ここに新しいシステムを一から作るという選択肢もありましたが、私たちが提案したのは、まず入力の形式を揃えることと、その整形作業を自動化することでした。結果として、大がかりな開発をせずに現場の負荷が下がりました。
弊社が「業務整理 → 業務改善 → システム化 → AI導入」という順番を大切にしているのは、こういう場面があるからです。順番を飛ばして最初からシステム化に入ると、整理されていない業務がそのまま画面になります。使いにくいシステムの多くは、技術ではなく、その手前の整理を飛ばしたことが原因です。
もちろん、作らない提案をすればその案件の売上は小さくなります。それでも私たちがその提案をするのは、課題が本当に解けたかどうかのほうを見ているからです。実際、「今回は作らないほうがいい」と伝えたお客様から、次の相談をいただくことは少なくありません。この順番でしか積み上がらない信頼があります。
一般的な業務コンサルは提案までで、システム会社は開発から。その境目で困っているお客様は、想像よりずっと多いです。弊社は業務・IT・マネジメントの三つをまたいで、課題の整理から実際にリリースするところまで自社で対応します。前半で「作らない」と言えるのは、後半まで責任を持つ前提で関わっているからです。
提案から入ると、開発フェーズの景色が変わります
前半に時間を使うと、開発が始まったときの手触りが変わります。
いちばん大きいのは、「なぜこの仕様なのか」をチーム全員が知っている状態で作り始められることです。仕様書に書かれていない判断を迫られたとき——だいたい、そういう場面は必ず来ます——背景を知っていれば、その場で筋の良いほうを選べます。背景を知らないと、確認のたびに手が止まります。
仕様変更への対応も速くなります。お客様の事情が変わって要件が動いたとき、「その変更は当初の課題にとって重要か」を判断できるからです。全部を等しく受け入れるのでも、全部を断るのでもなく、優先順位の話ができる。これは、最初の打ち合わせに立ち会っていた人間だからこそできる会話です。
弊社は設立から3年あまりで20件を超える開発プロジェクトを経験してきましたが、生成AIを開発プロセスに組み込んだことで、実装そのものにかかる時間は以前よりかなり短くなりました。だからこそ、「何を作るかを決める前半」の価値が相対的に上がっている、というのが最近の実感です。速く作れる時代だからこそ、作るものを間違えないことの重みが増しています。
「作る前」の打ち合わせから関わるエンジニアを募集しています。
提案・要件定義から開発・リリースまで、同じチームの中で地続きに担当します。フルリモート・フルフレックス勤務です。
エンジニア募集中！働き方と選考の流れを見る
「この機能、誰が使うんだろう」が気になる人へ
コードを書くのが好きなら、それは十分な強みです。そのうえで、「この機能、そもそも誰が何のために使うんだろう」と気になってしまう人には、弊社の仕事は面白いはずです。その疑問を、お客様に直接ぶつけられる場所だからです。
最初から全部できる必要はありません。私自身、最初の打ち合わせで的外れな質問をしたことは何度もあります。それでも同席し続けているうちに、聞くべきことの順番が分かってきました。弊社はフルリモートで、社員十数名。提案から開発、リリースまでが同じチームの中で地続きになっているので、前半戦に関わるチャンスは早い段階から回ってきます。
「作る前」から関わってみたい方は、ぜひ一度お話ししましょう。
まとめ
弊社のエンジニアが最初の打ち合わせに同席するのは、実現可能性とコストの土地勘をその場に持ち込むためです。業務の話だけを聞いて持ち帰り、社内で相談してから回答する進め方だと、往復のたびに1週間が溶けます。その場で「それは大きく触らずにできそうです」「そこは作り替えが必要です」と言えること。これが前半戦の速度をつくっています。
そして前半に時間を使うと、後半の景色が変わります。なぜこの仕様なのかをチーム全員が知った状態で作り始められ、要件が動いたときにも優先順位の話ができる。実装そのものが速くなった時代だからこそ、作るものを間違えないための時間に価値が集まっている——提案から入る会社で働いていて、いちばん実感するのはそこです。
清水洋太（しみず・ようた）
株式会社K.Platinum所属。エンジニアが力を発揮できる環境づくりを大切にしている。
K.Platinumでは一緒に働くエンジニアを募集しています。「実力で正当に評価される環境」に興味がある方は、ぜひ採用ページをご覧ください。