エス・エム・エスで、チーム開発の支援を主に担当している西村（@nawoto）です。今回は、チームを支援するうえで心がけている視点について書いてみます。

ソフトウェアとチーム開発について

弊社のようなサービス開発を行なっている会社だけでなく、今は多くの事業においてソフトウェアの存在が不可欠になっています。事業を成長させていくのは簡単でシンプルではありません。そのため、事業に寄りそっていくソフトウェアづくり自体も複雑な課題に対峙することになり、一筋縄ではいきません。

僕は、ソフトウェアづくりには誰かスーパーマンのような人の個人の力で成果を出していくことより、あらゆる局面でたくさんの知恵や能力を活かしていくチーム開発の方が成果を継続的に出しやすいので有効だと思っています。

チーム開発は難しい？

では、複数人で開発を行なっていれば、チーム開発として成立するのでしょうか？

残念ながらそう簡単ではありません。単に人が集まって作業を進めるだけでは、うまく成果を出すことは難しいと思います。チーム開発では、メンバー同士が共通の目的に向かって、互いに協力していくことでさまざまな局面でも円滑に仕事を進めることができます。そうした活動を積み重ねることで、「作業が予定通り終わった」「プロダクトに良いフィードバックが得られた」など今より「うまく開発できてる！」といった小さな成功の数が増えていき、結果として成果に繋がりやすくなります。

もちろん、チームとしてうまく協力して円滑にソフトウェアをつくっていくこと自体も簡単ではありません。しかし、今は参考になるやり方が世の中に増えてきました。その代表的なものとしては、スクラムをはじめとするアジャイルな開発があります。

アジャイルな開発は、複数人で価値あるソフトウェアを届けていくためのやり方です。チームとして何をどう協力していくかが、さまざまな活動と共に示されています。これからチーム開発をやっていきたい人たちが、アジャイルな開発のやり方から始めることも増えてきました。また、自分たちのやり方がうまくいっていないため、アジャイルな開発を導入していくケースも増えているように感じています。

アジャイルな開発を目指せばいいの？

自分たちのチームが手始めに目指す理想のチーム像として、アジャイルな開発から始めることは良い選択だと思います。何もお手本が無いなかで、手探りで仕事のやり方を良くしていくのは大変です。ただし、アジャイルな開発もチームでうまく仕事を進めていくうえでは、あくまで目指すべき姿のひとつであることを忘れてはいけません。

アジャイルな開発を実践している人は多少なりとも経験があると思いますが、実際にやってみると案外うまくいかないことが多いです。例えば、「スプリントの期間内に作業が終わらない」、「プロダクトオーナーが忙しくてチームの作業にあんまりコミットしてくれない」、「ステークホルダーからの指摘が多くて、プロダクトバックログの中身が膨大で煩雑なものになってしまった」などなど。

たくさんのチームがこうしたよくある課題に一度は直面していると思います。アジャイルな開発では、こうした表出した課題にひとつひとつ向きあって解消していくことでより良い開発に近づいていきます。

しかし、出てきた課題の解消のみに目を向けていれば良いのでしょうか？

僕は、スクラムを始めたばかりの人向けの勉強会などを開催していますが、そこで度々聞かれる質問の中に「チームメンバーの自主性がなくどうしたら良いか？」や「上司などステークホルダーにスクラムを理解してもらうにはどうしたら良いか？」といったものがあります。

たしかに、こうしたことは日々の開発を円滑に進めるうえでは課題になっているかもしれません。そして、アジャイルな開発を目指していこうとすると、人や環境に関することも自分たちのチームではうまく実践できていないこと = 課題として捉えてしまいがちです。

けれど、チームメンバーに関するような人に関する課題や上司やステークホルダーがどこまで協力的といったチームの置かれている環境に課題などは、なかなか簡単には解決できないと思います。では、こうしたすぐに解決できない課題をどう扱って、どう解決に向けてアプローチしていくかをもう少し詳しく考えてみたいと思います。

未来に向かってアプローチしましょう

ひとつの方法としては、課題やそれに付随する課題を整理・分析して、より本質に近い課題を見つけにいく。そして、それに対して適切な解決策を探していくのも良いアプローチです。

しかし、頑張って分析したにもかかわらず、その結果は自分たちのチームだけでは解決が困難だったり、「あれ？より手強い課題になったかも。。。」と解決により時間がかかりそうだということが分かって落胆することもあります。

