株式会社K.Platinum 清水洋太
「エンジニアの仕事は、コードを書くことだと思っていました」
入社してしばらく経ったメンバーから、こういう感想をもらうことがあります。もちろんコードは書きます。書かない日はありません。それでも、日によっては「日本語を書いている時間」のほうが長くなる。提案書、業務フロー、要件定義書、議事録、そしてお客様への一通のメッセージ。これらを書くことも、私たちの仕事のど真ん中にあります。
この記事では、なぜ私たちのエンジニアに「書く時間」が生まれるのか、その時間がエンジニアとしての市場価値にどう効いてくるのか、そして文章が得意でない方でも大丈夫な理由を、順番にお話しします。「上流工程には興味があるけれど、資料づくりは苦手だ」と感じている方にこそ読んでいただきたい内容です。
「何を作るか」が決まっていない状態から、仕事が始まります
私たちのメイン事業はITコンサルティングです。お客様のビジネス課題に対して提案活動から入り、課題の改善、システム開発、リリースまでを一気通貫で支援します。
ここが、いわゆる受託開発の会社と少し違うところです。一般的に、業務コンサルティングの会社は戦略や業務の提案までを担当し、システム開発の会社は決まった仕様をかたちにすることを担当します。私たちは、その両方をひとつのチームで引き受けます。業務整理から業務改善、システム化、そしてAI導入まで、業務・IT・マネジメントの三位一体で関わる。それが私たちの立ち位置です。
その結果、案件の入口で私たちの手元にあるのは、きれいに整った仕様書ではありません。「月末になると特定の部署だけ残業が跳ね上がる」「担当者が変わるたびに引き継ぎでミスが起きる」といった、現場の生の困りごとです。
ある製造業のお客様の案件では、最初のヒアリングで出てきたのは「Excelの集計に時間がかかっている」という一言だけでした。そこから現場の方に一日の流れを聞き、誰がどのタイミングで何を入力しているのかを書き出していく。すると、時間がかかっている本当の原因は集計作業ではなく、その手前の「入力ルールが部署ごとに違うこと」だとわかりました。
この工程で私たちが作るのは、コードではありません。業務の流れを描いた図と、そこから導かれた課題の整理です。この最初の成果物の質が、後工程のすべてを決めます。ここが曖昧なまま開発に進んだプロジェクトは、たいてい終盤で作り直しが発生します。
提案書は「売り込み」ではなく、認識をそろえる道具です
提案書と聞くと、営業資料のような、こちらの実力をアピールする文書を想像されるかもしれません。私たちが書く提案書は、それとは少し性格が違います。
一番の目的は、「私たちはあなたの課題をこう理解しました」を、相手の言葉で書き切ることです。技術的にどんなアーキテクチャを選ぶかは、その後の話になります。
だから提案書を書くときは、曖昧な言葉を徹底的に潰していきます。「使いやすくする」ではなく「いまは1件あたり5分かかっている入力を、1分以内にする」。「効率化する」ではなく「月末に3人でやっている作業を、1人が確認するだけの状態にする」。数字と、誰の作業がどう変わるかまで書く。ここまで書いて初めて、お客様は「そこは違う、うちが困っているのはもっと手前だ」と言えるようになります。
読み手がひとりではない、というのも大事な前提です。提案書を読むのは、情報システム部門の方だけではありません。実際にその業務を毎日やっている現場の方、そして投資判断をする経営層の方も読みます。それぞれ知りたいことが違う三者に、同じ一枚の絵を見てもらう。そのために、専門用語を並べるのではなく、業務の言葉で書く必要があります。
この「翻訳する力」は、正直に言えば、コードを書く力とは別の筋肉です。でも身につけると、エンジニアとしての立ち位置が変わります。仕様をもらう側から、仕様を一緒に決める側になれるからです。
要件定義は「決める」より「そろえる」作業です
提案が通ると、次は要件定義に入ります。ここでも、書く時間がまとまって発生します。
要件定義書でトラブルになるのは、たいてい「書いてあること」ではなく「書いていないこと」です。たとえば、既存システムからのデータ移行をどこまでやるのか。過去何年分を対象にするのか。移行できなかったデータはどう扱うのか。合意しないまま進むと、リリース直前に「そこはやってもらえると思っていました」という会話が生まれます。
そこで私たちは、要件定義書に「やること」と同じくらいの分量で「やらないこと」と「前提」を書きます。今回のスコープに含まれない範囲、お客様側で対応いただく作業、判断が保留になっている論点。これを明文化しておくと、後から状況が変わったときに「ではここを見直しましょう」と、感情ではなく事実ベースで話ができます。
書いたものは、社内でレビューします。フルリモートなので、レビューはテキストで残ります。「この一文、二通りに読めます」「この数字の根拠はどこですか」と、若手が書いたものにもベテランが書いたものにも同じように指摘が入る。逆に、入って半年のメンバーが先輩の要件定義書に質問を投げることも普通にあります。読んでわからないなら、それは書き手の責任だからです。
このレビューを何度か経験すると、書き方が変わります。自分が理解していないことは、文章にすると必ずバレる。だから書く前に、わからない部分を先に潰しにいくようになる。この順番が身についた人は、設計でもコードレビューでも強くなります。
この「書いて、レビューされて、直す」サイクルを面白いと感じた方へ。エンジニア募集中！仕事内容と選考の流れを見る
ChatGPTとClaude Codeを入れても、「書く仕事」は減りませんでした
弊社では、開発プロセスに生成AIを組み込んでいます。ChatGPTでドキュメントのたたき台を作り、Claude Codeでコードを生成し、Copilotでレビューする。この三段構えにしてから、ゼロから白紙に向かうまとまった時間は、はっきり短くなりました。
では書く仕事が減ったかというと、そうではありませんでした。減ったのは「文章をゼロから組み立てる手間」のほうで、残ったのは「何を書くべきかを決める部分」です。
AIは、お客様の現場でどんな会話があったかを知りません。どの部署とどの部署が過去にぶつかっているか、今回の予算がどういう経緯で通ったかも知りません。前提を持っているのは人間だけです。つまり、たたき台が数分で出てくるようになったぶん、そこに正しい前提を入れられるかどうかで差がつくようになりました。
新しく入ったメンバーには、この使い方から入ってもらいます。いきなり完璧な要件定義書は書けなくても、AIに下書きを出させて、それを自分の目で「ここは事実、ここは推測」と分けていく作業はできる。そこから始めて、少しずつ判断できる範囲を広げていってもらいます。
文章がうまい人を採用しているわけではありません
ここまで読んで、「文章に自信がないから難しそうだ」と感じた方がいるかもしれません。安心してください。入社時点で文章力を求めてはいません。
理由は単純で、この種の文章にはある程度の型があるからです。結論から書く、事実と解釈と意見を分ける、判断の材料になる数字を添える。この三つを意識するだけで、伝わり方はかなり変わります。弊社では入社時研修とビジネススキル研修でこのあたりを扱い、そのあとは実際の案件のなかでOJTで身につけてもらいます。オンラインの勉強会やLT会も定期的に開いていて、うまく書けなかった経験を共有する場になっています。
フルリモートで働いていることも、実は追い風になっています。隣の席で口頭で補足する、という手段がないぶん、書いて伝えるしかない。最初は面倒に感じるかもしれませんが、テキストで残る環境は、書き方が上達するのがいちばん速い環境でもあります。
「作れる人」から「決められる人」へ
コードを書く力は、エンジニアの土台です。そこは疑いようがありません。そのうえで、課題を言葉にして、関係者の認識をそろえて、作るものを決められる人は、この先も長く必要とされ続けると思っています。
弊社の仕事は、その両方に手が届く場所にあります。お客様の困りごとを聞いて、業務を整理して、作るものを決めて、実際に作って、届ける。全部の工程に関われるからこそ、書く時間も自分の仕事として引き受けることになります。大変ではありますが、自分の書いた一枚の資料で現場の景色が変わる瞬間は、コードが動いたときとはまた違う手応えがあります。
「言われたものを作る」の先へ行きたい方、課題そのものに向き合ってみたい方には、面白い環境だと思います。ご興味があれば、まずはカジュアルにお話しさせてください。
清水洋太（しみず・ようた）
株式会社K.Platinum所属。エンジニアが力を発揮できる環境づくりを大切にしている。
K.Platinumでは一緒に働くエンジニアを募集しています。「実力で正当に評価される環境」に興味がある方は、ぜひ採用ページをご覧ください。