リクルート、進化を止めないIT現場力 システム開発のリアル

米谷修

「リクナビ」「SUUMO」「ホットペッパービューティー」――。各ジャンルで国内最大規模の利用者を抱えるこうしたネットサービスを、いくつも手掛けるリクルート。実はそのほぼすべてを、同社が自前で設計・開発・運用していることはあまり知られていない。
これまでの同社のイメージは、「R25」「ホットペッパー」「じゃらん」「カーセンサー」といった情報誌を次々生み出してきた企画力や、顧客企業に切り込んでいく営業部隊の強さ。それは今も昔も変わらない。

ただ、大胆な戦略転換によって、日本随一のテクノロジー企業へと変貌を遂げたのが現在のリクルートの正しい姿だ。

では、新生リクルートの強さの源泉はどこにあるのか。グループのIT施策全般を担うリクルートテクノロジーズで、司令塔として采配を振るい続けたＣＴＯ（最高技術責任者）が、その全貌を明らかにする。

• カテゴリ: ビジネス・実用
• ジャンル: ビジネス・経済 / ビジネス資格
• 出版社: 日経BP
• ページ数: 184ページ
• 電子版発売日: 2016年10月07日
• コンテンツ形式: EPUB
• サイズ(目安): 4MB

[ブクログ · ★★★★★]

各論が大切というのは当たり前だけど難しい。マネジメント層になって、各論を知らない業務を担当するとき、この方はどうしているのかと気になる。

[ブクログ · ★★★★★]

リクルートテクノロジーズのCTOが自身のIT事始めから連発する大胆なチャレンジを振り返り、後進の育成や組織づくり、そしてわくわくする未来に向けての新たなチャレンジ（宇宙開発にまで関わっているのには驚きです！）を熱く語ります。
フィクションとしていくつか逸話が挿入されてますが、ノンフィクションにリライトできそうなところもあり、幾分の懐かしさ感じながらも熱い思いに引き込まれて一気に読みました。
特に、厳しくも愛のあるエンジニアの育て方にはとても感銘を受けます。すべての企業が「IT企業」になると言われている昨今、必読の書です。

[ブクログ · ★★★★☆]

様々な取り組みを恐ろしいくらい早いスピードで
実現していっているリクルートグループ。
そのリクルートグループのITを取りまとめるのが、
リクルートテクノロジーズ。

取り組みもそうだが、
取り組みが出来るメンバーを揃えるというか、
育成する取り組みとしてどんなことをやっているのか？
を紹介してくれていました。

正直当たり前だなと思う取り組みもありましたが、
当たり前の取り組みを愚直に実践するということが、
逆にリクルートグループの強みなのかなあとも思った。

あと、結構泥臭いんだなとも感じたが、
泥臭くやることが成長の近道なのかなと感じた。

【勉強になったこと】
・問題解決が出来るようになるには各論を知るしかない。
　各論とは、ゴールやゴールに至るまでのプロセス。
　開発プロセスの定義の仕方から始まり、
　プロジェクト管理のあり方、
　コーディングルールやテスト方法、
　品質指標、インフラ選定といった各種プロセスのこと。
　これらを理解しなければ、解決に何をすればは見えない。

・プロジェクトマネージャーは
　プロジェクトを管理してればよいというわけではない。
　場合によっては、自分が動くという決断も必要。

・圧倒的当事者意識を身につけること。
　なんのことかというと、
　私はこれしかやりませんみたいな意識ではダメで、
　お客の立場に立って考えるという姿勢が大事。
　足りないなら補おう、補うパワーが無いなら、
　他を止めてでもやる必要があるのかをお客の立場で
　考えられるようになるのが大事という意味だと思う。

・オフショア開発の課題
　①委託する工程が短いと効果が薄くなる
　②オフショアといっても間に関係会社が多数絡み、
　　コミュニケーションが取りづらい
　③テレビ会議では得られる情報が少ない
　④ブリッジSEを介すため、認識ずれが起きやすい
　⑤通訳によるコミュニケーションずれが起きやすい

・マネジメントの基本は報告・連絡・相談
　当たり前のように思えるかもしれないが、
　オフショアでは意外と徹底されない。

・異なる文化の組織が団結するためには、
　何度も話し合いを実施するしかない。
　時間はかかるが、お互いを理解する一番の近道は、
　腹を割って何度も話し合うこと。

[ブクログ · ★★★☆☆]

システム開発への方法論に感激。大賛成！

　こうした状況からの脱却を目指してまず打ち出したのが、従来とは真逆のアプローチ、すなわち「自分たちで手を動かすこと。」仕事を決して他人任せにせず、絶対に自分の目で中身を見て確かめようと決心したのです。
　要件定義の段階から、自ら誰にも負けないぐらいの業務知識を習得し、要件を漏れなく把握する。開発作業も、自ら手を動かしてプログラムコードを記述し、一行一行に至るまで内容を把握する。そして単体テストや統合テストはもちろんのこと、性能テストも決して他人任せにしない。本当に想定通りの性能を発揮できるか徹底的に確認するために、性能評価も自分たちで行いました。

　私が一貫して主張しているのは、たとえ作業を管理する立場にある者でも、きちんと各論を理解しておくべきだということです。各論に一切踏み込むことなく、プロジェクトの管理タスクだけに終始しても、システムは何とか出来上がるかもしれません。しかし万が一問題が発生したとき、管理する側が各論を把握していなければ、問題の本質を探り当てて適切な判断を下せません。

　何も「末端の細かな作業に至るすべてを自分でこなせ」と主張しているわけではありません。人に任せられる作業は積極的に任せていかないと、大きなプロジェクトを回すことは不可能です。ただ任せるとしても、「その作業を過去に経験しており、いざとなれば自らこなせるので任せている」のと、「自身でできるかどうか分からないまま、丸投げしてしまう」のとでは、雲泥の差があります。

　4つめは、ブリッジSEの存在です。発注元とオフショアベンダーの連携をスムーズに運ぶために、間にブリッジSEを挟むのが一般的です。ここで「伝言ゲーム」が発生してしまいがちです。私自身の経験から、ブリッジSEによって情報が欠落するトラブルが実に多いのです。

　振り返って思うのは、手っ取り早く解決できる「銀の弾丸」はもともとなかったということです。

　例えば、「ウォータフォール型とアジャイル型のどちらの開発スキームを採用すべきか」という対立は、バックエンド部分の開発はプロジェクト推進部流のウォーターフォール型を、フロントエンド部分の開発に関しては事業別組織流のアジャイル型を採用することで決着しました。開発部分ごとに適切な方法論を持ち込むハイブリッド型スキームを編み出したのです。

[ブクログ · ★★★☆☆]

最新本を読んだので、昔の本を再読。
リクルートの本は読みやすい。1時間程度で読める。リクルートならではの力技具体例が多いが、得る知識とかけるコスパのバランスはいい。
各論を知ることが今のIT組織の強み。粘り強く情熱を持って進める。最近の若手世代には難しいんじゃないかと思うシーンもあるが、そのへんはどうなんだろうなあ。