アジャイル開発している人にインタビューしてみた

今回はTSOneで初めてアジャイルの研修を受け、社内で初めてアジャイル・スクラムを導入した先輩に、いろいろインタビューしてみました。いろいろとネットとかで記事は見るものの、実際の体験談を聞けるというのは非常に貴重な機会でした。是非ご一読ください。

―　まずは、いつどのようなアジャイルの研修を受けられたのですか？

10月の終わりから12月の頭まで、総計120時間の「高度IT技術を活用したビジネス創造プログラム」という、DX時代に向けた高度IT人材を育成するという研修の中の1メニューとして、12月の頭くらいに受講しました。VUCA※１時代に求められる開発手法として、その講義の中ではアジャイル開発が推奨されていました。

－　現状、VUCAってわけでもないと思うのですが、アジャイル開発、スクラムを取り入れたきっかけって何だったのですか？

実際にスタートしていた案件に取り入れた、ということもあって、いわゆるプロダクトオーナーがいて、というようなアジャイル開発を目的として取り入れたわけではなくて、もっとコアな部分、『チーム化を促進する』ということを目的として取り入れました。だから開発全体としては従来のウォーターフォール型なのだけど、チーム化にフォーカスしてアジャイルを取り入れた、というのが正解かもしれません。

－　『チーム化を促進する』ということをもう少し詳しく聞かせて頂けますか？

はい。少し前になりますが、ラグビーワールドカップで活躍した日本代表のことを思い出してほしいのですが、彼らは試合中、監督からの指示というものは殆ど受けないそうです。ではどのようにチームが機能しているか、それは、試合前からの目的共有と試合中のチームメンバーのコミュニケーション、そしてゲームキャプテンのキャプテンシーです。チームメンバーが自分の考えをきちんと伝えられる環境があり、キャプテンがそれを尊重して、最終的な判断を下す、ということをきちんと行っているから、チームがきちんと自己組織化され機能しているのです。私もそういうチームを目指しました。

－　なるほど。それではチーム化を促進するために具体的にどのような方策を取られたのですか？

今までは顧客からの要望がまず自分宛にチャットできて、各メンバーにそれぞれタスクを割り当てていく、というやり方でした。もちろん自分が咀嚼してタスクを割り当てていた分、想定外の方向には進みにくいというメリットはあったけれども、さっき言った通り、研修にも多くの時間を取られていた当時の状況は、どうみても自分のオーバーヘッド、パンク寸前でした。その状況を改善するために、まずは自分宛に来ていたチャットをメンバー含めたグループチャットにして、顧客の要望、タスクを受け取れる人が自ら受け取れるようにしてタスク化を行い、そのまま全員に共有できるようにしたことが一つ。もう一つはこちらから進捗確認するのではなく、チームメンバーが自ら自分の状況を発信できるようにしたことです。もちろん、これらの施策を実行するために仕組みを変えるだけでなく、現状の問題点と自分のチームに対する思いを伝えるところから始めました。

－　仕組みとしてはカンバンとKPTを使われていたようですが。

カンバンは、チームメンバーの誰が何をしているかが他の人から見えづらいっていう状況があったので導入しました。私自身もどのタスクでいっぱいになっているのかを見せるようにしていますし、他のメンバーも自分の取ったタスクに対して、このように実施している、ということをアピールしてほしい、と話しました。

あと利用していたKPTは、最初のころは毎週振り返りしていたのが本当に有効だった。最近ではだいぶプロジェクト自体が収束してきて、あんまり振り返ることなくなったけど。始めた当時は意識付けの意味合いもあって、みんなに見える化するためにホワイトボードを利用していたけど、意識付けの部分も定着できたので、今はWeb上で行っています。

－　ペアプロ(ペアプログラミング)の導入は検討しなかったんですか？

ペアプロは導入した時点でプロジェクトの製造が半分ほど終わっていたことと、製造工程で躓くような内容もなかったから今回は導入しなかった。やってもいいかもね、という話はチーム内でもしていましたが。次になんかあれば採用したいとは思っています。

－　カンバンについては作業時間の目安とかどうされていたのでしょうか？

最初研修で聞いていたときはなるべく短い時間(1時間とか)で区切るのが基本ということだったけれど、目的がタスクの見える化だったので、そこまで細分化にはこだわりませんでした。大き目のタスク粒度でいいから見積時間を書いてもらうような進め方でした。

