システム品質を左右する「組織体制」「開発スキーム」「マインド」を改善してきたリクルートの苦労を振り返る（組織編）～ソフトウェア品質シンポジウム 2013

システムの品質を左右する要因は何か。リクルートテクノロジーズ 執行役員CTO 米谷修氏は「組織体制」「開発スキーム」、そして発注者を含む関係者の「マインド」の3つが大きな要因であると説明します。

9月12日と13日の2日間、都内で開催された日本におけるソフトウェア品質に関する最大級のイベント「ソフトウェア品質シンポジウム 2013」（日本科学技術連盟主催）の特別講演として行われたのが、米谷氏の講演「進化するIT組織と開発スキーム ～リクルートのサービス開発の事例紹介とともに～」でした。

大規模なシステムを迅速、かつ高品質に、という要求が続く現場で、米谷氏が続けてきた試行錯誤の中で得た知見とは何か。講演の内容をダイジェストで紹介しましょう。

本記事は「組織編」「開発スキーム編」「マインド編」の3部構成です。本記事は組織編です。

進化するIT組織と開発スキーム

株式会社リクルートテクノロジーズ 執行役員CTO 米谷修氏。

システムの品質を決める要素は、大きく3つある、というのが私の持論です。「組織体制」「開発スキーム」「マインド」です。

組織体制はいまでも試行錯誤しています。開発スキームは、自社のビジネスが紙からネットにシフトする中で変わってきました。最後はマインド。特にIT部門に所属するメンバーの意識だけではなく、ビジネスサイド、事業側のマインドがシステム品質に非常に大きな影響を与えることを身に染みて感じています。今日はこれらを軸にお話をしたいと思います。

リクルートというと情報誌や営業力の会社だと思われることが多いのですが、これが2011年までの売上比率のグラフで、現在はさらにネットの売上げが伸びておりまして、ネットとエンジニアの会社という風に急激に変わりつつあります。

リクルートは昨年10月にホールディング制になって、持ち株会社と7つの主要事業会社と3つの機能会社で構成されています。

私がいるリクルートテクノロジーズはリクルートグループのITとネットマーケティングの専門部隊です。

リクルートが展開しているサービス、これらはほんの一部ですが、いくつかのサービスはみなさんも見たり使われたことがあるのではないかと思います。

4つの時代を経てきた組織の変遷

組織について。リクルートにおけるIT組織の変遷は、大きく4つの時代に分けられ、現在は「融合時代2」になっています。

「分散時代」は、まだ紙を中心としたビジネスをやっていた時代でした。ITは営業や企画から要望を聞いてタイムリーに応える。そこでIT組織は事業ごとに個別の現場に配置するのが適していました。

「統合時代」は徐々にネット系の商品が立ち上がり始め、事業ごとの開発量が増え始めました。IT組織を分割していることで分割損が発生したことが気になり始め、徐々に組織を横断的に統合し始めた時代です。

ネットビジネスの拡大とともに、事業ごとにエンジニアを分けているとITスキルやナレッジが分散してしまったり、同じ仕組みを重複して開発する無駄や、チームごとの開発プロセスが違うといったことが課題でした。

続く「融合時代1」は、そういう課題に対応するためのものでした。事業別組織と、横断的な機能別組織の両方を持ちました。

事業別組織は、事業の要望にタイムリーに応えられやすい一方、ITの技術領域ごとに専門性を高めるにはボリュームが足りません。横断的な機能別組織では、インフラ専門、UI/UX専門として専門性を高めやすい。ただ事業との接点が相対的に減るので、事業の個別担当者の要望を受け入れるのは少し難しくなります。その接点を事業別組織が担います。

リクルートのビジネスがネットへとシフトするに従い、ジェネラリスト型の技術者だけではビジネスの要望に応えられなくなってきました。

例えばネットのインフラを企画、設計、構築、運用する部隊。ネットサービスの大規模開発プロジェクトの推進、ビッグデータの部隊も約2年前から活動していて現在100名ほど。事業部のログ解析や新たなリコメンドのロジック開発やネット広告の最適化などをしています。

テクノロジーR&D部隊は先進的な技術をサーチし、ビジネスに貢献するか見極めをします。

これでかなり回るようになりましたが、徐々に事業別組織と機能別組織の考え方の違いによる対立が起きてきました。

IT組織同士が考え方の違いから反目

例えば「計画」という言葉。大規模開発チームでは綿密に計画を立てて、それを守るのが彼らの正義です。ところが事業部別のチームでは、計画は仮決めであって、事業から要望があればどんどん変えていくのが正義です。

両者が会議で、ある項目が「計画で決まったよね？」という議論をしたときに、大規模チームは計画を変えることに抵抗があるが、事業別チームは計画を変えないことに抵抗がある。そこで両者が激しく議論する、といったことなどがいろんな場面でありました。

こうしたことが重なって、お互いのやることなすことが全部気に入らない、というところまで行きました。本当に骨肉の争いのようなところまで行った。

どちらもリクルートのビジネスの成功を支えたい、カスタマへよいものを届けたいわけですが、両者はまったく別の考え方だったわけで、それぞれが一生懸命なほどひどくなっていく。

これをどうやって乗り越えたか、ですが、お互いの主張の押し付け合いをするところから、なぜそういう考え方なのか、その背景をひとつひとつ説明する、ということをやりました。

簡単に書いていますが、結構な時間をかけて研修をやり、お互いを理解し合う、主張を押しつけ合うのではなく、お互いが大事にしている価値観や行動の背景を理解し合うことで乗り越えました。

ソリューションのマトリクスを作り、技術の活用へ

「融合時代2」では、事業別組織と機能別組織のさらなるシナジーを発揮するようにしました。

課題として、事業からの要望とソリューションのマッチが難しかったのですが、打ち手としてニーズとソリューションのラインナップをマトリクス化しました。

こうすると、どのソリューションがどのサービスで使われているかが一覧で見えます。すると、事業側はほかの事業では使っていて、自分が担当している事業では使っていないソリューションがすぐに分かります。そして使っていないソリューションがどう活用されているのかもすぐに聞ける。

機能別側からは、使われていないソリューションがあれば事業側になぜ使われていないのかを聞けます。

こうやってマッチングを向上させていきました。

しかしIT組織に最終形はありません。今年の10月の組織再編でもかなり大きく動かしています。ビジネスの状況に対してどこまで事業別にし、機能別にしていくのかはつねに変化します。それに合わせて進化させていかなければいけないなと考えています。

≫続く「開発スキーム編」では、品質重視、納期重視など、あらかじめ用途別に用意された開発スキームについて説明しています。