成長の裏側にあった、カルチャーの衝突

SHIFTの原点は、ソフトウェアテスト工程の業務分析・業務分解です。これによって、ITの知見が浅い人でもプロジェクトに貢献できる仕組みを確立し、ソフトウェアの品質保証・テスト領域で急成長を遂げました。

転機が訪れたのは、2017年のことです。SHIFTはそのノウハウを活用し、DXを推進する総合SIベンダーへと事業の舵を切ります。

開発ソリューション、アジャイル開発支援、DevOpsコンサルティングなど、事業領域を急速に拡大しました。

「幸いにして、非常によいお客様に恵まれ、右肩あがりに事業成長ができました。経営陣からの理解も得られ、採用も加速し、勢いが非常にありました。」と池ノ上は振り返ります。

事業領域の拡大に伴い、SHIFTには実に多様なバックグラウンドをもつエンジニアが集結しました。

優秀な人材が集まることは喜ばしい反面、組織内には多種多様なカルチャーや開発スタイルが混在することになりました。

多様な個性を尊重しつつも、組織全体の生産性を底上げし、品質を担保するための「共通のものさし」がSHIFTには必要だったのです。

池ノ上は、「開発者ごとに異なるスタイルやアプローチでコードが書かれており、可読性が低下していました。開発者間での認識の齟齬は、不具合に発展します。

これが要因となってプロジェクトに問題が発生したり、当初想定していた工数見積もりを大幅に超えたりといった事象は避ける必要がありました。」と説明します。

この課題を解決するために、SHIFTは「あえての標準化」という戦略を実施。

これは、個人のスキルやセンスに頼るのではなく、組織としての「型」をつくることで品質と生産性を底上げするアプローチです。池ノ上は、その中核をなす4つの武器を紹介します。

コードの“クセ”をなくすアプリケーションフレームワーク

最初にSHIFTが取り組んだのは、コードの一貫性を保つための、アプリケーションフレームワークの構築です。

「システム開発で使われることの多い機能を網羅する形でレイヤー構造にし、フロントエンドとバックエンドそれぞれに制御機能を用意しました。

モダンなカルチャーで育ってきた方とレガシーなカルチャーで育ってきた方、双方の視点を取り入れています。これらを共存させるための議論はすごく効果的でした。」と池ノ上は語ります。

このフレームワークには、フォーマッターや静的解析ルールが組み込まれており、コードの表記や構造の一貫性が担保されています。

特に個人の癖が出やすい例外処理や排他制御といった部分を共通化することで、不具合の発生を劇的に削減しました。

認識のズレを防ぐ「方式設計テンプレート」

次に課題となったのが、アーキテクチャ設計での時間のロスです。

「小さくはやくはじめることを美学としている方と、『枯れた技術で安定性を求めることが一番だ』という方がいます。カルチャーの差は一番苦労するところでした。」と池ノ上は語ります。

特に、非機能要件を先読みするための議論に膨大な時間を費やし、プロジェクトの立ち上げが遅れるという問題が頻発していました。

これを放置していると最終的にコストに跳ね返り、お客様の負担増やSHIFTの競争力低下につながってしまいかねませんでした。

そこで、SHIFTは物理的な「ボイラープレート」（テンプレートコード）と「方式設計テンプレート」という2つの標準を用意しました。

方式設計を考えるときに議論すべき項目があらかじめ定義されていることで、エンジニアは迷うことなく本質的な議論に集中できます。

これにより、プロジェクトのスムーズな立ち上げと、開発者間の認識のズレ防止を実現しました。

デザインのバラつきをなくす「コンポーネントライブラリ」

UX（ユーザー体験）もまた、個人のセンスに依存しがちな領域です。分業が進むと、同じシステム内でも画面によってデザインのテイストが異なり、ユーザーを混乱させてしまうケースがありました。

そこでSHIFTが導入したのが、コンポーネントライブラリです。

その結果、個々のデザイナーやエンジニアのセンスに頼らず、統一されたUXを実現できるようになりました。

期待値のズレを防ぐ「標準設計テンプレート」

最後に、開発プロセス全体を通じた標準化にも取り組みました。特に課題となっていたのが、お客様との期待値のすり合わせです。

この課題に対して、SHIFTはアーキテクチャ設計で用いていた方式設計テンプレートを、さらに上流の提案フェーズから活用するというアプローチをとりました。

上流工程から具体的な項目に基づいて議論することで、曖昧な言葉を使うことで起こる「すれ違い」を防ぎ、お客様と開発チームの間に強固な共通認識を築く。

この仕組みが、手戻りをなくし、プロジェクト全体の生産性を劇的に向上させました。

「標準化」への葛藤と、効果的な導入戦略

この標準化戦略を推進してきたVPoEの池ノ上自身も、かつては「標準化に強い抵抗感を抱いていた」と前置きし、「エンジニアとして仕事をしているはずが、やっていることはほとんどExcel作業だった。

『こんな仕事をしたかったわけじゃない』と若いころに感じていたため、開発標準の整備には疑問をもっていました。」と明かします。

池ノ上は「標準フレームワークを導入することの懸念点」を改めて整理しました。

• 変化への対応能力の低下
• 創造性の阻害
• オーナーシップの喪失

標準フレームワークというルールで縛ることによって、自由な発想や挑戦的な提案が阻害されるのではないか？技術進化が遅れるのではないか？という懸念をもっていたといいます。