－　大き目というと一日を超えるようなタスクサイズもあったのですか？

そこは一日で終わるようなレベル感で作ってもらいました。一日を超えるタスクは分割してもらって、基本的には２，３時間で終わるタスクを基本とするようなレベル感にしてもらいました。

－　その進捗自身が遅れているとかの管理はどのようにしたのですか？カンバンとは別ですか？

はい、別で管理していました。実際全てがアジャイル化されていれば、成果物の完成度で進捗を管理するところですが、一部だけ取り入れたこともあり、顧客に進捗を報告するためのスケジュールは別にありました。なので、カンバンから顧客報告用の進捗に変換して顧客への報告を行っていました。

顧客への報告は一週間単位だったので、内部での進捗確認としては日々タスクにかける時間を調整することはあったけれど、顧客向けへの進捗は大きく狂わなかったように思います。

－　スプリントで回して開発していたのですか？

本当だったらプロダクトオーナーが機能一覧を作るとこからなのだろうけど、機能一覧はもうできてたこともあって、それぞれの機能を誰がやるとか、実装の説明もプロダクトオーナーがいないので、私に対して行ってもらうようにしました。実際にスプリントで回すことができた期間は1週間のスプリントを3周しかありませんでしたが、繰り返しの中で振り返り(KPT)はできたので、その繰り返しの中で改善する、というやり方はできていたと思います。

－　実際どんな改善ができたのでしょうか？

改善は物理カンバンでやっていたので、昔のKPTの付箋とか捨てちゃったので正確ではなく、申し訳ないのですが、最初はメンバーが指示待ちで積極的ではなかったかな、と思います。それに対し、一回目の振り返りでもっと積極的に行こう、という話をして、タスクがないのであれば、別のタスクを探していた、だとか。他の人がみえていないけど、やる必要があるものとかを提示して、周りと相談してやることを決めてくようにしましたが、最初は戸惑いが多かったのかもしれません。

最初はメンバー間でコミュニケーションが少なかったこともあり、会話が少ないとかそういうのでもいいから出してほしいと伝えました。それでランチを一緒にするタイミングを作るとか、実際の開発に対する指摘よりも、チーム化、チームのコミュニケーションに関する改善が多かったような気はします。

－　スクラムを実際に行ってみて苦労した部分ってありましたか？

あまり苦労した、って印象はないけど、自己主張が苦手かな、ってメンバーからどう引き出すか、みたいなことは考えましたけど。結構両極端なメンバーが揃ってました。一方はアグレッシブで、もう一方はディフェンシブ、みたいな。まあ、そういうコミュニケーションのスタイルはアジャイルだから困るようなものではなくて、ウォーターフォールで開発していても考えなければいけないものだから、スクラムの苦労ではないのかな、と思います。ただ、スクラムで見える化したからこそ、いち早く気づけたのかな。

－　ということは改善されていった内容としては、問題を早期発見できるようになったことと、自己発信の習慣作りができた、ということでしょうか。今回はウォーターフォールとアジャイルのハイブリッドな開発ということで、難しい質問かもしれませんが、アジャイルに比べてウォーターフォールが優れている、というのはどういうところだと思いますか？

難しい質問ですね(笑)。今回は今のチームに一番自然に取り入れられるように部分的に取り入れたので、完全にいきなり切り替えるよりも自然に取り入れられた、という意味ではハイブリッドはいい選択だった、と思っています。とはいいつつも現状できることをやった結果、このやり方になった。実際にアジャイル、スクラムを全面に押し出して開発するには、案件の契約時に、そのようにします、と宣言しないと無理なんじゃないかな。そういう意味で優れている、という話になると、ウォーターフォールの案件の方が現状圧倒的に多い(笑)。

ただ、顧客との信頼関係をがっちりと握れれば、このチームメンバー全員が自己発信して進めるスクラムというやり方はメリットがたくさんあるので、できる限りどんどん取り入れていきたいと思います。

－　そうは言ってもコミュニケーションに手間暇かけた分だけ工数がかかった、みたいなデメリットとかはないんでしょうか？

スクラムだから、というよりは、本人も発信していかないとダメ、という意識をもってもらわないと指示待ちになると思うのですよ。今回スクラムをやった結果というよりは、チーム化したい、という自分の思いをメンバーに伝えた段階で一定の成果が出たのかな、って思っています。そのいい状態を、今までずっと続けられている、というところは、スクラムの繰り返しと短い期間で振り返るっていうところが寄与していると思います。

