技術選定の自由度が高い組織で何が起きるか

ClassLab Engineering の Dev チームメンバーが執筆しました。

この記事は、技術選定に関わりたいテックリード・EMや、多言語環境でのチーム開発に興味があるエンジニア向けです。

1. 背景

ClassLab のエンジニアリングチームは、プロダクトの技術選定をエンジニア自身に委ねる方針を取っています。CTO が特定のスタックを指定するのではなく、「そのプロダクトに最適な技術を、担当エンジニアが選ぶ」というスタンスです。

この方針の結果、社内には以下の技術スタックが共存しています。

「なぜ統一しないのか」という疑問は当然あります。この記事では、技術選定の自由度を高く保つ組織で実際に何が起きたかを、利点と課題の両面から率直に共有します。

2. 課題（技術の多様性がもたらすもの）

これらは実際に発生した課題であり、現在も完全には解消されていません。しかし、以下に述べる利点が課題を上回ると判断しています。

3. 設計（技術選定の判断基準）

技術選定の自由度が高いといっても、何でもありではありません。暗黙的に共有されている判断基準があります。

選定時の3つの問い

flowchart TD
    START[新プロダクト/機能の技術選定] --> Q1{そのドメインに<br/>最適な言語/FWは?}
    Q1 --> Q2{チーム内に<br/>経験者がいるか?}
    Q2 -->|いる| Q3{長期運用の<br/>見通しがあるか?}
    Q2 -->|いない| LEARN[学習コストを見積もり<br/>代替案と比較]
    LEARN --> Q3
    Q3 -->|ある| ADOPT[採用]
    Q3 -->|ない| RECONSIDER[汎用的な選択肢を<br/>再検討]

問い1: ドメイン適合性 OCCTO連携にPHPを選んだのは、SOAPのネイティブサポートが決定的だったからです。AI研修にElectronを選んだのは、ローカルWebSocket通信が必要だったから。技術選定の最大の判断基準は「そのドメインの制約に最も自然に適合するか」です。

問い2: チーム内の経験 未経験の技術を選ぶ場合は、学習コストと代替案を明示的に比較します。Flutterの採用時は、React Nativeとの比較検討を行い、Google Maps SDKの統合品質で判断しました。

問い3: 長期運用 プロトタイプやスクリプトなら選定基準は緩くなりますが、年間15万件を処理する基幹システムのような長期運用プロダクトでは、コミュニティの活発さ・メンテナンス見通し・採用市場を重視します。

やらないこと

• 技術統一のための移行プロジェクト: 動いているシステムを別言語で書き直すことはしない
• スタック制限による採用フィルタ: 「Go経験必須」のような制限は設けず、ドメインへの関心を重視
• 技術的な正解の押しつけ: アーキテクチャレビューは行うが、最終判断は担当エンジニアに委ねる

4. 実装（具体的に何が起きたか）

事例1: SOAP連携でPHPが最適解になった

ライフライン基幹システムのOCCTO連携で、当初はGoでの実装を検討しました。しかしOCCTOのWSDLベースSOAP APIに対して、GoのSOAPライブラリは型マッピングの自動生成が不十分でした。PHPのSoapClientがWSDLを自動パースし、型安全なリクエスト構築をネイティブでサポートしていたため、PHPを選定しました。

事例2: Electronが唯一の選択肢だった

AI研修システムでは、SalesforceのLWCユーティリティバーからws://localhost:3001でデスクトップアプリと通信する必要がありました。WebアプリではブラウザのセキュリティポリシーでローカルホストへのWebSocket接続が制限されるため、Electronデスクトップアプリが実質的に唯一の選択肢でした。

事例3: AI駆動開発が多言語を可能にした

技術の多様性を支えているのは、Claude CodeとGitHub Copilotの全員導入です。PHPのレビューが得意なメンバーが少なくても、AIアシスタントがコードレビュー・テスト生成・ドキュメント作成を補完します。これにより、少人数チームでも複数言語の品質を維持できています。

事例4: Pythonスクリプトが業務自動化の標準になった

コールセンターの業務自動化では、当初はPHPで統一する案もありました。しかし、AWS Lambdaとの統合性、データ分析ライブラリの充実、そして非エンジニアでも読みやすいコードという点で、Pythonが最適と判断しました。実際に業務部門のメンバーが処理ロジックを読んでフィードバックするケースがあり、言語の可読性が組織間コミュニケーションに貢献しています。

事例5: 技術選定の失敗と学び

すべてが成功したわけではありません。ある社内ツールでフレームワークの選定を誤り、チーム内に経験者が不在のまま開発を進めた結果、メンテナンスが属人化した事例があります。この経験から「問い2: チーム内に経験者がいるか?」を選定プロセスに明示的に組み込みました。失敗から学んだルールこそが、選定基準の核になっています。

共通化した唯一のレイヤー

多言語環境でもCI/CDパイプライン（GitHub Actions）だけは統一しています。ワークフロー定義はプロダクト固有ですが、トリガー方式・シークレット管理・デプロイ先の命名規則は全プロダクトで共通です。

5. 結果（数値）

「技術的負債による書き直し0件」は、統一スタックを採用した場合には発生し得た「ドメインに合わない技術を無理に適用した結果の書き直し」がゼロという意味です。各プロダクトが適切な技術で構築されているため、根本的な設計問題が起きていません。

一方で、この方針のコストも明確に認識しています。オンボーディング時に「全プロダクトの技術スタックを把握する」のではなく「担当プロダクトのスタックに集中し、隣接プロダクトは概要レベルで理解する」というアプローチを取ることで、新メンバーの立ち上がりを現実的な期間に収めています。

もう一つの定性的な効果として、エンジニアの技術的好奇心が維持される点があります。「この技術を使いたいから」ではなく「この問題にはこの技術が最適だから」という判断ができる環境は、エンジニアのモチベーション維持に寄与しています。採用面談でも「技術選定に関われること」は候補者からの反応が良いポイントです。

6. 展望

次に取り組む課題

• 共通基盤の段階的整備: APIゲートウェイや共通認証基盤の設計。言語統一ではなくインフラと運用の統一を優先する方針で、インフラ設計の経験を持つエンジニアと一緒に進めたい領域です
• ADR（Architecture Decision Records）の蓄積: 「なぜこの技術を選んだか」を組織知として残す仕組みの構築

関連記事

• 15万件/年のライフライン基幹システムの信頼性設計 — PHP選定の具体的な背景
• AI音声ロールプレイ研修を内製した話 — Electron選定の具体的な背景
• Claude CodeとGitHub Copilotを全員が使う開発チームの実態 — 多言語開発を支えるAI駆動開発

採用情報

ClassLab では、技術選定の判断に参画できるテックリード・シニアエンジニアを募集しています。特定の言語に縛られず、ドメインに最適な技術を選べる環境です。

• Findyでカジュアル面談する
• 採用情報を見る