ペパボの本社事業部のチーフテクニカルリードになりました2017/01/11Tweet2017年1月1日付けで、勤務先であるGMOペパボ株式会社の本社事業部のチーフテクニカルリード(通称CTL)になりました。各方面から「おめでとうございます」と言われがちなので「ありがとうございます」とお返事しています。ここでCTLの先輩たちのエントリを紹介。このおじさんたちは2016年9月1日からCTLで、本社事業部はいろいろと事情があって半年遅れでのスタートです。天神スナップオン半年遅れている分だけ「追いつかなきゃ...!」という気持ちもありますが、先輩CTLたちがこの半年の間にやってきたことがぼくにとっては道標になるので、後発のアドバンテージを活かしてババーンとやっていきたいところです。2016年12月の某日にCTOのあんちぽさんと面談していて、なにかの話の流れで「来年はCTLをやってもらうわけですが、」と急に聞かされる形になったので、一瞬、キョトンとしてしまいました。ぼくがもともと本社事業部でやっていたこと・やろうとしていたことがあって、それは別にCTLにならなくてもやっていただろうと思うので、そういう意味では「もっとバーンとやってくれ」という追い風なのだと捉えて、しっかりと「やらせてください」とお返事できたのはよかったです。して、こじんまりとやっていく理由はなくなったので、盛大にやっていきたい気持ちで今年を過ごしています。きのう2017年1月10日(火)に「本社事業部エンジニア決起集会」というものを開催し、関係各位とやっていきを確認し合えたので、ようやく自身のブログでも報告できる状態となりました。本社事業部は「いくつかのサービスを束ねて管理する事業部」という実状があって、EC事業部やホスティング事業部と比べてみても、あまり名が体を表していないんですよね。東京本社に拠点がある、ということくらいしか言っていない事業部名です。そんなところもあって、管理下にある各サービスごとにチームがあり、計画があり、目標があり、開発プロセスがあります。これだと、ともすれば「各サービス、がんばるように」となってしまい、同じ事業部といえどもサービス間の連携が弱くなりがちです。他の職種は除いたエンジニアのみの配置図を描いてみると、事業部の組織構造によって「各自、がんばるように」となりがちな構図が浮かび上がってきます。この構図は様々な問題を引き起こし得るでしょう。(画像は、決起集会に向けて用意した資料の一部を公開用にマイルドにしたやつ)CTLとして、まずはこの構造上の課題と向き合うことにしました。「本社事業部エンジニアーズ」という単位で仕事に当たり、各個人のパフォーマンスを最大まで引き出せる体制を目指します。エンジニア以外の全スタッフとも連携できる組織になり、本社事業部の全サービスの成長に貢献していきます。全員成長で、全サービス成長だ!とはいえ、いきなりエンジニアを乱獲して今日から各サービスに配属させることもできませんし、常に「人手不足」となりがちなサービス開発の現場にどのようにアプローチしていくのか?ここがひとつ、悩みどころではあります。手を尽くしていこうと思っている中で、今週からはじめてみるのが「番長制度」です。各サービスごとにチームがあって計画を立てて進んでいく以上、各サービスのコアなところはサービスのチームメンバーにしかわかりません。他のサービスチームの人に相談するにはハイコンテキストすぎることが多々あります。それでも幸いなことに、ぼくらはエンジニアです。一般化・抽象化されたエンジニアリングについて言えば、サービスに依らず適用可能なことがあります。エンジニアリングは共通言語です。共通言語があれば話ができる、やりましたね!というわけで、エンジニア各位におかれましては、各自の得意なこと、あるいは、これから得意にしていきたいことについて、番長になってください。みんながみんな、なにかしらの番長であるのがよいと思います。あなたが、フロントエンド番長ならば、フロントエンド関連のIssueやPRを見つけては、番長から見て技術水準が充分かどうかレビューしていってほしいと思います。それを苦手とする人がいたら、ぜひともあなたの得意で助けてあげてください。得意なことを持ち寄って全員で成長していきましょう。各自の「自分としてはがんばりました」の水準ではなく、業界の水準を意識して仕事していけるようにがんばっていきましょう。ぼくが大きな声で「自分の担当サービス以外のことにも関心を持ってくださいね」と叫び続けたとしても、精神論にしかならず、あまり実際の行動は誘発されないだろうと悪い予想をしました。番長という役割を置くことで、サービスや事業部の目に見えない境界線を越えてエンジニアたちがオラオラとやっていけるような、そんな取り組みに育てていきたいと思います。番長の名乗りあげが相次いでおり、ひとりひとりの存在を本当に心強く感じています。他の事業部からも番長が次々に現れて、もう一触即発です。今日、決済番長が「決済番長なので、新年会のお金を集めます!」と元気に声をかけてくれましたが、それはただの集金係だと思いました。ん?あらためまして立場も新たにしながら新年を迎えたので、今のお気持ちを表明しました。あわせて、やっていく取り組みの一部を紹介しました。今年は、自分ひとりで奮闘してもほとんど成果にならないゲームに挑戦するので、これまで以上に周囲のみなさんの力を借りながらがんばっていく1年になることでしょう。あらためまして、本社事業部のみなさん、ペパボのみなさん、そして関わってくれているすべてのみなさん、どうぞよろしくお願いいたします!めちゃんこ頼りにしています。自分の言葉で書かれたコミットメッセージが好き2017/01/11Tweet誰にも質問されていないけど回答すると、ぼく個人としては「レビュー指摘事項を反映」的なコミットメッセージにはやんわり否定派で、どうしてそう変更すべきと思ったのかを自分の言葉で書く方がベターと思っています。2017140文字には納まらないな、と思ったのでちゃんとエッセイを書く人間になろう!たとえばぼくがレビューを担当させてもらって「ここはAの方がよいと思いました」とコメントしたとして、そのときに「レビューで指摘された箇所を修正」というメッセージ付きのコミットが追加されたとする。そのあとぼくが思い直して「いや、他の箇所も考慮すると、やっぱりBの方がよさそうです」とコメントしたとする。「レビューで指摘された箇所を修正」というコミットが追加される。いうやりとりだと、「レビュー」というプロセスというよりは「指示」を出している感じになっちゃって、レビューをしているつもりの身としては少し悲しい。いった感情は抜きにしても、レビュー内容を理解して「うん、その方がよさそうだ」と思っているならそれを言葉にしてほしい。言葉になって出てくれば、レビューで伝えたかった内容がきちんと伝わっているか確認することもできてお得。悪さをした中学生を叱ったときに「怒られたのでやめます」と言ってきたら「なにが悪かったのか、理解してもらえたのだろうか...?」と心配になることだろう。あと、指摘されたので修正しました〜というメッセージはあとから見たときに有益になることは少ないと思う。「より意味のある名前に変更する」と書いてあったら有益だ。コミットメッセージを自分の感覚と自分の言葉で書こうとしたときに指が止まってしまうとしたら、その変更の意義をしっかりと理解できていない可能性がある。したら、レビューしてくれた人ともう少し丁寧に会話を重ねるのが筋でしょう。ところで、さっきのツイートをしたら、過去にお仕事でいっしょになったことがある後輩からメンションがきた。ぼくは言ったことを覚えていなかったのだけれど、彼は覚えていてくれてうれしくなった。彼には、ぼくのレビュー内容の意図がしっかり伝わっていたのだと感じられてうれしい。特集1の「レビュー実践研修」ってやつを書きました。ソフトウェア開発の現場における「レビュー」というプロセスについて書いています。さんによる「コードレビュー実践入門」という特集記事があります。これがとてもよい内容で「さすが、うっくん」という感じなのですが、あれから丸4年が経って業界の状況も変わっており、次の春には次の新卒さんたちが入社してくることもありますし、2016年〜2017年にあわせた内容で「レビューをはじめるなら、これを読んでくれ!」と言って手渡せるようなものを目指して書きました。ぼく自身のレビューに対する考え方は、就職して上京した2008年4月以降になにかしらのプロジェクトでいっしょにわいわいさせてもらったみなさんの影響を大きく受けていることでしょう。みなさんと共に過ごす日々の中で「このレビューはよかったな」「今回のレビューはなんかうまくいかなかったな」と蓄積してきたものを、ふりかえって整理しながら文章にしていきました。した日々がなければ書くことはできなかった内容なので、この場で感謝の言葉を述べておきたいと思います。んこありがとうございました!!!そして、3〜4ヶ月間ほど執筆に取り組んでいたぼくを笑顔で応援してくれた妻にも感謝させてください。