リクルート、進化を止めないIT現場力 の商品レビュー

米谷修(著者)

2020/04/11

・各論を理解しないとダメ
・ati圧倒的当事者意識
・オフショア開発→直契約、現地派遣
・プロ推と事業との対立（機能別組織と事業別組織）
・フロント側はアジャイル、バックエンドはウォータフォールのハイブリット開発
・仕様変更も画面だけならOK、DBの項目レベルはNGという臨機応変な対応

2021/08/08

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

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

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

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

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

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

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

2018/02/17

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

2017/12/10

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

2016/11/12

リクルートのCTOが書いた本。
非IT企業だったリクルートがどうやってトップクラスのIT企業に成長したのかが書かれています。

・各論こそすべて
各論を知らないと、計画に自信が持てない。判断ができない。発想が浮かばない。

・人材の育て方
修羅場をくぐらせる。
新人研修でも納期は厳守。若手でも1人で海外武者修行をさせる。オフショア開発を任せる。

・最強のチームの作り方
ビジネスを管轄する事業や利用者のニーズを理解して応えていく事業別組織と、技術分野ごとに専門家を集めた機能別組織にわける。
このお互いの論点で話し合い、お互いの考えを共有し合い、合意形成を進めることで、コラボレーションが実現する。

2016/10/23

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

2016/10/14

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

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

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

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

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

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

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

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

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

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