組織の成長過程で発生した課題

ソフトウェアの「品質保証」を起点にお客様のサービスづくり全体を支援しているSHIFTは、製造業における業務改善コンサルタンティングのノウハウを活かし、業務プロセスを分析して生産性向上の取り組みを進める点に強みをもっています。

売上高は、FY2017からFY2024にかけて13.5倍に成長しており、ソフトウェアテスト以外のITサービスも順調に成長していることが紹介されました。

一方で、数字的な成長の裏で課題としてあったのが「エンジニアリングマネージャーの不在」です。課題の要素としては以下の3点があげられ、それらについて一つひとつ説明がなされました。

「個人の成長」にまつわる課題と対応施策

特にエンタープライズの大規模なプロジェクトになると、エンジニアがプロジェクトごとの業務で必要な技術を場当たり的に習得するため、全体像の理解や体系的な知識の構築が遅れる傾向にあったといいます。

その結果、設計原則や技術の本質を深く学ぶ機会が減り、長期的な成長が阻害される要因になることが懸念としてありました。

そこで取り組まれたのが、「次に修得すべき技術要素の整理」です。エンジニア一人ひとりが学ぶべき技術のロードマップを描いてあげることで、長期的な成長を支援し、それを目指すための「スキルツリー」を作成していきました。

そして、それが社内で意外なもりあがりを見せたと池ノ上は説明します。

「SI、セキュリティ、ERP、DevOpsなど各分野のプロフェッショナルに整理したスキルをみてもらいました。すると『ここが全然足りないよ』という意見が続々と出てきました。

『キャリア形成の面でも事業成長の面でも、自分たちに必要なスキル・経験は何なのか？』という議論が面白くて。エンジニアたちはすごくもりあがり、自分たちのキャリアがどんどんと拓けていくような感覚を覚えました」

そんななか、習得・経験したスキルを評価制度・教育制度へと反映しようという動きが出てきて、そこで「立場によって捉え方が異なる」ことを痛感したと、池ノ上はつづけます。

「普段からエンジニアとしてモノづくりをしている人たちと、それを評価している人たちとでは、みえ方がどうしても違うことが多くありました。

そして、視点の違いというのは人事だけでなく、営業やバックオフィスなど、さまざまなところに存在していました。

そのときに、『これは会社全体の理解／文化の問題だな』と感じたことから、マネジメント層とIT技術をテーマに議論する場を設定することになりました」

ここから、マネジメント層がエンジニアを理解しようとする姿勢が生まれました。

このように書くと、以前はマネジメント層によるエンジニアへの理解がなかったように感じるかもしれませんが、そんなことはないと池ノ上は強調します。

SHIFTは「多重下請け構造を打開して、国内IT業界を効率化したい」という考えのもと、同一労働には同一賃金を支払いたいという、エンジニアに寄り添った思想をもち、人事制度や施策に反映していました。

それがいつのまにか、エンジニアの実力を「受注単価で評価する」という、結果論でしかない評価軸になりかけた時代があり、新たな評価制度に関する議論が必要と判断されました。

「技術力を評価するための議論として、技術スタックとロールにわけてそれぞれの評価要素／パラメーターを整理していきました。

その結果、最適な計算式が生まれたのですが、そこで弾き出される数値はあくまで中央値としての想定年収であり、そこからエンジニア個人に合わせてフィードバックをするという仕組みの評価制度にしています。

このようにして、エンジニアの成長を最大化できる機会をつくる制度にしていきました」

「キャリアプラン」にまつわる課題と対応施策

個人の成長にも重なる話ですが、エンジニアの案件参画が営業の引きあい依存になるケースが多いことから、アサインに振りまわされてしまい、長期的なキャリアプランが描きづらい状況がありました。

「これも、会社の成長に伴う成長痛でした。新しいサービスが次々とリリースされるなかで、つねに人材不足でした。

現場のエンジニアが技術的に大きな背伸びをせざるをえない／アサインが決まらないケースもあり、組織的なハレーションが生まれていました」

