気づかいが透明性を失わせるかもしれない
先日、過去に参加していたプロジェクトのことを思い出す機会があった。その中で、アジャイル開発の導入を狙ったけど失敗したプロジェクトを思い出した。プロダクトはリリースできたし、未だに動いているもののようなので、プロジェクトとしては成功だと言えると思う。しかし、アジャイル開発の導入としては失敗だったと思う。その時のことを思い出しながら、ふと思ったことをつらつらと書いてみる。
そのプロジェクトでは、プロダクトオーナー（PO）の人が「アジャイル開発をやりたい」と言って始まった。新しいことに挑戦するのは良いことだという部署の雰囲気があったし、そのPOが非常に勉強する方でもあったので、一緒に働いていた開発チーム（自分含む）も協力的だったと記憶している。当時はスクラムを自分は知らなかったのだが、今思えばおそらくスクラムだったと思う。毎朝全員でミーティングをして、たしか一週間くらいごとに振り返りをして、スプリントレビューをして、次の計画をして、といったことをやっていた。でも、そのスプリントレビューはPOがその時点でのプロダクトの出来を確認するようなもので、ステークホルダーへのデモやフィードバックをもらう場は別だった。その場に出るのはPOのみ。その時は誰もなんとも思っていなかった、他の人に無関心というわけではなく、「PO（または開発チーム）がやることだから」といった
プロジェクトを開始してから数ヶ月くらいは順調だった。期間にもある程度余裕があったので開始してからは準備期間のように要件の整理や実装できるか実験したりしていたので、プロダクトバックログがかなり具体化されていたと思う。ある時、ステークホルダーのビジネスの状況が変わり、色々と要件の追加や変更が出てきた。カットオーバーの日付も早まったり、作戦の立て直しが必要だった。POはバックログを見直し、何をどう進めるのか考えるのに忙しそうだった。そうなり始めてから少し経ったころ、プロダクトバックログから着手できるものが無くなるのが見え始めた。バックログはたくさんあるのだが、何をやるべきかが作戦立て直しのままで手がつけられない状態だった。POに「次は何やりましょうね」と聞くと、
スケジュールも決まってないし、まだ見せられる状態じゃない。まだ待ってください。
という答えが返ってきた。何度か同じことを聞いたが、いずれも同じような答えだった。隣の席だった自分は、ガントチャートツールを使っているPOの姿を見えた。横に棒をつなげていくと期限の赤い線を超えてしまう。なので、いくつかの棒を横に並べてみる。しかし、そうすると棒の前後関係が崩れてしまい矛盾が発生する。そして、違う組み合わせを試す。でもやはり赤い線を超えてしまう。そんな状況が続き、いずれそのPOは体調を崩してしまった。それでも進めなければいけなかったので、残った開発チームだけでバックログを精査することにした。スケジュールの問題もあったが、バックログの中に技術的に実装可能かどうかの判断が難しいもの、必要無さそうなもの、分割して進めた方が良さそうなものなど、色んな意味でReadyでは無い状態のバックログアイテムばかりだった。
そのPOが時折、「エンジニアには開発に集中してもらうために」といったことを言っていた。プロダクトバックログに対する責任感やエンジニアへの気づかいから出ていた発言だと思われる。しかし、残念なことにその気づかいが結果的に開発に集中できない事態を招いてしまった。
数年前のことなのでもう今更どうにもならないのだけれど、こういう事態に陥らないためにはどうしたら良いのだろうか。
スクラムガイド（2017年版）には、
プロダクトオーナーは、プロダクトバックログの管理に責任を持つ 1 人の人間である。
と書いてあるが、その後に、
上記の作業は、プロダクトオーナーが行う場合もあれば、開発チームが行う場合もある。
ここでの「上記の作業」は、プロダクトバックログの管理のための作業を指している。開発チームと一緒に行うことを禁じてはいない。むしろコラボレーションを推奨しているのだと思う。個人的には、開発に着手可能かどうかは開発者が判断することが一番信頼できると思っている。
また、スクラムの大本になった論文「The New New Product Development Game」では、新規プロダクト開発の良いプロジェクトでは作業フェーズで関わる人達がオーバーラップしていることを挙げている。
プロダクトバックログアイテムを考えることと新規プロダクト開発プロジェクトとでは違うものかもしれない。けれど、チームとして共に同じものを作っていく活動としては似ているので、共同で進めていくことが重要なのかもしれない。
件のPOは勉強熱心だった。そういったことを十分に知っていたかもしれない。それでも尚、これまでのやり方や他の人に見せられない何らかの原因があったのかもしれない。
先のスクラムガイドのプロダクトオーナーの定義には「責任」とあるが、この言葉の解釈によってもその人の動き方は変わりそうだ。「1人でやること、周りに煩わせないこと」のように捉えてしまっている人もいるのではないだろうか。
プロダクトオーナーとの隔たりが生まれてしまうという話はよくあるようだ。コミュニティなどで話を聞いていると、そういった話題が出てくることがある。「POが忙しいから」「開発チームが回るようになってきたのでプロダクトバックログがReadyのものが減ってきてPOがボトルネックになってきた」といった言葉も聞いたりする。かく言う自分も同じような状況を何度か体験した。しかし、忙しい原因やプロダクトバックログにReadyなものが枯渇する原因を考えられていなかったとも反省している。もしかしたら、そのPOは開発チームを気づかって忙しくなっているのかもしれない。Readyかどうかを1人で判断しようとして時間がかかっているのかもしれない。
これといって具体的な解決策は無いのだけれど、同じ1つのスクラムチームとしてプロダクト開発に挑めると良いですね。
最後まで読んでいただきありがとうございます！ サポートで頂いたお金は、技術書の購入や勉強会参加費など勉強に使わせていただきます！