SHIFTについて

池ノ上：皆さん、こんにちは。株式会社SHIFTの池ノ上です。本日は「事業成長の裏側：エンジニア組織と開発生産性の進化」というテーマでお話しします。

まず自己紹介をさせてください。私はSHIFTでVPoEとしてエンジニアリングの管掌責任を負っていて、組織のマネジメントや制度設計をやりながら、事業サイドでのソリューション提供と数字責任を担っています。キャリアの始まりはLAMPを扱うアプリケーションエンジニアで、最近はコードを書く機会も減り、日曜プログラマーとしてAIと格闘しています。

本日の主題に大きく関わるため、まず弊社の事業からご紹介します。SHIFTは総合SIerで、もともとはテスト工程の業務プロセスをマイクロタスク化し、専門訓練を受けていない方でも参画できるテストソリューションから始まりました。その後、2017年頃にDXの会社へと事業をピボットし、社会貢献度を高めていこう、と開発ソリューションなどサービスを拡充しながら成長を遂げてきました。本日はその過程での話が中心となります。

具体的には、アジャイル開発やDevOps導入支援、コンサルティングといったSIメニューに加え、セキュリティやSAPのような専門領域のサービスを立ち上げ、チームを組成し販路を開拓してきました。

幸いにも、事業が順調に進んだことで経営陣の理解と期待を得られ、採用や設備投資も加速しました。しかし、その裏で特にしんどかったのが、事業のスピードと体制構築の勢いです。本日は、主にこの2点についてお話しします。

組織の急拡大がもたらした課題

池ノ上：急成長の過程で採用した人材は、実に多種多様です。当初はモダンな技術に強い方が中心でしたが、SI事業の拡大に伴いレガシーな開発文化も加わりました。さらに、セキュリティやERPといった専門領域には、それぞれ独自のカルチャーや作法が存在します。



多様な人材が増えるほど、組織全体の生産性は下がりがちです。本日は、この課題に対して生産性をいかに維持・向上させてきたか。そして、日々の改善活動を組織的にどう加速させてきたか。この2点をお話しします。



まず1点目ですが、人員の増加は生産性の低下を招きます。特にアプリケーション領域ではカルチャー差が顕著でした。

当初は明確なルールがないまま、優秀なメンバーが「何でもできる」という勢いでスタートしました。
そこでは、優秀な開発者が集まったからこそ、各自のスタイルでコードを書き進めた結果、可読性が著しく低下しました。自由な技術選定も相まって、チームの人数が増えるにつれ認識の齟齬が不具合に直結し、収拾がつかない事態が多発しました。

そうした散々な経験から得た知見を結集し、我々は独自のアプリケーションフレームワークを構築しました。これは、一般的なシステムで多用される機能を網羅した、フロントとバックの制御機能を持つ標準的なフレームワークです。

構築過程で面白かったのがレビューです。標準機能や制御方法を決める際、モダンな文化で育った開発者とレガシーに精通した開発者とでは視点が全く異なり、両者の意見を共存させる議論は非常に生産的でした。

このフレームワークを導入し、フォーマッターや静的解析ルールを定義することで、コードの表記や構造の一貫性を担保し、開発者間の共通理解を促進しました。結果として、例外処理や排他制御など、属人化しがちな実装が統一され、不具合の削減につながる開発基盤となりました。

アーキテクチャ生産性を高めるには設計段階が重要

アーキテクチャの生産性

アーキテクチャの生産性も、アプリケーション開発と同様の課題を抱えています。こちらは特に、設計段階で時間を使いました。新しい技術を試したい人、手慣れた技術を使いたい人、小さく早く始めることを是とする人、安定性を求めてこれまで通りの技術を選ぶべきと考える人など、多様な文化の衝突に最も苦労しました。

また、非機能要件の議論が長引いて立ち上がりが遅れることもあり、コスト増や競争力低下を招くことにつながっていたと思います。たとえ共通理解を得ても、長期プロジェクトでは徐々にズレが生じ、コミュニケーションを阻害することもありました。

この課題には、パブリッククラウドのベストプラクティスを基にしたボイラープレートを用意しました。物理的に標準化することで設計議論の時間を短縮し、生産性を高めています。

ただし、ボイラープレート自体よりも、それに付随する方式設計のテンプレートを文章化したことに価値があります。「設計を議論する際は、これらの項目を必ず検討する」という論点をあらかじめ定義したのです。
これが議論の時間短縮に非常に効果的で、スムーズな立ち上げを可能にし、標準化されたガイドラインとして生産性向上に貢献しています。

UXの生産性

