株式会社K.Platinum 清水洋太
求人票には「Java／AWS・Azure／要件定義から参画」と書いてあります。ただ、これを読んで入社後の景色が浮かぶ人は、たぶんあまりいません。Javaと言っても業務系なのかAPI基盤なのかで日々の作業はまるで違いますし、「要件定義から」も、資料をまとめるだけの現場と、設計判断まで任される現場では意味がまったく変わります。
そこで今回は、弊社のエンジニアが実際に手を動かしている技術を、できるだけそのまま書き出してみることにしました。読み終えたときに分かるのは3つです。どの言語とクラウドを日常的に触るのか、要件定義の段階で何を判断しているのか、生成AIを前提にした開発で何が変わったのか。かっこよく見せる編集はしていません。
主戦場はJavaとSpring、クラウドはAWSとAzureの両方です
まず言語から。中心はJavaです。フレームワークはSpringが主で、画面まわりではThymeleafを使う場面もあります。加えて、フロント寄りの実装や社内ツールではTypeScript／JavaScript、データ処理や自動化ではPython、既存システムの保守でRubyに触れることもあります。「Javaしか書かない会社」ではありませんが、「Javaが背骨にある会社」ではあります。
クラウドはAWSとAzureの両方です。案件で登場する頻度が高いのは、このあたりの顔ぶれです。
- AWS: Lambda（サーバーレスで処理を組み立てる）、Aurora、S3、SageMaker（機械学習の推論基盤を用意する）
- Azure: AKS（Kubernetes）、Cosmos DB ── コンテナ前提のアプリケーションを動かす
- 案件ごとに乗る要素: 認証基盤、メッセージキュー、バッチ処理
- 周辺領域: 定型作業をRPAで置き換える、機械学習で判定を自動化する、業務の入り口をモバイルアプリにする、現場の機器からIoTでデータを吸い上げる
領域としては、金融・製造・流通のお客様が中心です。設立から2年ほどで20件を超える開発プロジェクトを経験してきましたが、その中身は「新しいものを一から作る」ものと「動いているものを作り直す」ものがだいたい半々。後者は既存の業務と既存のデータを壊さずに移行する必要があるので、正直、地味で難しい仕事です。ただ、この「難しい方」をやってきたことが、そのまま会社の技術的な足腰になっていると感じています。
周辺領域まで全員が全部をやるわけではありません。ただ「これはうちの担当ではない」と切り分ける文化がないので、必要になれば調べて手を出すことになります。実際、私自身も入社してから初めて触った領域がいくつもあります。
インフラやDevOpsも外注していません。設計してコードを書いた人が、そのまま動かす場所まで面倒を見ます。守備範囲は広いですが、そのぶん「なぜこの構成なのか」を自分の言葉で説明できるようになります。
「作らない」という結論も出す ── 要件定義から入るということ
弊社の仕事は、提案活動から始まることが少なくありません。お客様が持ってくるのは、たいてい「システムの要件」ではなく「業務の困りごと」です。処理が終わらない、確認作業に人が張り付いている、月末になると全員が残業している。そこから、何をシステムにして、何は運用の見直しで済ませるのかを一緒に決めていきます。
この段階でやっていることは、実はかなり技術的です。業務フローを描き起こし、データがどこで発生してどこで詰まっているかを追い、既存システムのどこに手を入れると影響が最小で済むかを見積もる。「作らない」という結論を出すこともあります。作らずに解決できるなら、それが一番安い解決策だからです。
その上でシステム化に進むと、次はアーキテクチャ設計です。マネージドサービスに寄せるのか、コンテナで持つのか。同期で処理するのか、キューを挟むのか。この判断は、性能や可用性だけでなく、お客様の社内に運用できる人がいるかどうかにも左右されます。技術的に正しい答えと、その現場で回る答えは、必ずしも一致しません。
こういう判断に、若手のうちから同席できます。というより、人数が多くないので同席するしかありません。最初は議事録係でも、半年もすると「この処理、バッチじゃなくてイベント駆動にしませんか」と自分から言い出す人が出てきます。
生成AIは「使ってみる」段階を終えました ── ChatGPT・Claude Code・Copilotの三段構え
弊社の開発プロセスには、生成AIが最初から組み込まれています。おおまかには三段構えです。設計や仕様の整理をChatGPTで文書に落とし、実装はClaude Codeで生成し、レビューにはCopilotを挟む。この流れを回すことで、従来のやり方と比べて5倍から20倍の生産性が出ている工程もあります。
数字だけ見ると景気のいい話ですが、現場の実感としては「作業が速くなった」というより「ボトルネックが移った」に近いです。コードを書く時間が縮んだ結果、仕様が曖昧なまま着手していたことや、レビューの観点が言語化されていなかったことが、そのまま速度の上限として表に出てきました。
だから、いま伸びる人はコードを速く打てる人ではありません。やりたいことを曖昧さなく言葉にできる人と、出てきた成果物の妥当性を判断できる人です。生成AIが書いた実装を読んで「この例外処理は要件と合っていない」と気づけるかどうか。ここは経験と設計力がそのまま出ます。
もうひとつ変わったのは、レビューの重さです。人が書いたコードは書いた本人に意図を聞けますが、生成されたコードにはその相手がいません。そのぶん、要件と実装を突き合わせる作業を丁寧にやる必要があります。逆に言えば、この突き合わせを面倒がらずにできる人は、経験年数に関係なく重宝されます。
新しく入った方には、まずこの三段構えの流れごと引き継いでもらいます。ツールの使い方を覚える研修ではなく、「AIを前提にしたときの、まともな設計とレビューのやり方」を身につけてもらうイメージです。
エンジニア募集中！詳しい条件を見る → K.Platinum 採用ページ
フルリモート・フルフレックス。ここに書いた技術を、要件定義の段階から一緒に触る仲間を探しています。
触れる範囲が広いのは、会社が小さいからです
ここまで挙げた技術に、入社してすぐ全部触れるわけではありません。ただ、触れるまでの距離はかなり短いと思います。社員は十数名、平均年齢は27.5歳で、20代のリーダーも複数います。「あの領域は別の部署の担当なので」と言われる場面が、そもそも存在しません。
学ぶ環境としては、入社時研修と業務研修に加えて、オンラインの勉強会・LT会を定期的に開いています。話す内容は「最近ハマった技術」でも「案件でうまくいかなかった話」でも構いません。資格取得の支援制度もあります。働き方はフルリモート・フルフレックスで、コアタイムはなく、残業もほとんどありません。PCとモニターは貸与、副業も相談の上で認めています。
入社直後は、OJTを中心に既存プロジェクトへ入ってもらうことが多いです。いきなり設計を任せることはしませんが、設計の議論が行われている場には最初から入ってもらいます。「聞いているだけの時期」を意図的に短くしたいからです。分からないことをその場で聞ける空気は、意識してつくっています。
技術を広く触れることと、消耗しないことは両立できると考えています。むしろ、消耗していない状態でないと、新しい技術を面白がる余力は残りません。
まとめ：大事なのは「何を使うか」より「どんな距離で関われるか」
技術スタックの一覧は、会社のサイトにも書いてあります。ただ、ここまで書いてきて改めて思うのは、効いてくるのは技術の名前そのものより「その技術に、どんな距離で関われるか」だということです。課題を聞く場に居られるか、構成を決める議論に入れるか、動かした後まで見届けられるか。弊社の場合、その距離はかなり近いです。近すぎて最初は戸惑うかもしれません。
課題を聞くところから設計、実装、動かす場所の面倒まで一通り関わりたい。生成AIを前提にした開発の進め方を、実務の中で身につけたい。そう考えている方には、面白い環境だと思います。経験年数よりも、目の前の課題に手を伸ばせるかどうかを見ています。
少しでも気になった方は、まずカジュアルにお話しするところからで構いません。あなたが次に書くコードが、どんな課題につながっているのか。その話を、一緒にできたら嬉しいです。
清水洋太（しみず・ようた）
株式会社K.Platinum所属。エンジニアが力を発揮できる環境づくりを大切にしている。
K.Platinumでは一緒に働くエンジニアを募集しています。「実力で正当に評価される環境」に興味がある方は、ぜひ採用ページをご覧ください。