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

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

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

本記事は「組織編」「開発スキーム編」「マインド編」の3部構成です。いまお読みのページは「開発スキーム編」です。

品質優先、納期優先、コスト優先など5つのスキームを用意

次は開発スキームについての話です。

プロジェクトを推進するときにはQCDについて、バランスとプライオリティで判断するのが大事です。当たり前ですが、弊社の各事業部にもこの3つの指標のバランスで計画を立てて判断するのが大事です、ということを何年も啓蒙し続けています。

現在、リクルートには5つくらいの「開発スキーム」ラインナップがあります。

1つ目は「大規模型」で、品質を優先するスキームです。

機能別組織ができる前は大規模開発スキルの標準もなくいろんな問題が発生して、うまくいかないことが多発していました。

そこでプロジェクト推進部というところで、システム開発標準を作ってきました。プロジェクトの定義フェーズを設け、成果物、フェーズ、完了基準などを定め、進捗と品質の見える化を行い、専門部隊が管理、監査をしていく。これらを組織的に担保する仕組みも作りました。

結果的に18プロジェクト、のべ8000人月くらいの開発をほとんど失敗なくできて、リクルートの看板商品を数多く作ってきました。

2つ目は「エンハンス型」で、アジャイル開発スキーム「SWAT」と呼んでいます。納期に特化したスキームです。

リクルートの新規ネットサービスを立ち上げるときに主に使われていて、弊社の中ではウォーターフォールを使うより2～3倍の生産性です。

弊社はもともと情報誌を作るシステムが中心でした。情報誌は印刷して全国の本屋さんに並んだあとでは絶対に直せません。だから絶対に間違えてはいけないためのシステムでした。

しかしネットの世界では、サービスを始めててみないと分からないことがたくさんあるので、従来の方法ではできるだけたくさん要件を実現しつつ完璧にしてからシステムをリリースするのですが、Webでは最低限の機能を入れて早く出すのが大事だということに気がつきました。

開発スピードを上げるためにどうしたか

開発スピードを上げるにはどうするか？ パッケージやテンプレートを使う方法も考えましたが、「アジャイル憲章（アジャイルソフトウェア開発宣言）」というものに出会いまして、これがわれわれの会社にも合っていたので、じゃあこれを採用しようと勉強したうえでリクルートのスキームを作りました。

アジャイル開発スキームを実現する上で、いくつかの課題がありました。

まず事業側のマインド。これまでは事業側は発注者、開発側は受注者というスタンスで、いちど開発側が「できます」と言ったことは、どんなことがあってもやらなければいけないという文化でした。

だから開発側はどんどん慎重になっていきますし、開発の途中で問題が発生しても事業側が「はじめにできるって言いましたよね？ じゃあやってもらわないと」というように相談できないような非建設的な関係でした。

これを変えなければいけないと。

従来のやり方は、カットオーバー時点で100％の完成度を目指します。しかしまずカットオーバー時期と工数を決めて、その範囲でやるのがSWATの中心です。ここは大きく従来の考え方を変えました。

受発注の関係からの脱却は、協力会社も含めて全体を1つのチームにして、同じ部屋に集めるということもやりました。

「80％ルール」というのも実践しています。これは事業側の関係者と開発者が80％程度の精度を意識してものごとを決める方法です。例えば仕様を100％出すとか、受けたものが100％できるか検証する、となると時間がかかるので、80％の精度でお互いに先に進めましょうと。

「機能を追加したいのですが大丈夫ですか」というのは開発の途中でよく起きます。でもその場で「できそうですね」と回答するとやらなくてはならなくなるし、「できません」と回答すると、やる気はあるのか？ ということになる。だからだいたい「持ち帰って検討します」となってしまって検証することになり、時間がかかる。慎重に時間をかけるよりざっくりとその場で判断して先に進んでしまう方がいい。

また追加機能のときにはほかの機能を減らして納期を守ることになりますが、工数の再見積りを厳密にやるのは無駄なので、だいたいこの辺の機能を削ればできるのではないか、といったことを80％の精度でやろうと。

総工数ベースのスコープ管理。スコープがぶれて収束しない、という課題に対しては、バーンダウンチャートを使って上限ラインによって要件の許容範囲を確認。ユニットごとに張り出して日々確認することで、全員の意識合わせをしています。

コスト重視型はオフショアを採用

3つ目の「コスト重視型」はオフショア開発スキームを使います。さまざまな項目を検討して、私たちはベトナムを使うと判断しました。

オフショアは過去なかなかうまくいきませんでした。その理由を調べてみると、だいたいこの5つでした。

そこで、この5つの課題を全部逆にする取り組みをしました。

開発工程全般をオフショアに出し、現地法人とは直接契約。テレビ会議は使わず、弊社の社員が現地に常駐し直接コミュニケーション。ブリッジSEはおかず、社員が現地で直接確認。通訳はせず、双方が英語で話します。

第一号案件は70人月程度のシステム規模でしたが、予想以上にうまくいきました。

コスト重視で生産性を上げる意味だけでなく、社員育成の場としても機能していたのは嬉しい誤算でした。もともとベトナムのSEは非常に意欲が高く、現地社員もそれに触発されて伸びていったようです。

4つ目の「短納期型」では、スマートデバイスアプリ開発スキームを進めています。

これはスマートデバイス横断チームを作って行った取り組みです。スマートデバイスではデバイスの制限があるのでアプリケーションがどれも似ており、モジュールの横展開がやりやすい点が、いい結果につながっているようです。

5つ目のハイブリッド型は、大規模型とアジャイル型を混ぜたやり方です。バックエンドの業務は大規模型、フロントエンドのWebはSWATで作るという取り組みも最近やっています。

これまで紹介した5つのスキームを用意して、プロジェクトのQCDの優先順位によってどのスキームにするかを選択しています。

≫続く「マインド編」では、事業責任者のマインドをいかに変えていくかを解説しています。