米谷修の作品一覧

前作は自身のエンジニア人生の振り返りから今後の展望など自分語りだったのに対して、今回はリクルートテクノロジーズ社のメンバーについて語ります。
これは各メンバーとの掘り下げたコミュニケーションの賜物です。自分が頑張ってきたことをしっかり理解してもらい、このような形で表現して貰えるのはエンジニア冥利に尽きるのではないでしょうか。
技術畑の経営者としての愛のある（とても厳しいのもよく知ってます。）姿勢を学ばせて頂きました。
また、社員でない、いわゆるパートナーまで登場していたのにはとても驚きました。この辺りは弊社社員ともしっかり議論する所存です。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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