また、大きな課題や解決に時間がかかりそうな課題にばかり目を向けていると正直、精神的にもしんどいと感じる人も多いと思います。(少なくとも僕はわりと凹みます)

僕も、上記のような課題→分析→解決する方法も行ないますが、並行して別の視点でも考えるようにしています。それは、自分たちのチームが理想の姿に着実に進めているかです。何かができていない = 課題だと考えるのではなく、あくまで自分たちのチームが着実に成長していることにフォーカスして考えます。大雑把な説明ですが、自分たちのチームの理想の姿をイメージして、そこに近づくまでのステップを考え、ひとつずつ着実に近づいているかを確認していくアプローチです。

どういうふうにアプローチするの？

もう少し詳しく説明するために、僕たちのチームの例を紹介していきます。

僕たちのチームは、リリースまでのリードタイムの長さに悩んでいました。その大きな原因のひとつとして、実装が終わってからQA作業を行なっていることでした。実装がひと段落してからQAメンバーに仕様の詳細を伝えて、テストケースを作成する。そして、そのテストケースをレビューしてテストを実施する。そこで見つかった不具合を解消してからリリースするので、一定の時間がかかってしまいます。そして、QAメンバーのリソース状況の影響も受けやすいので、そこを課題に感じていました。

そのため、僕たちのチームではQAメンバーを自分たちのチームに迎え入れて日々の作業を一緒にすることで解消しようとしました。しかし、単にチームに加わったからといって、すぐに一緒に作業をこなせるようになり、リードタイムが短縮するわけではありません。新しく加わったQAメンバーも自分たちは日々どういうふうに作業をしていいのか手探りな状況でした。そこでQAメンバーも含めて、どういう姿で一緒に開発していると理想的なのかを考えて、そこに近づけていくことようにしました。

まず、チームの一員として一緒に作業している理想の姿としてイメージしやすいのが、Agile Testing *1や書籍『アジャイルサムライ』に出てくる「アジャイルなテスター」だったので、最初にそこを目指しました。既に言語化されているものを利用すると、理想形をゼロから考える時間を大幅に短縮できるので、先人には感謝です。

次に、そこに近づけるためのステップをいくつか考えてみました。

その中からまず最初のステップとしたのが、「一緒に協業するイメージを揃える」でした。誰でも知識として知らないことは実行にうつせないだろうという考えから、これを最初のステップにしました。具体的にやったこととしては、僕たちのチームはスクラムをベースとした開発をやっていたので、まずQAメンバーも含めた全員でスクラムガイドや入門書の読書会をチーム全員でやりました。それとあわせて、これまで開発を主にしているメンバーで実施していたスプリントプランニングやデイリースクラムなどに参加してもらいました。これでQAメンバーにもチーム全体で普段、何をやっているかをより具体的に知ってもらいました。

そのあと、『Agile Testing Condensed』の読書会もやりました。これによって、開発が得意なメンバーとQAメンバーの両方に、どういうふうに協業していくか、どういうチームを目指していきたいかをまずは知識としてインプットしました。

次のステップは、知識としてインプットができたので、簡単なものから実際にやってみて体験してみることでした。まずは今のスプリントで実装している新しい機能の一部をどうテストしていくかを議論するところから始めてみました。どの部分なら自動化できそうか、もちろん全てを自動化するのはとても時間と根気が必要なので、どの部分は手動テストでやってみるか。テストの観点はチームの誰もが見ても分かりやすいものになっているか、他に気になる点はないかなどなど、議論の論点も多岐にわたりました。そして、共通認識がある程度できたところで、試しに一部分の受入れテストの自動化を全員で実装していきました。

もちろん最初からテストの自動化がうまくできたわけではないですが、実際にやってみたことで次はどうしようという具体的な意見が出てきました。そこで次のステップとして、「一緒に作業をやってみる」から、「チームとして仕事のやり方をふりかえる」段階に進んでいきます。徐々に自動化するスコープをどこにするか、チームの置かれている状況を踏まえて、どこまでテストするべきかなどなどチームでもっとうまくやれることを探して少しずつ良くしていきました。たとえば、QAメンバーと呼ぶと壁があるように感じるので、テスト得意メンバーと呼ぶというものもありました。

まとめると、以下のようなステップを歩んできました。

一緒に協業するイメージを揃える
お互いに意見を出す
一緒に作業をしてみる
やってみた作業をふりかえり、次のゴールを考える
To Be Continued (「壁を感じないようにしたい」「セキュリティテストをどうしよう」など)

