開発チームの立ち上げで見るべきものは何か　方法論ではなく人中心で考える、アジャイル開発のコツ

プロダクトオーナーがアジャイルへの正しい期待を持っていた

岡本卓也氏（以下、岡本）次に、幸運だったことの話にいきます。良き理解者と良いチームという話です。

良き理解者というのは、ここではプロダクトオーナーのことですね。何よりプロダクトオーナーがアジャイルへの正しい期待を持ってくれているというのが、すごくラッキーだなと思っています。よくあるアジャイルへの勘違いなどが一切なく、「チームに成長してほしい」という明確なビジョンをいつも示してくれます。

チームや永和への信頼も厚いので、チームとしてもすごくやりやすいです。なのでPOには感謝しかないのですが、現場を信頼してくれて、適切な権限委譲をしてくれるとチームは本当に動きやすいなと思います。

ポテンシャルのあるメンバーを集めてモチベーションを高く保てば、チームは勝手に成長する

それから良いチームですね。先ほど「チームビルドをがんばった」という話をしましたが、実は半分ぐらいは最初から良いチームでした。

メンバーのポテンシャルもすごいし、バランスも絶妙だし、見た時に伸びしろしかないなという印象を持ちました。なのでチームビルドは、単なるきっかけにしか過ぎなくて、勝手にどんどん成長しているんじゃないかなと思います。良いチームがいてラッキーだったなという話なのですが、チームを作る時にポテンシャルのあるメンバーを集めてモチベーションを高く保てば、あとは勝手にチームが成長していくんじゃないかなと思います。

アジャイルの一番の肝は「人を中心に考える」こと

最後にちょっとまとめに入ります。いろいろな話をしましたが、今日話したことは実は全部人の話なんですね。がんばったこととか、がんばり過ぎないこととか、幸運だったことの対象や目的は全部人にかかっていると思います。

アジャイルチームの立ち上げと言うと、どうしてもプロセスなどの方法論に目がいくのですが、本当に見る必要があるのはそこじゃなくて、真ん中にある人だと思います。この、人を中心に見て考えるという考え方がまさにアジャイルの本質なんじゃないかなと思っています。

これはよくあるゴールデンサークルの考え方で、私はこれが好きなんですけれども。これを今回のアジャイルの話にちょっと当てはめてみると、「アジャイルチームを作りたい」というWhatがあって、プロセス、ツール、ノウハウなどのHowがあったとしても、本当に注目するのはそこじゃなくて、Whyのところにある「人をエンパワーしたい」というところ。

そもそもなんで自分たちはアジャイルをやりたいのか、というところを見ないといけないのかなと思っています。これも「プロセスやツールよりも個人と対話を」という、有名な一節（「アジャイルソフトウェア開発宣言」より）で、もちろんいろいろな解釈がありますが、先ほどの話で考えると、ここでいうWhatやHowよりも、Whyに来る「人をエンパワーしたい」というところに価値を置くべきなんじゃないかなと思います。

繰り返しになりますが、人を中心に考えるというところがアジャイルの一番の肝じゃないかなと思っています。とはいえ、人を中心に考えましょうというのは、フワッとし過ぎてちょっと具体性に欠けるので、別の言い方がないかなと思って考えました。

例えば、開発チームを立ち上げる時に、普通はやはりプロダクト起点になると思います。この時にちょっとだけ視点を変えてみて、「このプロダクトを開発したい」じゃなくて「この人と開発したい」と思えるかどうかをちょっと考えてみたらどうかなと思います。

ここでスッと「そうだな」と思えるのであれば、今日お話ししたような成功するための条件は、かなりいいところまで来ているんじゃないかなと思います。

逆に、「そんな発想はなかったわ！」という場合、もしかすると人に関する検討とか見落としなどがあるんじゃないかなという気がします。なので、チームを作る際の1つの考え方として参考にしてもらえたらなと思います。

あとは、ちょっと最初に戻りますが、このサービスもやはり対象は人なんですね。「人づくり」と書いてあるのですが、やはり人が大事なんですよというのをあらためて強調しておきます。以上になります。ありがとうございました。

（会場拍手）

チームビルディングに時間をかけたくないクライアントにはどうするか？

司会者：ありがとうございました。ここから5分間のAsk the Speakerに移ります。ご質問がある方は挙手をお願いいたします。いかがですか？　

（会場挙手）

司会者：ありがとうございます。お願いします。

質問者1：お話ありがとうございました。「人中心でチームビルディングをされた」という話を聞いて、すごく強く共感しました。

チームビルディングの時間を、たっぷり2ヶ月ぐらい時間をかけてやられたと思います。私の体験談ですが、クライアントによっては、まったくそういったチームビルディングの時間を取っていただけないというか、承認いただけない。

私も「非常に重要です、人が中心です」と、提案をするのですが、「そうじゃなくて、プロダクト開発に時間を使ってください」と言うクライアントも多いと思います。そういったクライアントに対して、そもそも提案した時にOKをいただけなかったらお仕事を受けないのか、それともまた別のアプローチで提案するのか、どういったことを（クライアントに）お聞きしたいのかと思っています。

