アジャイル研修を受けて学んだ「アジャイルの価値観と原理原則」
先日、会社の開発チーム全員でアジャイル研修を受けた。プロのアジャイル講師が来て、1日かけて講義と実践を交えてアジャイルのやり方を説明してもらったのだが、いろいろな気づきがあった。
研修前の状況
自分のチームでは一応1週間ごとにスプリントを区切り、チケットにStory Pointをつけてタスクを割り振るスクラム開発を行っているのだが、最近自分だけがタスクを抱え込みすぎて、うまくチームで協力できていない感じがしていた。別にチームメンバーが冷たいというわけではなく「何かあったらすぐ相談してくれ」とよく言ってきてくれるのだが、どのラインから相談していいのか自分の中であまり理解できておらず、スプリントという仕組みをうまく使えていない自覚があった。そのため、個人的にはアジャイルに対する正しい認識を身につけることを目的として研修に参加した。
アジャイルの価値観と原理原則を理解する
アジャイルという言葉はあまりにも広まっており、いろいろな方法論やフレームワークが溢れかえっている。今回の研修でもINVESTやScrum 3355など多くの用語が出てきたが、単にやり方を覚えても今の自分にとっては表面的な理解になってしまうと思い、この辺りは丸のまま覚えようとしないように意識していた。
むしろ最も印象に残ったのは、アジャイルの価値観についての話だった。アジャイルとは特定の方法論ではなく価値観・原理原則を指す言葉であり、それを実践するためのやり方としてスクラムやカンバンなどがある。そしてその価値観は、アジャイルという言葉を生んだ17人のソフトウェアエンジニアによって、アジャイルマニフェストとして定義されている。
このマニフェストで4つの価値観が定義されており、さらにその下に12の原理原則がある。
この価値観と原理原則が、今回の研修の最も大きな学びとなった。アジャイルという手法やエンジニアという仕事について、中には自分のイメージが間違っていたところも見つけることができた。いくつか刺さったものを書いておく。
アジャイルチームは自律的な組織
最良のアーキテクチャ・要求・設計は、自己組織的なチームから生み出されます。
「自己組織的」とは、価値あるソフトウェアのリリースをゴールとし、そのために何をするかを常に自分たちで考えつつ、ときには柔軟に行動を変えるチームのこと。そして、そのようなことができる自律的なメンバーたちのことを指す。スクラム開発も、自己組織的なチームであることを前提とした手法である。
スクラム開発を表面的にしか知らないと、こんな誤解をしがちになる。というか自分もそうだった。
- スクラムマネージャーが上司、それ以外のチームメンバーが部下。
- チケットを切ることでタスクの割り振りを行う。自分のチケットの見積もりは自分で行い、それを期間内にこなす責任を持つ。
しかし、これは全く自律的ではない。自分のタスクをこなすという考え方の時点で内向きになっているうえ、視点がその期間のスプリントにしか向いていないからだ。
正しい捉え方はこんな感じ。
- チーム内には上司も部下もない。チーム全体として、価値あるソフトウェアをリリースするというゴールのために動いている。
- チケットを切る目的は、チーム全体としてそのスプリント期間にどれほどの開発ができるかを見積もるため。そのため、見積もりはチーム全員で合意する必要がある。
- 期間の途中に自分のタスクが終わったなら、チーム全体としての見積もりを達成するべく、率先して他の人のタスクを助けるべき。誰かのタスクが終わっていなければ、それはチーム全体の問題。
- タスクにないがリリースのために必要なことが明らかになったら、チームとしてどう動くかをすぐに相談するべき。
開発者は、チーム全体でひとつのソフトウェアを作っている。そのため、視点を自分に閉じず、チーム全体での目標達成をサポートしていく姿勢が必要になる。
直接の会話が重要
情報を伝えるもっとも効率的で効果的な方法はフェイス・トゥ・フェイスで話をすることです。
上記のようなチーム開発をするためには、緊密なコミュニケーションが欠かせない。最強なのは直接顔を合わせて話すことであり、それが一番誤解が生まれにくい。
自分がエンジニアになった頃は、エンジニアはどこでも働ける職業だというイメージがあった。しかし副業でリモート勤務をしてみてわかったが、顔を合わせていないと意思疎通がとても難しい。もちろんチャットやビデオ会議などはできるが、人に何か聞くためのコストは同じ場所にいるときより遥かに高い。
フルリモートで働けるという人は、最小限のやり取りで認識を合わせて期待どおりのものを作れるだけの実力とコミュニケーション力を持った人である。そしてチームメンバーと同じ場所で働いているなら、なおさら積極的にコミュニケーションを取ることが求められる。
エンジニアは信頼されてしまう存在
意欲に満ちた人々を集めてプロジェクトを構成します。 環境と支援を与え仕事が無事終わるまで彼らを信頼します。
ここでいう「信頼」とは、チームメンバーが価値あるソフトウェアを出すための行動をするだろうという前提に立つこと。そのため、この権限が必要なのでほしいと言えばすぐ渡されるし、これを最優先に行うべきだと言えばチームの次のスコープが変更されるのが理想の組織である。その代わり、もし成果が出せなかったり、もらった権限を使って何かやらかした場合は、自由がどんどん奪われていく。
会社の先輩が「エンジニアは入社直後に最大限の信頼を置かれ、その後減点主義で評価される仕事」と言っていたが、それはアジャイル開発を行うエンジニアは自律的であって当然という前提があるからだ。
活かせるまでの道は険しい
このように、アジャイルの価値観や原理原則を理解しなければ、どんな方法論を取ってもうまくはいかない。逆に言うと、方法論だけ学んでもうまくいかないし、価値観がわかったうえでそれを自分なりの方法論に落とし込むには試行錯誤が必要になる。
どのみちすぐに行動を劇的に変えられるわけではないし、しばらくは間違った解釈で的外れなことをしてしまうかもしれないが、アジャイルマニフェストを何度も読み返しつつ行動を見直していきたい。