チームの成長のためにこの1年で取り組んできた5つのことと秘訣

Advent Calendar チーム開発 輪読会

これは XTechグループ Advent Calendar 2020 の1日目の記事です。

はじめに

エキサイトのLife&Wellness事業部でエンジニアをしている おおしげ ( @_ohshige ) です。
XTechグループとしては初めての試みとなる Advent Calendar の記念すべき1日目を任されました。

XTechグループの Advent Calendar として、弊エキサイトはもちろん、Radiotalk社、iXIT社、クロスマート、イークラウド、さらには内定者まで、様々なエンジニアが至極の記事を執筆する（らしい）ので今後もご覧いただければ幸いです。 qiita.com

この1年で取り組んできたこと

私自身の最近の目標として、チームの技術力向上を掲げています。
ビジネスとは直接的には関係のない技術に関する「何か」をやることで、自分も含めてチームに良い影響を与えられるのではないかと考えて、この1年でいくつか取り組んできました。

既にこのブログ内で紹介しているものもありますが、1年を振り替える意味を込めて包括的に改めて紹介しようと思います。

この1年で私が主催者としてやってきたことは、主に以下の5つです。

  • AWS資格もくもく勉強会の開催
  • ライブコーディングの実施
  • 輪読会の開催
  • ペアプログラミングの実施
  • モブプログラミングの実施

AWS資格もくもく勉強会

取り組んできたことの1つ目は、AWS資格もくもく勉強会の開催です。

弊社はオンプレ環境で開発をすることが多かったのですが、あるときからクラウド(AWS)への移行が始まり、AWSのマネージドサービスを使う場面も増えてきました。
そこで、せっかくAWSに触れているなら資格でも取ろうと思い立ったのが始まりです。
ただ、一人でやっても面白くないので、チームを巻き込み、週に1時間だけ「みんなでもくもくと勉強する会」を開催することにしました。

内容としては、講義が開かれるわけでもなく、本当にただもくもくと好きな方法で資格取得に向けた勉強をするだけです。
実際、黒本を読むメンバー、Udemyで対策試験を受けるメンバー、YouTubeで勉強するメンバーなど、ただの自由な会でした。 毎日ちょっとずつ勉強するのも大事ですが、どうしても忘れてしまったり怠けてしまったりすることもあるので、何でもいいので強制的に勉強する日を作ろうという目的です。

開催して良かった点は、まず、目的通りであるのですが強制的に勉強する日ができたことです。もちろん、もくもく会以外でも勉強はしていましたが、がっつり1時間とって勉強していたのはもくもく会だけでした。
また、勉強している同士が集まっているので、おすすめの参考書やサイト、資格試験を受けるための登録フローなどを教え合えたことも良かったです。逆にAWSのサービスに関してわからないことの教え合いについては、皆が初心者なだけあってあまり見られなかったです。
そして、やはり一番良かった点は、何名かが資格を取得することができたということです。

業務の関係で来れない日があったメンバーや離脱していったメンバーもいましたが、2020年3月いっぱいまでは続けると固く誓って続けることができました。
その結果、何名かは何かしらの資格を取得することができ、個々の勉強した成果ではあるのですが、開催して良かったです。
私も、ソリューションアーキテクト - アソシエイトの資格を取ることができ、そのことは過去のブログでも紹介させていただきました。 ohshige.hatenablog.com

ライブコーディング

取り組んできたことの2つ目は、ライブコーディングの実施です。

業務としてがっつりとリファクタリングをやる機会があり、結果的にうまくリファクタリングできた部分もあったため、これはチームに共有できたらいいなと思ったのがきっかけです。
チームのメンバーを集めて、業務でやったリファクタリングをなぞる形で、みんなの前で、つまりライブコーディング形式でのリファクタリングを行いました。

大きな目的としては、

  • リファクタリングのやり方を知ってもらう
  • 設計思想を知ってもらう
  • PhpStormの便利な機能を知ってもらう

です。