今日インタビュー受けて改めて思ったのは、小さく分割するっていうことが、コストを抑えることに直結しているな、って。開発もそうだし、コミュニケーションもそう。問題が小さいうちに対処することが大事。大きくなってからの問題は本当に大変だから。

－　そもそも自己発信とかコミュニケーションとか、細かく振り返って改善していく、というのも、仕事全般でホントは絶対必要な内容なのだけど、ウォーターフォールでの開発だと、上の人が下の人に指示して、得意な人ができる作業をやってしまうという進め方自体が、そういったコミュニケーションとか自己発信とか、振り返りの機会を作りにくい仕組みになってしまっている可能性がある、そういう状況にせずに、自己発信とか振り返りを仕組みとして意識できるようにしてくれるのがアジャイルの一つのメリットなのかなって思いました。

そうだね、それは感じていますね。

－　私はもともとチームとは、コミュニケーションが相互にあるのが、あるべき姿だと思っていましたが、今まで見てきた開発チームでは、ちょっとコミュニケーションを取り切れてないところが多いかな、って思っていました。そこを改善する方法として、お客さんに交渉して完全にスクラムにするのは難しくても、今回みたいに部分的にハイブリッドにして、内部にアジャイルを入れることで、そういった自己発信とかコミュニケーションを進めていけるのと、振り返りも入れていけてどんどんチーム自体の動きをよくしていけるようなので、積極的に取り入れてみたいと思います。

研修を受けたときの講師の人に、アジャイル・スクラムは開発方法じゃなくてマインドセットだ、ってすごく言われていて、確かにそうなのだろうと思います。アジャイルの場合、どうやって開発しろとかそういうことは一切決められていなくて、ウォーターフォールだとこの工程この工程でやるべきことが決まっているけど、そういう何をやるのかっていうのは自分たちで決めろという。だからアジャイルは部分的にどこででも取り入れられると思っています。

チームで作業を行っている、というのは他の人がやっている作業を知らなくてもいい、ということではなくて、自分たちが顧客に納めるシステムの機能や体験をチーム全員が共有している状態だと思います。だから、ある一人のメンバーしかそのことをやっていなくても、それが属人化しているということは決してなく、相互でコミュニケーションがとれて、それぞれのタスクがどういう状況になっているか全員が共有できている。そういう状況であれば万が一チームメンバーが急に入れ替わっても致命的な問題にはならないのかな、と。

－　今回実際やったことは、お互いにコミュニケーションとれるようにしようねと、よくないところを治していこうね、ですから、デメリットあるはずがないというか。

仕事のやり方、請負としては今まで通りで、そういうマインドセットを変えただけなので、ホントはウォーターフォールにもこういう今まではヒューマンスキルって言って各自で努力しようっていう話だったのだけど、各自で努力しようって結構厳しくて、やらない人も出てくるし、やっていた人との差が激しくなって不満につながったりもするし、だったらみんなでやろうよっていう、仕組化された方が、チームメンバー全員が幸せだと思うのですけどね。だから今後の開発でちゃんとしたスクラムとかアジャイルとかできたらいいな、とは思いますが、もしできなくても内部でやりようはあるのかな、って思っています。

－　そうですね。大きなインパクトがでないように仕組化されたアジャイル・スクラムを実践して、私も幸せになりたいと思います(笑)。今日はありがとうございました。

ありがとうございました(笑)。

# 感想

アジャイルとかスクラムはチームがよりチームとして動けるようにするためのコミュニケーションや改善を仕組化して実践しやすくしてくれるものなのだと思いました。現在のウォーターフォールの案件をスクラムに変更することはできなくても、部分的に取り入れて説明することでチームをよりよくしていくことはできるので、柔軟に取り入れてチームの改善につなげていきたいと思いました。

※１ VUCAとは

Volatility（変動性）、Uncertainty（不確実性）、Complexity（複雑性）、Ambiguity（曖昧性）の頭文字を並べたアクロニム。1990年代後半にアメリカ合衆国で軍事用語として発生したが、2010年代になってビジネスの業界でも使われるようになった。「今はVUCAの世界になった」というような文脈で使われることも多い。

https://ja.wikipedia.org/wiki/VUCA