UXもまた、個性が強く出てしまう領域です。特に分業体制では問題が顕著になり、デザインの統一感を管理できないと、同じシステム内で画面ごとに全く異なるテイストのUIが生まれ、ユーザーにとって直感的でない、価値を届けられない失敗プロジェクトが多々ありました。

そこでコンポーネントライブラリを整備し、全体的な標準化を進めました。もちろんデザイントークンに対応しているため、デザイン部分のみをお客様のプロジェクトに合わせて柔軟にカスタマイズすることも可能です。

開発プロセスの標準化

最後に開発プロセスです。最終的に、お客様との期待値のすり合わせと、将来的な計画の見通しは、開発生産性を最も左右する要素になっています。特に、PoCから始まって継続的に成長するプロジェクトで、後々の要求にどう対応し続けるかの方針決定は、現代のアーキテクチャにおける最難関の一つだと感じています。

期待値は、どうしても「ふわっとした言語」ですり合わせがちです。社内にも多様な職種や経歴のメンバーが増える中、言葉の価値観のズレは文章で埋めるしかありません。

そこで、アーキテクチャのところで紹介した方式設計のテンプレートを、開発プロセス全体に適用しました。フロントエンド、バックエンド、インフラ、CI/CDに至るまで、「何を議論し決定すべきか」という必須項目を整理したのです。



これにより、プロジェクトが小さなPoCであろうと大規模開発であろうと、設計の初期段階で重要な議論が必ず行われるようになります。このテンプレートを提案やヒアリングの段階から活用し、開発プロセス自体の標準化を進めています。

標準化の利点と懸念 - 新しい技術を活用するために

池ノ上：これまでの取り組みは、いわゆる開発標準として体系化されつつあります。正直、過去にSIerとして働いていた頃、仕事の大半がExcel作業になった経験から、私自身は開発標準の整備に強い抵抗がありました。

しかし、必要なものを組み合わせていくと自然と標準が形作られ、今では当社の開発を支える重要なアセットになっています。実のところ、弊社は標準化という思想に強い思いがあります。創業時の「業務プロセスを分析・マイクロタスク化し、現場の難易度を下げる」という文化が会社全体に根付いており、開発部門以外でもプラクティスの標準化や改善活動の横展開が日々議論されています。標準化という言葉を聞かない日はないくらいです。

ただ、どうしても標準化することへの懸念は私自身残っている部分はあります。変化への対応力や創造性の低下を招き、当事者意識を希薄にする可能性がある、という点です。何より、ルールによる束縛は、挑戦的な提案や自由な発想を阻害し、技術進化を遅らせるのではないかと常に懸念しています。

それでもなぜ我々は標準化を進めるのかというと、最大の理由はやはり、毎月数百人規模で多様な文化や常識を持つ人材が入社するという事業環境にあります。この規模の組織をマネジメントするには、トラディショナルな標準化が、生産性の向上に一定の効果を持つことは間違いないからです。

ただし、いくつかの「逃げ道」も用意しています。まず、この開発標準は強制ではありません。まだ運用実績を積んでいる段階であり、標準を使わないプロジェクトもリスクアセスメントの上で許容しています。

もう一つの重要な点が、技術進化です。例えば、最近注目しているDevinのようなAIツールは、指示が曖昧だと不要なファイルを大量に生成したり、可読性の低い複雑な構造のコードを出力したりします。これに対し、方式設計で定めた命名規則や構造ルールをシステムプロンプトとして与えることで、出力の振れ幅を大幅に抑制できることがわかってきました。



このアプローチはまだ実証実験段階ですが、手応えを感じています。技術をそのまま導入するのではなく、標準化を前提とすることで、むしろ新しい技術をうまく活用できるのです。

2月にガートナー・ジャパンが発表したレポートにも、「生産性向上を十分に享受するためには、ツール導入だけでなく開発標準の抜本的な見直しが不可欠」とあります。私個人は標準化が好きではありませんが、我々のような環境では、あえて標準を作りルールで縛ることが、結果的に技術進化を促す効果を発揮できています。

改善活動と情報共有の仕組み

池ノ上：一方で、これまで話してきた日々の改善活動や標準化を生産性に繋げるには、多くの疑問が伴います。それらをここからはご紹介していきたいと思います。

誰がフレームワークをつくるのか？

基本はボトムアップです。現場から生まれた活動が形になった後、トップダウンで支援し「錦の御旗」を掲げてさらに広げる。そして再び現場の改善活動が続く、というサイクルが最も効果的です。トップダウンとボトムアップ、双方の利点を活かすため、状況に応じて使い分けています。

