株式会社K.Platinum 清水洋太
面接でよく聞かれる質問があります。「御社はAWSですか、Azureですか」。
正直にお答えすると、どちらもあります。そして、その答えは案件ごとに違います。ここで「両方経験できます」と言ってしまうと便利なのですが、実際に伝えたいのはもう少し手前の話です。弊社の案件では、使う技術はたいてい、いちばん最後に決まります。
この記事では、技術が決まるまでに何が起きているのか、弊社が選定で見ている4つの観点、そして決めたあとに必ず残している記録について書きます。技術選定を「決まったものを受け取る作業」だと思っている方にこそ、読んでいただきたい内容です。
技術の話をする前に、業務の話が数週間続く
弊社のメイン事業はITコンサルティングです。お客様のビジネス課題に対して提案活動から入り、課題の整理・改善からシステム開発、リリースまでを一気通貫で支援します。
そのため、案件の最初に出てくるのは技術要件ではありません。「毎月の締め処理に何日かかっているのか」「その作業は誰が、何を見ながらやっているのか」といった、業務の話です。ときには、システムを作らずに業務の手順を変えるだけで解決してしまうこともあります。
この段階でエンジニアが同席する理由は、後で技術を選ぶのが自分たちだからです。
現場のヒアリングに入っていないと、要件だけを渡されたときに「なぜその条件なのか」が分かりません。たとえば「夜間バッチは3時間以内に終わってほしい」という一行があったとして、その裏に「翌朝7時の店舗開店に間に合わせたい」という事情があるのか、「なんとなく今までそうだった」なのかで、設計の選択肢はまったく変わります。前者なら処理時間は死守すべき制約で、後者なら交渉できる希望です。
この違いは、打ち合わせの場にいれば分かります。議事録だけでは、ほぼ落ちます。だから弊社では、エンジニアが「つくる前」の会話から入ります。
もうひとつ、この期間にしかできないことがあります。まだ言葉になっていない要件を拾うことです。お客様は困りごとを業務の言葉で話されますが、そのなかには「実は毎月ここで手作業の確認をしている」といった、本人にとっては当たり前すぎて要件に書かれない作業が混ざっています。そこを聞けているかどうかで、後半の手戻りの量が変わります。
選定で見ているのは、技術そのものより「その後」の4つ
業務の輪郭が見えてきて、はじめて技術の話になります。このとき弊社が見ているのは、主に4つです。
1つ目は、既にあるものとの接続。お客様の環境には、たいてい長く使われてきたシステムがあります。そこと繋がらない選択は、どれだけ新しくても採用できません。
2つ目は、運用する人。リリース後に手を入れるのが誰かによって、選ぶべきものは変わります。社内に情報システムの担当者がいない会社に、運用に高い専門性が要る構成を置いていくのは不誠実だと考えています。
3つ目は、数年後に変えられるか。作った瞬間がいちばん良い状態で、あとは劣化していくだけ、という作り方をしない。制度や業務ルールの変更で仕様が変わるのは前提として、そのときどこを触れば済むのかを最初に決めておきます。特定のサービスに深く依存する構成を選ぶなら、抜けられなくなる範囲をどこまでに抑えるかまで含めて判断します。
4つ目は、コスト。クラウドの構成は、動かし方ひとつで費用が桁違いになります。動くかどうかだけでなく、毎月いくらで動き続けるのかまでを見て提案します。
この4つは、どれも「今日動くか」ではなく「このあと何年か付き合えるか」を見ている点で共通しています。技術の新しさや好みは、正直この後ろに来ます。
弊社ではAWSもAzureも使いますし、言語はJavaを中心にTypeScriptやPythonまで。案件によってはRPAやAI・機械学習、モバイルアプリやIoTの領域にも広がります。選べる幅があるのは、特定の技術を売る立場にいないからです。 この4つに照らして選んだ結果がたまたまAWSだった、Azureだった、というだけの話です。
エンジニア募集中。 技術を「選ぶ側」で働ける環境かどうかは、募集要項を見ていただくのが早いです → 募集中のポジションと条件を見る
決めるのは、いちばん根拠を持っている人
技術選定というと、役職の高い人が決めるものだと思われがちです。弊社はそうなっていません。
選定の場では、まず候補を並べて、それぞれの案で何が起きるかを書き出します。ここで通るのは「新しいから」「流行っているから」ではなく、「この制約があるから、この案では詰まる」という具体的な根拠です。根拠を持っている人の案が通ります。それが入社1年目のメンバーであることもあります。
逆に言えば、経験が浅いうちでも、調べて根拠を用意すれば選定に入っていけます。実際、若いメンバーが「この構成だと運用側の負担が増えませんか」と指摘して、案がひっくり返ったこともあります。
弊社は原則リモートワークなので、この議論の多くはテキストで進みます。声の大きさや発言のタイミングではなく、書かれた根拠が並んで比較される。リモートは不便なことも多いですが、この一点については、フェアに働いていると感じています。
その代わり、決めた人が一番よく分かっているので、後の設計や実装でも中心になります。決めることと、責任を持つことはセットです。 ここを分離しないのが、弊社のやり方です。
技術は年々変わりますが、この「根拠で決める」やり方は変わりません。だから、いま持っているスキルセットよりも、分からないことを調べて言語化できるかどうかを、私たちは見ています。
決めたあとに、必ず残すもの ── 選定理由の記録（ADR）
選定が終わったら、その理由を必ず書き残します。何を比較して、何を理由に落としたのか。この記録があると、数年後に「なぜこの構成なのか」と聞かれたときに答えられます。
これは自分たちのためでもあります。リリースして終わりではなく、運用や改善まで関わり続けるのが一気通貫の後半です。当時の判断の理由が残っていないと、過去の自分が置いた制約に、未来の自分が振り回されます。
書き方は難しくありません。候補を並べた表と、採用した理由、落とした理由を数行ずつ。世の中ではADR（Architecture Decision Record＝アーキテクチャ決定記録）と呼ばれる形式が知られていますが、様式にこだわる必要はありません。大事なのは分量ではなく、「その時点で何を知っていて、何を知らなかったか」が分かる状態にしておくことです。後から読む人が責めるためではなく、前提が変わったかどうかを判断するために読みます。
お客様に対しても、同じものをそのままお見せします。選定の理由を隠さないほうが、その後の相談がしやすくなるからです。
そして、こうした記録はそのまま次の案件の材料になります。似た業務課題に当たったとき、「前の案件ではこれを理由にこちらを選んだ」という前例が社内にあるのは、想像以上に強いです。ここが、一つの技術に閉じずに案件を重ねていくことの、いちばんの見返りだと思っています。
「どのクラウドを使っていますか」という質問の答えは、たぶんどの会社でも数年で変わります。変わらないのは、何を見て選ぶかのほうです。
弊社は、その選ぶ過程にエンジニアを最初から置いています。言われたものを作るのではなく、なぜそれを作るのかを決める側に立つ。その経験は、どんな技術が流行り廃りしても、手元に残り続けます。
実力で正当に評価される環境で、技術を「選ぶ側」に回ってみたい。そう考えている方とは、まずカジュアル面談で一度お話ししたいです。選考の前に、実際の案件でどう技術を決めているかをお伝えします。
清水洋太（しみず・ようた）
株式会社K.Platinum所属。エンジニアが力を発揮できる環境づくりを大切にしている。
K.Platinumでは一緒に働くエンジニアを募集しています。「実力で正当に評価される環境」に興味がある方は、ぜひ採用ページをご覧ください。