株式会社K.Platinum 清水洋太
転職を考えるとき、多くの方が気にされるのは「入ったら何をやらされるか」よりも、「入ったら何ができるようになるか」ではないでしょうか。
求人票には技術スタックが並んでいます。でも、そこに書かれた言語やクラウドを、自分が本当に手を動かして触れるのか。それとも、すでに決まった構成の上で、決まった機能を作り続けるのか。求人票からは読み取れません。
弊社で働くエンジニアの職務経歴書は、2年も経つと最初の頃とかなり違う見た目になります。この記事で書くのは、制度の名前を並べた話ではありません。AWSの次にAzureが来て、その次に業務改善の相談が来る ── その「案件の並び方」そのものの話です。
クラウドが変わると、設計の「癖」に気づく
弊社が関わってきた案件は、業界もクラウドも一つではありません。
たとえば製造業向けのAI基盤構築では、AWSを中心に組みました。API Gateway、SageMaker、Aurora、S3。マネージドサービスを組み合わせて、データが流れる道筋を作っていく仕事です。
一方で、金融業界向けの業務システムでは、Azureを使いました。AKS上のアプリケーション、Cosmos DB、認証基盤との連携。同じ「クラウド上の業務システム」でも、考えることの順番がまるで違います。
片方だけを長く触っていると、そのクラウドの流儀が自分にとっての「当たり前」になります。当たり前は、疑えません。
けれど両方を経験すると、「なぜここはキューを挟むのか」「なぜここはマネージドに寄せるのか」を、自分の言葉で説明しなければならない場面が出てきます。他社の当たり前と比べて初めて、自分がやってきた設計が「選択のひとつだった」と分かる。この気づきは、本を読んでも手に入りません。
案件の大きさにも幅があります。100万人規模の認証基盤に関わることもあれば、現場の方が毎日手作業でこなしている集計を、表計算のマクロで数分に縮めるような案件もあります。
後者を「小さい仕事」と呼ぶ方もいますが、私はそう思っていません。使う人の顔が見え、効果がその日のうちに返ってくる仕事は、設計の良し悪しがごまかせない。大きな基盤を作るときの感覚とは別の筋肉が鍛えられます。
もちろん、毎回まったく違う技術に放り込まれるわけではありません。Javaを軸に持つメンバーが多く、その軸は案件が変わっても消えません。変わるのは、軸のまわりに何が積まれるかです。
「そもそも、その業務は必要ですか」と言える立ち位置
もうひとつ、技術が広がる理由があります。弊社が、提案の段階から関わっているからです。
弊社のメイン事業は、ITコンサルティングです。ただ、「コンサルティング」という言葉から想像される、資料を作って提言して終わり、という仕事ではありません。お客さまのビジネス課題を整理するところから入り、業務改善の方向を決め、システムを作り、リリースまで持っていく。そこまでを自社で担います。
一般的な業務コンサルティング会社は、戦略の提案までが守備範囲です。システム開発会社は、要件が固まった後から参加します。その間には、「何を作るかを決める」工程がまるごと残っています。
「こういうシステムが欲しい」というご要望の背景を伺っていくと、業務の順番を入れ替えるだけで解決する話だった、ということが本当にあります。逆に、現場の運用を見ないまま作られた機能が、誰にも使われずに残っていることもあります。
実際の打ち合わせで出てくるのは、「この帳票は誰が見ていますか」「この承認は何を防ぐためのものですか」といった、コードとは関係のない問いです。答えが出てこない項目は、たいてい後から仕様変更になります。
エンジニアがこの距離の手前側に立っていると、技術選定の理由が腹落ちします。「この要件だからこの構成」ではなく、「この業務をこう変えたいからこの構成」で考えられるようになる。ここが分かってくると、設計の判断がぶれにくくなります。
「要件が固まる前」から関わる仕事を見てみたい方へ — K.Platinumでは、提案の段階から入って設計・開発まで担当するエンジニアを募集しています。エンジニア募集中！詳しい条件を見る
広がるのは技術だけではない ── 提案書、講師、自社プロダクト
案件を重ねていくと、増えるのはコードを書く対象だけではないことに気づきます。
提案書やRFPの読み書き。アーキテクチャの設計方針を、技術者ではない方に説明する資料づくり。設計から導入までのプロジェクトマネジメント支援。お客さまの社内調整の事情を踏まえて、どこから着手するかを一緒に決めること。
弊社には、受託の開発以外にも動いている場があります。プログラミングスクールの運営では、現役のエンジニアが講師として教えています。自社のプロダクト開発も走っています。本業の案件と並行して、こうした場に手を挙げるメンバーもいます。
教える側に回ると、自分が感覚でやっていたことを言葉にしなければなりません。自社プロダクトに関われば、納期も仕様も自分たちで決める側の苦労が分かります。どちらも、受託の現場に戻ったときに効いてきます。
技術領域そのものも、Webシステムの開発だけにとどまりません。RPAによる定型業務の自動化、AI・機械学習を使った仕組み、モバイルアプリ、IoT。案件のご相談として持ち込まれるテーマは年々増えています。すべてを一人が担当するわけではありませんが、「その領域は分からないので」と手前で線を引いてしまうと、そこから先の話が社内で止まってしまう。だから、まずは調べて、分かるところまで持っていく人が強いです。
「やってみたい」と言った人に、まずやってもらう。この順番は、弊社では例外のほうが少ないと思います。役割を先に用意してから人を当てはめるのではなく、手が挙がったところから形にしていく。だから、入社前に描いていたキャリアの線と、2年後の実際の線は、たいてい少しずれます。多くの場合、想定より外側にずれます。
「広がりっぱなし」にしないための、研修とOJTと資格支援
ただ、いろいろな案件に関わることが、そのまま成長になるわけではありません。経験が点のまま散らばって終わることは、いくらでもあります。
そうならないように、弊社では研修をいくつかのカテゴリに分けて整理しています。入社時の研修、業務そのものに関する研修、ビジネススキルの研修。そして日々の仕事の中では、OJTで先輩が並走します。
資格取得の支援制度もあります。案件の中で断片的に触った技術を、体系立て直すきっかけとして使っているメンバーもいます。
働き方の面でも、フルフレックスで、原則リモートワークです。コアタイムはありません。学び直しの時間を夜に寄せる人もいれば、朝に寄せる人もいます。時間の使い方まで一律に決めてしまうと、せっかくの制度が形だけになってしまうので、そこは各自に委ねています。
広げる機会と、広げたものを整理する場所。両方がないと、経験は資産になりません。
まとめ
「この会社に入ったら、何ができるようになるか」という問いに、弊社は「これができるようになります」とひとつの答えを返すことができません。案件によって変わりますし、本人が手を挙げたかどうかでも変わるからです。
その代わりに言えることがあります。ここには、ひとつの技術だけを10年続ける道は、あまり用意されていません。クラウドが変わり、業界が変わり、求められる役割が変わっていく前提で、仕事が並んでいます。
それを大変だと感じる方もいると思います。ただ、もし今「この延長線上にいる3年後の自分が、あまり想像できない」と感じているのなら、一度お話ししてみませんか。技術の話でも、キャリアの話でも構いません。
弊社は、エンジニアが正当に評価され、実力主義が成り立つ社会を目指しています。そのための最初の一歩は、評価される中身そのものを増やせる環境に身を置くことだと考えています。
清水洋太（しみず・ようた）
株式会社K.Platinum所属。エンジニアが力を発揮できる環境づくりを大切にしている。
K.Platinumでは一緒に働くエンジニアを募集しています。「実力で正当に評価される環境」に興味がある方は、ぜひ採用ページをご覧ください。