しかし、上記のような懸念をもちながらも、毎月100人規模で入社してくる多様なバックグラウンドをもつメンバーを効率的に機能させるには、標準化というトラディショナルな手法が一定の効果を発揮すると池ノ上は判断しました。

「ただし、SHIFTではすべてのプロジェクトに開発標準を適用しているわけではありません。開発標準を使わなくてもいいプロジェクトに関しては、リスクアセスメントをしながら推進すればいいと考えていました。

こうした柔軟性があるからこそ、現場は標準化を『押し付けられたもの』ではなく『便利な道具』と受け入れてくれたんだと思います。」と池ノ上は振り返ります。

また、池ノ上は最新のAI技術の活用を通じて、標準化の新たな価値を見出したと続けます。開発特化のAIエージェント「Devin」での実証実験です。

あいまいな指示では出力が安定しないAIに対し、SHIFTの開発標準で定義したルールとテンプレートをプロンプトとして与えることで、出力の精度が劇的に向上することがわかりました。

池ノ上は「多くの開発技術を革新的に進め、生産性の向上を十分に享受するためには、ツールを導入するだけでなく、開発標準の抜本的な見直しが不可欠」と述べます。

一見トラディショナルな手法が、最新技術の効果を最大化する鍵となるのです。

SHIFT定番の「ボトムアップの改善活動」

SHIFTの「標準」は、誰かがトップダウンで決めたものではありません。そのほとんどは、現場のエンジニアによるボトムアップの改善活動から生まれます。

「トップダウンで何かを行うこともありますが、SHIFTにおける正攻法ではありません。ボトムアップで推進し、ある程度形になったものの活用を、トップダウンで支援する。

すると、さらに活用されるようになる。成功体験を積んだ現場が、また改善に動いてくれる。こうした進め方がSHIFTでは定番です。」と池ノ上は経験則を語ります。

では、現場から寄せられる数ある改善活動のなかから、何を基準に「標準」が定められたのでしょうか。池ノ上はこう語ります。

「標準は誰が決めているのか。これについては、経営層が行っているわけではありません。

お客様にプロジェクトを提案する際に、ゼロからフルオーダーでつくる方がいいのか、あるいはコスト交渉力やアサイン難易度といった点を解決するために、ある程度テーラーメイド化された標準を使った方がいいのか、さまざまなパターンで提案・検討し、結局はお客様のニーズに合わせています。

『お客様に選ばれるもの』が生き残るんです。」

お客様に選ばれたツールやフレームワークは、ユーザーがどんどん増える。

そして、フレームワークをメンテナンスできる体制が厚くなり、さらなる進化を遂げる。SHIFTには、こうした好循環が根づいています。

標準化を全社に定着させるには

毎月100人以上が入社する急成長環境で、標準化や改善活動を効果的に広めるには、強力な情報共有の仕組みが不可欠です。SHIFTでは主に2つのアプローチでこれを実現しています。

1つ目は「プロジェクトライフサイクルマネジメント」です。

プロジェクト完了後の「ポストモーテム（事後検証）」では、「今回の工夫で、これだけの生産性向上が見られました」といった成果が共有されます。

このセッションには、プロジェクトメンバーだけでなく、営業やマネジメント、場合によっては役員も参加するため、よい実践が組織全体に伝わりやすい環境となっています。

2つ目は社内技術発表会「テクシェア」です。

池ノ上は、「年に3回開催されるこの発表会は、当初はプロジェクトのねぎらいや優秀な従業員の称賛を目的としていましたが、『温めているネタをみんなに見せつけてやる』みたいな人が現れるんです。」と笑顔で語ります。

これがきっかけで新たな事業が生まれたり、部門が成長したりする事例も出てきたといいます。

エンジニアの称賛が情報共有の場へと発展する、この「うれしい誤算」が、イノベーションの好循環を生み出しているのです。

この文化を支える最後の要が、エンジニアを正当に評価する人事制度です。

SHIFTの評価の基本は、「市場に連動した絶対評価」。スキルや活躍が市場でどれだけ評価されるかが、直接処遇に反映されます。

しかし、この仕組みだけでは、まだ市場価値が定まっていない新しい挑戦を評価することはできません。そこで設けられているのが、「評価会議」です。

「その人の取り組みの内容、技術的な難易度、市場価値、将来性などを、役員一同、会社のステークホルダー、意思決定者が全員揃った状態で議論します。

評価会議にはリソースを割いており、1,000～1,200時間費やします。

会社が発展するには人事制度も進化しなければいけません。『評価の方程式』を考え直す機会として、全員がこの1,000時間というリソースを受け止めています。それが事業の成長の仕方だと考えています」

これからSHIFTでチャレンジしていきたいこと

池ノ上は「私たちの取り組みを振り返ってみると、重視してきたことは『ほしいものより売れるもの』『計画より実績』『調整よりスピード』という3点でした。

いまの段階まで来たからこそ言えることも多くあると思います。」と述べました。

エンジニア組織の強化と開発生産性向上に向けた取組みをつづけることで、「まずは、標準化活動の割合を増やすこと。今後、SHIFTのアセットはさらに大きくなっていきます。

それに伴って、保守・運用フェーズに積極的に投資していく構えです。

次に、基礎技術を研究すること。企業フェーズに合わせて、間接的な貢献活動で付加価値を創造していきます。

最後は、これらを行うための制度設計です。膨大な時間を使って議論、解決していることを仕組み化していきたいと思います。」と語り、池ノ上は発表を締めくくりました。

（※本記事の内容および取材対象者の所属は、イベント開催当時のものです）