ライブコーディングは、説明→コーディング→議論という流れで行いました。
より具体的に説明すると、まずは、前提知識の共有のためにリファクタリング対象の説明とリファクタリングの目的と設計方針について話しました。
その後に、実際に私のPhpStormやGitHubの画面をプロジェクターで投影し、思考発話法のようにひたすらやりたいことやっていることを口に出しながらコーディングしていきました。
ある程度ライブコーディングができたら、全てのリファクタリングを再現することはもちろんできないため、目指していた最終形（業務で実際に作成されたもの）を最後に軽く紹介し、皆で議論等を行い、お開きとしました。

参加者目線で良かった点は、目的通り、リファクタリングと設計のやり方やPhpStormの便利機能について知らなかったことを実際の使い方や活かし方を含めて知ってもらえたということです。
主催である私目線では、逆に自分が知らなかったことや悩んでいたことに対して野次としてアドバイスが出てきたのも良かったです。

ライブコーディングの話についても過去にブログで紹介させていただきました。
ohshige.hatenablog.com

輪読会

取り組んできたことの3つ目は、輪読会の開催です。

個人的に読みたい本があってせっかくなら誰か一緒に読む人はいないだろうかということで、Slackの分報で雑につぶやいたことがきっかけでした。
先にあげたもくもく会やライブコーディングなどの他の取り組みはチーム内にとどまるものですが、この輪読会は他部署やグループ会社であるRadiotalkのメンバーも一緒に行っています。
さらに、他の取り組みに比べて最も長く続いているものでもあります。

仰々しい目的はありませんが、個人で読むだけでなく複数人で読んだ上で議論をすることで、日々の業務や開発に活かすことができないか、意識の改革をすることはできないか、という思いをもって続けています。

全体として以下のような流れで進めています。

  1. 課題本を決める
  2. 1回の輪読会で取り扱える程度のまとまりの章で分割し、それぞれの担当を決める
  3. 輪読会当日までに全員がその範囲を読んでくる
  4. 輪読会当日は担当者がファシリテーターとなり良かった点や疑問点を提示して議論する
  5. 今の課題本が終わりに近づいたら次の課題本を決める

輪読会の一番良い点は議論ができることです。
個人で読むだけだとふむふむなるほどと思うにとどまるところも、輪読会であれば賛成・反対・疑問・共感・畏怖・懐古など様々な意見が飛び交います。
年次も部署も会社もバラバラであるため、うちではこうだけどそっちではどう？となる場面も多々あります。
むしろ、議論したいことがありすぎていつも時間オーバー気味になってしまうのが反省点です。

12/1時点で全34回の輪読会が開催されていて課題本も6冊目に突入しました。
これまでの課題本は以下の通りで、最初の2冊は過去のブログでも紹介させていただきました。

ペアプログラミング

取り組んできたことの4つ目は、ペアプログラミングの実施です。

私達が扱っているサービスは昔から続くものであり、その分古くから継ぎ足し継ぎ足しで秘伝のタレ化しているコードもたくさんあります。
そして、恥ずかしながらテストコードが無いところもたくさんあります。
そこで、業務的な別の兼ね合いもあるのですが、一念発起してテストコードを少しずつ書いていこうということになりました。
こうして、分担して日々の業務の中で少しずつテストコードを書くプロジェクトが始まりました。

始まったはいいのですが、問題が出てきました。
テストに多少明るいメンバーもいれば、全くの初心者のメンバーもいます。
逆に、仕様に詳しく秘伝のタレに明るいメンバーもいれば、仕様自体はあまり詳しくないメンバーもいます。
そのため、テストの書き方や仕様として重視する箇所の見極め方など、メンバーによってバラバラであるため、テストコードの質に差が出てきました。
さらに、PullRequestを出してレビュー依頼をしてもそのような認識に差異があるため、修正が何往復にもなってしまう場面が出てきました。

そこで、テストや仕様の知識の差を無くしてチーム全体としてテストコードの品質の平準化を図るために、ペアプログラミングを導入することを提案しました。
そして、そのペアプログラミングで出てきたテストコードに関する成果物はPullRequestを出す必要は無いというルール決めをしました。

テストの書き方に慣れている・慣れていない、仕様に詳しい・詳しくない、年次が若い・中堅など、様々な面からペアを決め、週に1回だけ時間を確保してペアプログラミングをやってもらうことにしました。