さまざまなヒアリング／議論をへてわかったことは、営業サイドは「困ったときに誰に相談していいのかがわからない」ということでした。

そこで、ソリューションを支える体制を可視化すべく、「ソリューションツリー」を作成して会社で共有しました。

「もともと我々のコアバリューはプロセス／スキルの分解、標準化であって、それがたまたま、テスト設計・実行・管理というソフトウェアテストのソリューションではじまりました。

そのなかからテスト自動化や継続的インテグレーションというムーブメントがあり、そのうち「もっと付加価値を高めよう」、さらには「DevSecOpsをやろう」、「それが一番活かされるのはウォーターフォールではなくアジャイルだよね」という一連の流れがありました。

このような動きのなかで、当然ですが体制が厚いところと薄いところ、つまり安定して案件を受けられるところと、つねにチャレンジングなところというチームごとの違いが出てきました。

そういったリソース調整は営業といっしょに会話しながら進めていこうということで、ソリューションツリーを通じた会話が増えていき、結果として、営業とエンジニアのアライメントが生まれるようになりました」

「チーム形成」にまつわる課題と対応施策

多くのエンジニアリングチームのあるあるとして、プロジェクトでの経験・実績がプロジェクト内に留まり、組織全体に展開されないことで、属人化や知見の断絶が生まれ、開発の非効率化や技術的負債の蓄積を招く状態の発生があげられます。

この組織課題を解決すべくはじまったのが、品質担保を目的にスタートしたプロジェクトライフサイクル活動です。

「これを徹底することで、開発品質のばらつきが可視化されていきました。それでまず、比較的一般的なアプローチではありますが、開発標準をつくっていきました。

実は以前からつくっていたのですが、現状あまり使われていない事実を目の当たりにし、改めて整備を進めました」

その結果、設計ガイドライン／生産性指標などを活用した提案活動や、見積もりにも再利用可能なコード／フレームワーク／ボイラープレートを活かすなど、個人の経験と知識に依存した体制から、形式知としてノウハウを蓄積・活用できるようになりました。

「これを運用するためにCoE（Center of Excellence：センターオブエクセレンス）活動をしていたのですが、そこで費用対効果の話をされるんですよね。本当に効果があるのかと。

安定的に運用していかないと、活動がたち消えになってしまいますし、何よりCoE参画者のキャリアを考えて彼らにはしっかりと売上責任をもってもらうことにしました。

つまり自社がもつ技術の優位性や、ノウハウの有効性をお客様に説明してプリセールスとしての役割をもってもらったんです。

これによって、事業に貢献しているという立場が守られるので、運営として安定しますし、ご本人にとってもキャリアになるという設計です」

技術とビジネスが共鳴する組織の、その先へ

「ビジネスとテクノロジーの対立構造」のような話はよく耳にしますが、実際にはそこまで対立関係にはない、と池ノ上は述べます。

「いままでふれてこなかった新しい情報／分野に飛び込んでいって理解しようという人と、そうではなく自分の領分をしっかりと守りたい人の対立構造はあると思いますが、それがビジネスとテクノロジーの対立かというと、それは違うんじゃないかなと思っています。

これまでは、そういう対立の基になるようなものを一生懸命解いていった日々だったのかなと思っていますし、ビジネスとテクノロジーが溶け合っていることが、ここまで会社としてうまくいっている大事な要素だったんじゃないかなと思っています」

評価制度が整い、目指すべきスキルセットやキャリアプランが明確になった結果、勉強会やコミュニティが自発的に複数生まれるような、エンジニアが輝ける組織になったと池ノ上は強調します。

そのうえで、今後取り組みたいこととしては以下の4点であると、池ノ上は強調します。

※左上の「テックリード以外のエンジニアのポジション」に関しては、以下の記事もあわせてご参照ください。

「これらをどうやって実現していくかはまだまだ検討中です。イメージとしては、CoE組織がこのような機能をもつようになってくれたらいいなと考えています。

そのうえで、みんなが同じゴールを目指したいと思ってくれて、それに向けた制度／KPI／仕組みをつくりたいというのが、目下考えていることです」

登壇資料はこちら

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