最初に目指したのは書籍で描かれているような姿でした。それは僕たちのチームの方針としては今でも存在していますが、受入れテストの自動化はQAメンバーだけでも実装していきたいなどチームやプロダクトの特性にあわせたものに変わっていきました。チームごとで自分たちなりにどういう姿になりたいかはそれぞれのチームごとに変わっていきます。

たとえば、先ほどの「チームメンバーの自主性がなくてどうしたらよいか？」もそれぞれのチームごとに理想の姿は変わってくると思います。チームをよく観察して、もう少しチームメンバーの顔を浮かべながら、詳しく見ていくのはどうでしょう？たとえば、特定のメンバーの発言がプロダクトに関する議論のときには少なっている場合も自主性がないと感じるかもしれません。また、チームの全員が何かしらの全体に関する方針を決める場面でだけ消極的な発言になりがちなことも自主性がないと感じるかもしれません。この2つの例では、それぞれ理想とする姿も異なってくるでしょう。また、チームメンバーひとりひとりの個性は違うので、自主性の発揮の仕方も変わってきます。発言するのは苦手でも、チームのために一番難しい部分の実装を引きうけてくれる人だったり、実装するスキルは低いけど、みんなで合意した内容を忘れないようにドキュメントを書いてくれる人などです。そうしたメンバーの特性に応じて、チームの理想像を考えてみましょう。

そうすると「自主性がない」とひと言で表現したものは、実は「このチームでは、プロダクトの今後について考える際には多様な意見を出して、選択肢を多くした状態で考えていきたい」というのが理想の姿かもしれません。(あくまで一例です)

そこに近づけていくステップとしては、たとえばこんな感じになるでしょう。

多様な意見が出ている状態のメリットを知識として知っている
各メンバーが、その状態についてお互いにどう考えているか共有できている
小さな成功体験を積む
To Be Continued (まだ知らない知識があれば勉強会などを開催、全員が発言しやすくなるようにMTGの進め方を工夫するとかなど)

ステップごとの実現の仕方は色々あると思うので、自分たちにあった形で実施していくと良いでしょう。たとえば、1on1 で頻繁にメンバーにフィードバックする機会があれば、そこを利用すればいいでしょうし、全員で勉強会やワークショップをしたり、個別に雑談のなかで伝えていくのも良いと思います。

ただ、理想の姿を考えるうえでの注意点として、自分の会社・組織だからここまでしかできないという制約を設けてしまうことはやめてください。それは理想の姿ではなく、現状の先入観を反映した姿でしかありません。理想の姿を考えるのは難しく思うかもしれませんが、誰でも練習をすればできます。たとえば、誰しもが「こんなに残業してるのは変だ」とか「誰もプロダクトの成果に関心がないのは変だ」といったモヤモヤを一つぐらいは持っていると思います。そうしたことを周りの状況などに左右されず解消できている姿を描いてください。最初は書籍で描かれていることを参考にしても良いです。そして、あとはチームメンバーの個性に寄りそった形でアップデートしてください。あとは、そこまでどう近づけていくかステップを考えましょう。別に間違っていても構いません。アプローチは様々あるので、ステップを実施してみて、うまくいかなければ別のステップを考えればいいだけです。もし、ステップをひとつ実施してうまくいけば、みんなでチームの成長を喜びましょう。

理想に近づけていくアプローチをまとめると、こんな感じになります。

できていないこと = 課題だ！とあまり深刻に考え過ぎない。特に解決に時間のかかりそうな(チームだけでは扱いにくい)テーマは、チームがどうなっていると良いかにフォーカスする
チームの理想の姿をイメージしてみる。その際にメンバーの個性や適性を忘れないようにする
理想の姿に近づくためのステップを洗いだして、実施する順番を考えてみる
ひとつのステップを実施してみて、理想の姿やステップをアップデートしてみる。メンバーの反応なども参考にしよう
ステップが無事にうまくいったら、チームで成長を祝う！

自分たちが直面している課題に正面から向きあうことは大切ですが、自分たちなりの理想の姿を解像度高く持ち、そこに着実に近づけていく。そして、近づくことで成長を実感できることも大事だと思います。

もし、こうした視点がみなさんのチームの成長に向けた活動の参考になれば幸いです。ぜひ、自分たちのチーム開発を楽しんでください！

*1:Agile Testing については『実践アジャイルテスト』などの書籍に詳しく書かれているので、気になる方はぜひ読んでみてください