誰が標準を決めるの？

標準はトップダウンではなく、自然競争によって決まります。私たちの唯一の判断基準は「お客様が第一」であることです。

標準化されたアセットを使うべきか、ゼロから作るべきか。提案時にはコストや納期、アサイン難易度などを多角的に検討し、常にお客様のニーズに最適な選択をします。結果として、最も多くのお客様に選ばれたものが事実上の標準となり、利用者が増えることでメンテナンス体制も厚くなり、さらに進化していくのです。

どうやって全社に展開するのか？

毎月百人以上が入社する環境での情報共有には、いくつかのアプローチがあります。
ここではそれらをご紹介します。



プロジェクトライフサイクル管理
プロジェクトは起案から完了、そしてポストモーテムまで一貫して管理されます。特にポストモーテムでは、成果物や生産性向上の工夫、ボトルネックなどを営業から役員まで幅広い層に報告するため、重要な情報共有の場となります。

社内技術発表会
年数回開催する技術発表会やプロジェクト報告会は、当初の「成果を称賛する」目的を超え、「温めているネタを共有したい」というエンジニアが集う技術研鑽の場へと進化しました。ここで発表されたアイデアが営業やコンサルの目に留まり、実際の大型案件に繋がり、一つの事業として成長した例もあります。

学習とキャリアパスの連動
公式な情報ポータルに加え、現場主導のコミュニケーションチャンネルも活発です。学習を促進する仕組みとして、独自のキャリアUP制度「トップガン」を設けています。自社の標準プログラムや方法論の習熟度を測るもので、合格や改善提案の実績が自身のキャリアアップに繋がります。

どうやって陳腐化を防ぐのか？

陳腐化は、組織構造によっても防いでいます。当社は事業本部制をとっており、現場での裁量権を強めている、マトリックス型構造です。

縦の組織である事業本部のインダストリー系は、業界特化の専門家集団です。業界固有のトレンドや特徴把握に長けており、顧客の課題解決やプランニングを担い、会社の売上（P/L）責任を持ちます。

そして、私が所属する横の組織であるソリューション本部は、技術フォーカスの組織です。こちらも売上目標をもっておりますので、トップラインを伸ばすことにおいてもエンパワーメントは効くのですが、それに加えて、技術にコミットしているので、「特定技術を進化させる」というミッションが組織目標として明確に設定されています。なので、個別施策が個人ごとにとられており、それが自発的な技術向上を促しています。

この構造により、ソリューション本部は常に技術の陳腐化を防ぎ、進化させることを追求します。さらに、人事評価制度においても、改善への貢献度を定性・定量の両面から評価する仕組みが、全社的な改善活動を後押ししています。

活躍した人たちをどうやって評価するのか？

最後に最も重たいテーマ、工夫をした人の評価についてお話しします。

私たちの評価の基本は、市場に連動した絶対評価です。そのスキルや活動が市場やお客様にとって価値があるかが最も重要です。これを支えるため、技術力や知識を「教える力」「発信する力」「深掘りする力」といったKPIに分類し、マネージャーやアーキテクトといった多様な役割ごとに評価します。お客様から提示される市場単価も重要な情報源とし、これらの方程式によって年収の目安が決まります。

この仕組みは、市場価値が確立されたスキルには有効ですが、「これから価値が生まれるか」という新しい取り組みの評価には不向きです。

こうした方程式に当てはまらない人たちの評価は、役員全員が参加する評価会議で徹底的に議論します。マネージャーがその人材の取り組み内容、技術的難易度、将来性をプレゼンし、評価を決定します。

この会議には年間1,000時間以上のコストをかけていますが、会社の進化に不可欠な人事制度を更新するための重要な投資と捉えています。マネージャーにとって、既存の評価軸から外れる優秀な人材を推薦し、その価値を役員に認めさせることは、自身の成果に直結する極めて重要な業務です。



日経ビジネスの記事に掲載された「部下の給与を上げられない上司は不要」という言葉は、まさに当社の姿勢を象徴しています。

まとめ - 標準化という基礎に立ち返ること

池ノ上：開発生産性向上のため、あえてトラディショナルな標準化という手法という基礎に立ち返ることは有効だと考えています。その上で、現場の力を最優先に、

• 欲しいものより売れるもの
• 計画より実績
• 調整よりスピード

を重視してきました。
今後は事業フェーズの変化に合わせ、メンテナンス性や保守性も強化していく予定です。



本日はご清聴ありがとうございました。

アーカイブ動画も公開しております。こちらも併せてご覧ください。
※ご視聴には登録が必要です