はじめに
先日アジャイルサムライを読み、アジャイルなチームになるためにどうすればいいんだろう？という考えを以下資料にまとめました。
日本語: チームがアジャイルに 働くために
English: How to be Agile as a Team
この記事は、この資料＋それを作るまでに感じていた課題から、なんちゃってアジャイルを抜け出す手がかりを見つけることを目的としています。
スクラムを回すには？とかどう回す？の部分には触れません。その前の、マインドをどう持つかの話です。
アジャイル開発をしたい！やってるけどうまく浸透しない！という私たちのような方々の助けになれば幸いです。
アジャイルに動けないぼくらの課題
- 2019年4月にとあるBtoCサービスの支援システム開発チームに参画
- 複数ある既存システムを統合するため要望元や対象ユーザーはそこそこいる
- ざっくり以下のようなチーム構成
この記事では、Operator, Customer = まとめて要望元と呼ぶことにします。
小規模ではないけど特別でもない、どこにでもある構成のチームだと思います。
こんなチームでアジャイル開発を進めていこうとしていたのですが、課題は山積みでうまく行かないことが沢山。
改善はしてきているんですが、アジャイル開発と呼ぶにはまだまだ。そんな状況を何とかしたくて作ったのがこの資料となります。
どんな課題があったのか
- コミュニケーションに関する課題
- 要望に関する課題
- スケジュールに関する課題
- 開発に関する課題
これらの課題について、最初は「要望元がこちらの理解してくれないからだ！」とか、「開発としてはこうだ！」とか、課題の要因を相手に置いてるようなところもありました。
ただ、アジャイル開発について調べていると、自分たちの改善点も沢山見えてきました。
そんなことも出来てないの？アジャイル原則すら理解できてないじゃん！なんて思うでしょうが、そこはご了承ください。
- あくまで例で、特定の何かを指してるわけではないのでご了承ください。 To チームメンバー
コミュニケーションに関する課題
私たちには対話が足りない
- 例1: PM/BAと開発の間のとあるやりとり
PM:「とにかくこういう作りにしないといけないんだ！！この要件で合意したんだ！」
開発: 「いや、それだと工数も影響範囲も大きいんだ！YAGNI原則だ！最小限のもの・ことからはじめるべきだ！」
- 例2: 要望元とPM/BA＋開発内のあるやりとり
要望元との打ち合わせ
要望元A 「この機能Aを私たち向けに改良してほしい！出来るだけ早くくれ！」
PM A 「顧客との調和！いいですよ、出来ます！」
開発内
PM A 「要件追加です！次のリリースに出さなきゃいけないんです！」
Dev A 「わかりました、緊急対応します！」
Arch A 「なんかDev Aさんが謎のタスクをやってるんですけど、PM Bさんの要件はリリース対象から外れたんですか？」
PM B 「え、なにそれ知らない」
PM A 「え、でもなるはやって言われてるし…」
どうすればよかったのか？話すはもちろん、実は全体像の意識合ってないのでは？
いやいや、どうすればも何もちゃんと話をしようぜ！で終わりじゃん！
と客観的には思うんですが、それだけではうまく行かなかったです。お互い自分のわかる範囲で話はしてるつもりなんですよね。
話そうぜ！の前に、思い描く全体像が一致していなかったりするんですよね。なので誰と話すのか、何のために話すのかがずれています。
例1。
PM側は「動くソフトウェアを提供すること」が価値なはずなのに、要件を決める段階で開発のことを気にしてない。
逆に開発側は「顧客との協調」をせずに開発の都合を主に置いて主張しています。
例2。
これはPM一人ひとりは、自分のプロジェクトの全体は見えてるのかもしれません。しかし、私たちのチームはProjectをまたがってSystemを作っているため、最終的な成果物のソフトウェアもプロジェクトを跨いで1つです。
各自は一生懸命働いていますが、大元の全体像を気にしてないため、協調して動けてないのです。
というわけで、
- 全体像の意識を合わせた上で
- 必要なことを日々話す
ことが大事になります。この辺りの意識があってないと、いくらstand upをやろうが情報が共有されないです。共有が必要と気付いてないんだから。
意識を合わせたら、後はやり方模索して改善しながら日々話しましょう！
要望に関する課題
譲れない要望
- 要望元「現実に合わせて？いや、私たちのスケジュールがある！合わせてほしい！」
まあそうですよね、お気持ちはわかります。スコープが調整してください！え、だめ？じゃあスケジュール調整が出来れば！え、それもだめ？
でも実現できないものはできないですよ！え、どうしようもない？頑張れ？えー。。
徹夜でごにょごにょ
どうすればよかったのか？だって調整できなければしょうがないじゃない！・・・実は期待に応えず信頼を失っていない？
最初のうちは、無茶を言ってきて！しんどいわ！ってなってたんですが、全体像が見えて明らかになったことが一つありました。
私たち、要望元に対して価値を提供出来ていなかったんですよね。それで信頼を失ってしまっていた。
例えば、出来るといった要望、来週お見せします！って言ってた話を実際見せることが出来なかった。
検討しますといっていた要望に対するフィードバックを何もしていなかった。
要望元から見たら、開発側がごねて話したはずの背景とかをまた聞き出した。
こんな風に、要望元が期待していることを何も満たせずにいると、調整しようにもうまく行きませんよね。
まずはきちんと期待に応えて信頼を得る必要がありますね。
ただ一方で、私たちの開発事情も要望元に知ってもらうことは大事なので、「素早く価値を提供するためにこういった考えで開発してます」の部分を理解してもらうよう、
啓蒙を続けていく必要もありそうです。日々頑張ります。
スケジュールに関する課題
オンスケじゃない時にどうすればいいのか？
- え、思ったよりも進捗がよくない？リソースなら確保できるから何とか頑張ってくれ！
変化に対して対応したいけどどうしたらいいかわからず、作戦名：頑張れ 始動！
いやいや、えー。。徹夜でごにょごにょ
- PM 「実装が終わらない？いいよ、テストは後回しで！」ｳｺﾞｸﾓﾉﾃﾞｷｽﾞ―
リリース優先！品質は二の次！ってやった結果、バグ満載。ひどいものは契約終了した方の成果物がデモで見せたところしか動かない張りぼて。えー、こんなことってあるんだー
作り直しー
どうすればよかったのか？ 個人に頼りすぎず、キャッチアップ、トレードオフを
最後の張りぼては論外ですが、どれも個人のスキルに任せすぎて、問題が起こったらどうするかの準備が出来てなかったのが問題でした。
日々のstandupで状況が確認できない。確認出来る人を当てていない。とか、何を調整・トレードオフする時に何を落とすべきかを判断できてないとか。
トレードオフスライダーややることリストをこれから取り入れて組織をアップデートしていこうと思います。
開発に関する課題
PMと開発の距離感
- PM/BAと開発の間のとあるやりとり
PM/BA:「要望はこれ。後は任せた！とりあえずちょっとずつ動くもの出してくれたらいいから！」どーん
開発:「いや、よう分からんし。なんだよ無茶言って！」
とPM-開発間の距離が離れていく
どうすればよかったのか？ 都合のいいところだけをつまみ食いする「なんちゃってアジャイル」してない？
アジャイルな開発をするにあたって一番大事なのは、かんばんやスクラムといった手法をただ取り入れるんじゃなくて、アジャイルな原則・考えを持つことだと思います。
例えば前者の課題である作りたいもののすれ違いについては、
- 個人と対話
- 顧客との協調
辺りを、特に開発側が意識出来てなかったのかなと思います。YAGNI原則を都合よく切りだして、アジャイルな原則を忘れてしまっている。
後者は逆にPM側が「動くものを作る」だけをつまみ食いして、個人との対話をおざなりにしてますね。
これこそなんちゃってアジャイルですね
これに関してはArchitectを間に入れることで改善しました。
なんでこの資料を作ったか
手法やツール、もしくはコミュニケーション取ろうぜ！Small startで動くものを作ろうぜ！みたいな部分的な考え方はよく見聞きすると思います。
しかし、それ以前の原則・考え方が浸透してないと、いくら手法を凝らしても埋められないものがあるのかなと感じることがあります。
正直全員参加を求めていても、現実はそうはいかないです。働きアリの法則なんてのもありますし。
だからこそ、どうしたらいいんだろうを考え、共有していくことが大事なのかなと思います。
その為の行動として、こんな資料を作ってみたというわけです。
ここから議論を重ね、自分含めチーム全員が
- 顧客に価値を提供することを意識し、
- チームに目を向けて、
- 個々に依存せず、組織として自立するために、
素早く行動できたらいいなと思います。(小並感)
最後に
この記事で書いたことは、別にアジャイルだからこその話ではなく、うまく行っているチームが当たり前のようにやっていることだと思います。
ただ、そういった当たり前のことを日常にすることが、アジャイルに動くために必要だと思います。
現状を改善する為に、やれることをやりましょう。Just Do It!