しばらく取り組みを続けてみて良かった点は、やはりテストコードの最低限の質が担保された上でPullRequestによる時間拘束が軽減された点です。
もちろんペアプログラミングの利点としてよく出てくるようなPhpStormの使い方や開発の進め方のいいとこ取りができるという点も、良い点としてあげられます。

良くない点というか注意する点として、ペアプログラミングする題材のテストコードがあまりにも単純すぎると、2人ペアの時間を拘束してまでやるほどではなく、1人で開発してPullRequestを出す（もちろん簡単なのですぐLGTMになる）方が明らかに早いとなってしまいました。
これは、ペアプログラミング開始時に簡単すぎる題材は避けるようにすることが解決しました。

また、逆に、あまりにも難易度が高い題材だと、ペアプログラミングの数時間だけでは全く終わらないという問題も出てきました。
この問題点については、ペアプログラミングが始まったらいきなり上からコーディングしていくのではなく、まずは必要なテストケースをリストアップしてそれぞれでどういう検証を行うかを決めることから始めることにしました。
これによって、全体の見通しが立ち、どこまでどういうテストを行うかという一番悩ましい部分（PullRequestで一番の往復の原因になる部分）を解決できます。
もちろん、ペアプログラミングの時間内で終わらすことができない点は変わりませんが、残った部分は個人で巻き取ってコーディングに集中することができます。

業務的な理由により現在はペアプログラミングは停止していますが、メンバーにも概ね好評であり、テストコードを書くというプロジェクトもこれによってある程度進めることができました。

モブプログラミング

取り組んできたことの5つ目は、モブプログラミングの実施です。
取り組んできたというよりもまさに取り組み始めたばかりというのが正確です。

以下のような目的を掲げて提案し実施に至りました。

  • 新卒1年目の基礎的な技術力向上
  • リモートで減少傾向にある横に座って一緒にプログラミングをするような環境の提供
  • 運用だけではない新規開発を行うことによるモチベーションアップ
  • 新しいことへのチャレンジ（PHP8やTDDをやりたい）

モブプログラミングで何をするかという題材については現在試行錯誤中です。
始めたばかりでモブプロ自体も初めての試みのため、まずはチュートリアルとして『テスト駆動開発』の題材である多国通貨に取り組んでいます。

始めたばかりなので良い成果をあげているかは疑問ですが、PHP8の新記法やTDDの進め方やPhpStormの使い方など、初めて知ったので良かったという場面も既に出てきています。

より良い成果が出るようであれば改めて紹介しようと思います。

色々やってみて

こうやって振り返ってみると、色々やってるなと自分でも驚きました。
細かいものや今回のブログのテーマ趣旨からは逸れるような例もあげると、terraform伝授会、開発運用ルール策定定例、ソフトウェアアーキテクト的振る舞いなど、たくさんやってきた1年だったと思います。

色々なことをやって感じたのは、とにかくやりたいことをやってみる、そして面倒くさいことは続かないからやらない、ということです。
高尚な目的の上に成り立っているかと思いきや、自分がやりたい！と思ったことをやっているだけであったりします。
それが結果的にチームのためになればとても良いよねという感覚です。
そして、自分がやりたいことをやるにも続けなければ意味が無いので、極力面倒なことは避けるようにしています。
事前準備が大変なだけで続かなくなることは目に見えています。
例えば、輪読会であれば「毎回担当者がプレゼン資料を用意して担当部分の紹介をする」といったこともやり方として考えられますが、続かない原因になるので採用していません。

最近の目標としてチームの技術力向上を掲げていて、自分でやりたいことやりつつも、その目標のために色々なことをしているのですが、なかなか目に見えて技術力があがった！とはならないため難しいですね。
少しでもチームの何かしらの力になっていれば幸いです。

おわりに

非常に大きな成果が出たような取り組みと言えるわけではありませんが、色々なことをこの1年でやってきました。 ここまで読んでいただけた方にとって、少しでも参考になるものであれば幸いです。

XTechグループ Advent Calendar 2020 はまだまだ続くのでお楽しみください。

採用情報はコチラ↓ www.wantedly.com www.wantedly.com