岡本：弊社の場合、なるべくこういうのを気持ち良く「いいよ」と言っていただけるお客さんと一緒にやりたいなという気持ちを常に持っています。なのでそちらにいきたいなと思っていますし、そういけるように会社としてがんばっているというところがあります。

あとちょっと補足すると、2ヶ月というのは、2ヶ月間丸々お金をもらってやっていたわけではなくて、その中でちょこちょこやっているだけです。

なので、本当にお金をもらったのは最初の2泊3日のところ。そこにはお金を出してもらいました。やはりそういうのを気持ち良くできるお客さんとやらないと、なかなかアジャイルはスッといかないなというか、余計な苦労をするんじゃないかなと思いますので、なるべくそっちにいきたいなと思っています。

質問者1：わかりました。

司会者：ご質問いただき、ありがとうございました。

契約が始まる前から会話をすることで信頼関係が構築できた

司会者：その他にご質問はいかがですか？

（会場挙手）

参加者1：じゃあ、次はこちらにお願いします。

質問者2：幸運だったことの良き理解者の中で、チーム、永和さんへの信頼というのがあったんですけど。なぜ信頼していただいていたのか、その要因はどんなことがあったのかをお聞きしたい。あ、ちょっと困られていますね（笑）。

岡本：（笑）。

質問者2：お聞きできたらと思います。

岡本：実は契約が始まる1年ぐらい前からかな？　いろいろとコンタクトをいただいていて、事前にずっとお話をさせてもらっていたんですね。いきなりパッと会って始まったわけではなくて、事前にお互いにいろいろな話をして、たぶんお互いに価値観が合うだろうなと確信した上で始めたので、今回は始めからわりとスッといけたんじゃないかなと思います。すみません、答えになっていますかね？

質問者2：ありがとうございます。ここでも会話の量が大事だというのをすごく思いましたし、やはり継続して関わることが大事かなと思いました。

岡本：ありがとうございます。

司会者：ありがとうございました。

“開発者なのにテストばかり”はどう解決した？

司会者：その他のご質問はいかがですか？

参加者2：「Miro」から1件いいですかね？　オンラインの方もいっぱい書いてくださっているので、1件取り上げさせてください。「冒頭でテストから開放されたいとありましたが、こちらはどのように解決したのでしょうか？」というのがあります。

平井：そうですね。結合試験は3チームに分かれて開発を行っていたので、3チーム分のテストを私たちが作って、それを実施するというかたちでやっていました。そこでかなり工数を使ってしまっていたのですが、自社チームだけで作って、自社チームだけでテストすれば、作ったもののテストをすればいいので手戻りがないというか。

別のチームに「ここが原因だから、ここを直してください」というパスする時間というか、待っている時間がなくなったのがかなり大きいなと思っています。これで答えになっていますかね？

参加者2：はい、ありがとうございます。

「偏愛マップ」を用いることでメンバーの興味・関心を知ることができた

参加者2：あと一方ぐらいいける気がします。

参加者1：じゃあ、次こちらにいいですか？

質問者3：ご講演ありがとうございました。仕事をする時には、人がすごく大事だというところが非常に伝わって大変興味深いご講演でした。

チームビルディングをする時に「自己紹介をした」というお話がありましたが、自己紹介にはいろいろなやり方があると思っています。

例えば、どういうことを自己紹介で話すとお互いの仲の良さがすごく加速するのか。こういう自己紹介をすると、みんなからこういう反応がすごく得られて仲良くなるとか、すごく加速したとか、こういう反応があってすごく良かったというところの部分のお話を聞かせていただければと思います。

平井：今回は偏愛マップを用いて自己紹介を書きました。できるだけいろいろな範囲の自分の好きなものや興味のあることを書いていこうというふうにしました。なので、5年間ずっと一緒に働いていたけれど知らなかった自社のメンバーの好きなことだったり、興味だったりを知ることができたのも非常に大きかったと思っています。

岡本：ちょっと補足すると、偏愛マップというプラクティスを使いました。気をつけたのは仕事の話をほとんどせず、プライベートのことしかしゃべらなかったことです。なので、会った時に実はチームの大半の人がアニメ好きということが判明してそこで盛り上がったり（笑）。「仕事でこれをやっていました」みたいな話じゃなくて、その人のパーソナリティというか、個人を開示することを意識してやると、すごく仲良くなれるんじゃないかなと思います。以上です。

質問者3：ありがとうございました。ふだんから仕事をしているメンバーの意外性を見つけたり、その範囲を広げることによって共通するところを見つけるというイメージでやっていくと、仲の良さが加速するというか、仲の強化になるのかなという理解で聞いていました。ありがとうございます。

司会者：ありがとうございました。お時間となりましたので、講演を終了させていただきます。ありがとうございました。