mitsuのぶろぐ

基本的にはプログラミングの話のつもり。

複数のプロジェクトが動いているときに意識していること

Scrap アジャイル

本当はチームの中で一つのプロジェクトをみんなで回して行きたい気持ちが強いのですが、残念ながらそんなにキレイにいくことはありません。

そういった中でチーム内でどういう分担や振る舞い方ができるとよいかをちょっと考えてみたいと思います。

プロジェクトごとの優先順位を決める

基本的によほど成熟し、プロダクトのことも十二分に理解されている状態ではないと見積もりの精度というのはだいぶブレます。

ブレたものはあくまで次スプリントに引き継ぎ、時間をかければ解決するということであればそこまで問題ありませんが、

そうではなくどうにかして間に合わせる必要がある、といったことも珍しくはありません。

間に合わせる≒チームの他の面々の協力が必要となったときに、「私は私の仕事があるから手伝えません」といったことになると不幸です。

これは結局チームが社内受託のようになっており、あくまで自分の仕事を言われた通りやっていればokみたいな雰囲気になっているとそういったことがおこるのではないかと思いました。

もちろん別のタスクをアサインされている人の気持ちもわかります。

結局自分のタスクを放り投げて助けた結果、「どうして終わってないの？」なって言われた日には「助けるだけ損」といった形になってしまいます。

なのでチームとしてはそういった状況は避けなければいけません。

「チームとして目標を掲げたものが終わっていない」という状況にちゃんと向き合う形を取らなければいけません。

そういった意味でスクラムにおけるスプリントゴールの存在意義は大きいと思います。

具体的にどういったことをしているか

プロジェクトごとの優先順位を決める

上のタイトルにある通りですね。

これはチーム内外にキチンと名言し、「優先順位が高いほうは死守しますが、他のものは差し込みや優先順位が高いものがうまくいかなかった場合にそちらは終わらない可能性がある」と認識合わせをしておきます。

そうすれば自ずと優先順位が高いほうから解決するようになります。

必達なものとそうじゃないものをちゃんと区別し、認識しておく

上の内容と同じようなものです。

プロジェクトとは少し異なるbug fixなどがあったときに、それがはやめにリリースをしなければ不味いものなのか、遅延しても問題ないのかを把握しており、遅延しても問題ものに関してはやはり差し込みなどがあった場合は無理してやらない体制を取るようにしています。

アサインに余白/遊びを設けておく

リソースの100%をプランニングのタイミングからギチギチにしておくと、なにかあったときに最初から余力がありません。

そのため(個人的な肌感ですが)7~8割くらいは機能開発であったり、大きなプロジェクトの進行、攻めの開発のようなところに当てつつ、残りの2~3割はbug fixなどしつつ、問い合わせ/差し込みの対応など、なにかあったら対応するためのリソースとして確保しておくとよいかと思っています。

最近思うこととして、運用がはじまってからはやはり最低限でもリソースの1~2割は新規の開発「ではない」ところに充てたほうが健全なのではないかと思っています。(なお現実)

運用作業としてリソースを充てることはもちろんのこと、リファクタリングや、少し気になるところの雑多なものの解決などに充てても将来的にお釣りがくるのではないかと思います。

そしてなおかつ運用が実際に始まるころには、開発初期からいるベテランメンバーのチームからの離脱(異動や転職)、そして新しいメンバーの増員などが考えられ、ただ純粋に機能を0から開発してきた状況と大きくことなると思います。

すなわち教育、オンボーディング的な要素がチームに求められると思います。

ここでOJT的にタスクをアサインし、そこから学んでもらうことももちろん可能ですが、時間が経つにつれ、覚えてもらうこと、教えなければいけないことが増えていくと思います。

そうなってくるとOJTだけではどうしてもまかないきれない要素も増えてくると思います。

そこでチームで何かしら教育やオンボーディング、ドキュメンテーションをする時間などを意図して用意する必要があると思います。

できればプロジェクト間の担当者をたまに入れ替える

基本的に「◯◯さんが今日休みなのでプロジェクトの実装が止まります」であったり、「XXさんが退職されたのでこのプロジェクトの実装に詳しい人がいません」という状態はとてもチームとして脆いと思います。

必ずしもすべてを把握しているのは難しいかもしれませんが、ある程度数人休んだり、いなくなったりしたとしてもチームが持つプロダクトの実装は滞りなく進むことが望ましいでしょう。

そう考えたときに、プロジェクトが終わったあとに情報をシェアしてもシェアされた当人たちからすると「ふーん」で終わってしまうと思うので、できうる限り実装領域のアサインをたまに入れ替えたりすることによって、ある程度触ったことがある状態を作れないかと考えています。

スプリントごと(1~2週間ごと)でアサインを変えれないかと企てていましたが、さすがにそこまで頻度高くコロコロ変えてしまうと効率性が落ちるなと思ったので、1ヶ月などそれくらいのスパンなどでうまく変えれないかなと考えています(ここはまだ模索中です)

上記を踏まえて「できないことにはできない」と明示しておくことが必要だと思います。

もちろんスタートアップなどであればそんな悠長なことを言っていられないことはあると思いますが、その「今は頑張り時」みたいな切り札をいつまで使うのだろうか、というのは意識したほうがよいと思います。

組織やプロダクトがスケールしていくとどんどん「とりあえずがむしゃらになんでも頑張れる人」だけではなくもっと多様に「技術力はありつつ、普通に働くことを望んでいる人」なども入ってくるでしょう。

むしろ大なり小なりありますが、大半の人はあまりしんどいことにずっとは向き合いきれません。

なので「チーム」というものが今後も永続的に続いていけるような土台づくりをどこかで意識しなければいけないと思います。

一見すると昔のスピード感というのは明らかになくなります。人が増えてるはずなのに速度がでない、ということも平気で起きるでしょう。

そこで斧を研ぐ時間を用意しないともっと「人が増えてるのに速度があがらない」という状況が作られていきます。

複数のプロジェクトが動くときは、「今」もそうですが「長期的にどうか」も意識してアサインや振る舞いを考えることができるとよいのかなと思います。