本記事はLIFULL Advent Calendar2018 その2最後の記事です。メリークリスマス。
今年はなぜか3つAdvent Calendarがありますので興味ある方はどうぞ。
ということで本題ですが、私、恐縮ながら今年の4月から１つのチームを任せていただいています。
つまり9ヶ月ほどチームの開発について考える機会があったので、今回はその中で検討したうえで採用しなかったこと・採用したことについてその理由とともに書きたいと思っています。
各手法についての説明は本題からずれますので詳細は書きません。ご了承のほど・・・
※あくまで私たちのチームであり、弊社内の他のチームではバリバリスクラムやってたりいろんな違いがあると思います。あくまでとあるチームの話としてお読みください。
チームのステータス
検討材料の一端としてチームのステータスを特にカテゴリ分けせずざっくり書いてみます。
- 企画・開発・デザイン・業務委託あわせて10人ちょい
- WEBサービスの開発をしている
- レガシーなコードも割と残っているアプリケーションを触る
- 他部署からの問合せもチラホラある
- 若手（社歴1~4年目くらい）が多め
こんな感じです。なんとなくイメージつくでしょうか。それでは行きます。
採用しなかったもの
まずは採用しなかったものとその理由のご紹介です。
スクラムチーム
プロジェクトオーナー（PO）・開発チーム・スクラムマスター（SM）ってやつですね。
こちらは主にSMに対する懸念から見送りました。
というのも、SMを専任で持てるチーム体制ではなかったため、スクラムチームを採用するのであればSMを持ち回り制だったりPOなどが掛け持ちしたりしてすることになります。そうなると「忙しいから」という理由でSMという責務に応じた動きやモチベーションがついていかないリスクがあるなーと考えました。
ちなみにチーム体制については「これだ」というものはまだ思いついておらず、PJごとにメンバーの役割を与えて探り探りやっていっています。何かいい方法あったら教えてください。
スプリント
こちらはチームが持つ責務の観点からやめました。具体的に言うと
- 読めない差し込み作業がそれなりにある
- レガシーな実装に立ち向かうために長めの調査が必要なことが多い
- 企画によってはデッドラインがどうしてもズラせなかったりする
など、スプリント計画が破綻してしまう要因が多くあり、そのうちスクラムに対するモチベーションも下がり、最終的にはスプリントが形骸化してしまうリスクを懸念しました。
やるのであれば、これらの破綻要因がグッと少なくなる状況になってからにしようと思っています。
ストーリーポイント
これについてはいろいろ考えたのですが、結局「見積もりの精度が高くなるころにはチーム編成が変わりそう・別のPJをやってそう」という予測が一番のネックで採用するのをやめました。
そのほかにもスプリントの項目で書いた「デッドラインが決まってるもの」みたいなPJのときには結局時間の見積もりが欲しくなりそうだったり、などの理由もあります。
スプリント対象のPJをやる期間が半年を越えてきたら採用したい。
採用したもの
続いて採用したものです。
かんばん
タスク管理はJIRAを利用してかんばん形式で管理を行っています。
レーン・ワークフローは課題タイプによって違いますが、大まかには
- To Do
- Doing
- Reviewing
- Done
の４レーンです。
採用理由としては、「それを理由にしたら全部それが理由になるだろ」って感じですが「メンバーがすでに慣れていた」というのが大きいです。
（言い訳すると日々使うことになるものに学習コストや精神的な抵抗をかけたくなかったからです）
また、ワークフローやレーンを課題タイプごとに用意することで「リリース承認に必要なプロセスのフロー化」や「外部からの対応依頼の可視化」なども同じ「かんばん」という仕組みで提供できることもメリットです（同じUIであることがキモです）
課題としては、やはりレーンの最適化でしょうか。俗にいう「Doing」に該当する範囲をどこまで細分化するかはいまだに悩んでいます。
朝会（デイリースクラム）
朝会の議題もいろいろとパターンがあると思いますが、私達は
- 今やっていること
- 困っていること
- その他共有事項
を報告しあうことにしています。１日大体15分くらい。
特に大事なのはやはり「困っていること」で、その場で「こうやったらいいんじゃない？」「この後一緒に調べようか」のような話題に発展することも多く、朝会がなかった場合のタイムロスや開発遅延を防ぐ一端を担っていると思います。
もちろん他の部分でもチームメンバー間でのコミュニケーションがとれますし、1日15分で得られるリターンとしては大きいなと感じています。
ふりかえり会
こちらはPJの終了ごとにそのPJについてふりかえり会を実施しています。手法はオーソドックスなKPTを採用しています。
方法としては、会を長引かせないためにConfluenceにKEEP/Problemを事前に記載してから会に望みます。
振り返り会本番ではそれらを共有後、Tryをその場で議論して次回のPJに活かすようにしています。
こちらもKeepの部分ではあえて議題を絞らず「個人の良かったこと」も対象にすることで一種の褒め会のような一面も持たせられることができ、チームのモチベーションが下がらず気持ちよく振り返りができていると思います。
ただ、まだTryを常に意識するための手法が確立していないのが難点・・・
その他、ちゃんと組み込んでみたいなと思っているもの
ファイブフィンガー
ストーリーポイントの簡易的な代替案として。一度突発でやってみたら割と手ごたえがあったんですが、いろいろあってまだルーチン化されておらず。朝会の「困っていること」フェーズに組み込みつつ朝会の時間を伸ばしすぎないようにできないかなと考えています
インセプションデッキ
キックオフのときに有用だと思ってはいるんですが、今のところ企画担当の方の説明がうまいのか、開発メンバーがいろいろうまいこと察してくれているのか、大きな問題が発生していないので採用を見送っています。
この状態で採用してもメンバーの気持ちが入らないと思うので、折を見てやっていこうと思います。
まとめ
思いつく範囲で書いてみましたがいかがだったでしょうか。この情報化社会、いろんな良さそうにみえる手法が日々巷を賑わせていますが、そのどれもが今いるチームにふさわしいとは限りません。
私の判断が正しかったかどうかはわかりませんし、実際数カ月後には「スクラムチームにするぞ！」とかのたまっているかもしれませんが、少しでもチーム開発を進める上での参考になれば幸いです。
今のチームでいろいろほかにも試したいなと思っていますので、みなさんがどんな手法を用いているか教えてくれたらうれしいです。
それではLIFULL Advent Calendar2018 その2はここまでになります。来年もお楽しみに！