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

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

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

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

カンパニー長にもITの責任を感じてもらう

最後は「マインド」についてです。

これまでお話してきた組織体制や開発スキームはIT組織やそのパートナー企業に関するものでした。

しかしIT組織だけでなく、発注元となる事業サイドも同じマインドを持ってもらうことが非常に大事です。

事業の責任者、弊社でいうカンパニー長は、例えば営業や代理店さんで問題が起きたときには、それを自分の責任のように考えています。

しかしITに関しては、うまくいかなくて失敗したときにIT部門が失敗したと思う。ここが大きな課題としてあって、ITの成功や失敗も事業責任者が自分の責任だと感じるのが非常に大事だと考えています。

IT部門が責任を追及する対象となって「なんで失敗したんだ」と追い詰めてしまうと、IT部門はうまくいっていないことを報告しにくくなりますし、報告しても「なんとかするって言ってたじゃないか」と言われる。これが大きな失敗の元です。

そこで事業の責任者には考えを変えてもらうようにしました。要するに、システム構築が失敗したら自分の査定が落ちることなのだと。

これで何が起きたかというと、事業責任者がITの勉強を始めました。また、開発部門が言いたいことが言えていないのであれば、言えるような環境作りをするよ、となりました。

結果として、とある大規模開発において要件定義が収束しないという状況に陥ったとき、従来ならIT組織の方から納期や要件を再交渉しなければならないところを、事業部門の方からカットオーバーを延期すべきと言う提案がなされ、プロジェクトの成功につながりました。

このように事業側のマインドも揃えてもらい、プロジェクトリスクをIT組織でクローズさせない、ということがソフトウェアの品質にとって非常に大事です。

まとめ

ソフトウェアの品質には、組織体制、開発スキーム、マインド。この3つが重要だと思っています。

そして体制やスキームはつねにビジネスとともに変化します。一方で、みんなで良いものを作る、というマインドは変わらないと思います。

質疑応答

（会場から質問） 私も事業側の意識を変えるのにいつも苦労しています。なにかコツはありますか？

（回答） 私も非常に苦労しました。幸か不幸かプロジェクトが失敗し、その振り返りに時間をかけて、社長会にもかけて、研修をしたり、失敗プロジェクトにおいて事業責任者のどの判断が影響したのか、まで振り返りました。

また「IT投資を成功させるための37の掟」という小冊子を作ったりもして、非常に手間をかけました。

われわれは1つのプロジェクトの失敗を通じて、なぜ失敗したのか、どういう問題がそこにあったのかを検証し、啓蒙しました。その教訓はきわめて真っ当な話であって、失敗しなくてもちゃんと成功へ進む道はあったのかもしれません。しかしそのリアリティを作ってくれたのが失敗という経験で、これが意識の変化を加速してくれたと思います。

だから他社でも弊社の事例などを使って事業側の意識の変化を伝えるのは大事ではないかと思います。

（会場から質問） 80％ルールについて。精度を落とした結果、それが原因であとで問題が起きたことはありますか？

（回答） 結果としては、分からないというのが答えです。80％ルールにすると、本来やろうとしていたことが10だとすると、8しかできずにリリースするということもあります。ただ、新しいビジネスを始めるときには何が正解なのかは分かりませんので、何か見落としていることがあったとしても、それも分からない。

ただ、ここで重視するのはスピードであって、確実にスピードを上げることはできた、ということは言えます。

（会場から質問） オフショアは現地でコントロールすることが成功の要因だというお話でしたが、それでも言葉や文化の違いは大きくて、現地に社員が常駐してもまだ壁があるのではないかと思います。また、オフショアの開発範囲を広げるのはどうやって進めたのかも教えてください。

（回答） おっしゃるとおり、文化や言葉の違いの壁は非常に大きくて苦労しています。結局、日常的には英語でやっていても、細かいところを英語では伝えるのが難しくて通訳も使ったりしています。

壁をどうやって乗り越えるかというと、単純に現地に滞在するだけではなく、オフショアの末端の工程まで、設計書の書き方やコーディングの仕方まで、基本的には日本のやり方を英語にして持って行って、それを彼らに合わせています。そうやって現場の努力で越えていくしかないのではないでしょうか。

それ以外にも、開発プロセスの中でバグ撲滅キャンペーンをやって成績を壁に貼って表彰するといったリクルートでやっていたことはやっていますし、誕生日にはケーキを持っていくとか、メンバーの両親に花を贈るとか、細かいこともやっています。

開発範囲を広げるときには、範囲を広げてくれますか、ではなく、こうやって広げるよと教えていくんです。ポイントは、よろしくって投げない。手取り足取り各論で教える。発注者と受注者ではなく、家族になるというのを必死にやるということだと思っています。