9
12

More than 5 years have passed since last update.

面白くないことをちゃんと見る話、あるいはKPTの実際、またはコミュニケーションの必要性

Posted at

コミュニケーション AdventCalder 最終日の記事です。

考えてみたら、Qiitaってコミュニケーションツールなわけだし、ある意味で最もQiitaらしい AdventCalender だったのかな?

そんな最終日の今日は、面白くないことについての話をします。

全てを明るみに出すこととそのストレス

僕の好きな本、「アジャイルサムライ」のコラムがちょっと面白いので引用をします。

とある事業部長に、アジャイル開発についてどう思うかを尋ねたことがある。彼の答えはこうだった。「愛憎半ばする思いだよ」と。その事業部長は、アジャイル開発がプロジェクトにもたらす見通しの良さは気に入っているそうだが、その一方で見通しの良さを気に食わないとも感じているそうだ。以前なら都合の悪いことがあっても、何もかもうまくいっている振りをしてればよかった。砂に頭だけ突っ込んで姿を隠したと思い込んでいるダチョウみたいにね。ところが今は、都合の悪いこともあきらかになってしまう。それも毎日。事実が、プロジェクトのありのままの状況が目の前に突き付けられる。どれだけ改善が必要なのかを常に意識しなきゃならない。それが良いことなんだと頭ではわかっていても、やはり複雑な思いを隠せないそうだ。

引用元:アジャイルサムライ p.171

僕達のチームでは KPT を利用したチームの振り返りを行っていることを以前にQiitaの記事にまとめました。この振り返り会では沢山の Problem が発見されます。ちょっと幾つかをピックアップしてみましょう。

  • 大きすぎる Issue を作っていたため、期間の見積もりが正しくできず、想定した期間内に Issue が終わらなかった
  • Issue 作成時には想定できなかった依存関係によってタスクの量が増えため、想定した期間内に Issue が終わらなかった
  • コミュニケーションが足りないため、 Issue についての認識に違いがあった
  • タスクにかかる時間の見積もりが正しくなかった
  • Pull Request が常に同じ人にアサインされているので、「みんなでメンテナンスができる」コード作りという目的に沿っていなかった

だいたいこんな感じの Problems が何度も登場します。もちろん、僕達は何もしていない訳ではないです。

Problem に対して Try を用意して実践します。しかし、その多くは根本的解決に直結するわけではありません。何週間に渡って同じタイトルの Problem が登場し続けます。実際には Try によって変革が行われているので、全く同じではありません。

つまり「Issue が終わらなかった」という Problem の原因が Try を経て「Issue が大きすぎた」とかから「想像できなかったタスクがあった」とかに変わっていきます。

ただ、用意をしたバーンダウンチャートが消化できなかったという事実は同じです。

スクリーンショット 2015-12-25 5.39.00.png

同じ Problem が居続けることは少なくとも僕にとってはストレスでした。なんで色々やってるのに良くならないのだろうか、そんなことを考えるわけですね。

ダチョウのように 問題を直視せず過ごしていた時と比べて、考えることも増えました。これは多分ストレスなのでしょう。

面白くない物をちゃんと見るために

面白くない物、 KPT で言うところの Problem はそれ自体がストレスであり悩みの種です。しかし、我々はそれをはっきりと直視する必要があります。

そこで、この数ヶ月間で気がついた「面白くない物をちゃんと見る」のに必要な要素を紹介します。

チームで立ち向かう

面白くない物、問題にはチームで立ち向かってください。自分一人の問題では無いです。

よく「私の努力が足りなくて、タスクが終わりませんでした」なんてことを言う人がいますが、はっきり言って間違いです。仕事中にサボったりしてない限り、それは人間一人が原因ではなく、チームのスピード感を誰も把握できてなかったことが原因です。

そんなことがよくあります。問題はチームで共有し、原因にチームで立ち向かってください。そのための武器がコミュニケーションです。

なぜ面白くない物を見るのか

ポエム感が結構出たので、このままポエムで押し通しますね。

なぜ、我々はストレスであり悩みの種である「面白くないこと」に立ち向かうのでしょうか。僕の場合についてですが、またアジャイルサムライから引用をします。

ここで疑問を抱いた読者がいるかもしれない。プロジェクトの仕事量が、とても開発チームにはこなせないぐらい多いものにもかかわらず、スコープを柔軟なものとして扱うことをお客さんから拒まれたらどうすればいのか、と。
良い質問だ。このときの選択肢は2つある。
ひとつは、ごまかし続けることだ。見なかったことにして、古くなってしまった計画に従い続けるんだ---他のみんながやっているように。楽観的すぎる見積もりをしたり、見積もりを水増ししたり、チームのベロシティを無視したりしながら、「最後には何もかもよくなりますように」と祈ってもいいだろう(これは「奇跡によるマネジメント」という有名なマネジメント手法だ)
そうじゃなくて、事実をありのままに打ち明けるのがもうひとつの道だ。どうなっているのかをお客さんに報告して、気まずい沈黙のなかで座ってひたすら待ち続けるんだ---どうやら君は諦め無さそうだ、とお客さんが折れるまで。うわべだけを取り繕うんじゃない。共犯者になろうとしちゃだめだ---私達の業界が過去40年にわたって続けてきた、ひどい誤魔化しに加担するんじゃない。私はアジャイルサムライの道が簡単だなんて言ったおぼえはない。

引用元: アジャイルサムライ p.154

初めて読んだとき以来、このページの衝撃が忘れられません。共犯者になろうとしちゃだめだ 、と言われたらストレスや悩みの種に飛び込むのも良いかなと思っています。

動機は人それぞれでしょうが、それなりに何かがあると良いと思います。

まとめ

あんまりコミュニケーションの話でもなくて、以前に自分が書いた KPT の話の補強になりましたね。

とは言え、 KPT の中で発生する Problem に立ち向かうためにはコミュニケーションが欠かせないわけで、その必要性は最初に僕が思い描いていた物以上です。

コミュニケーションの方法はそれなりに一般化できそうですが、やっぱりチームが違えば人も違うので一筋縄ではいかないのでしょうね。

しかし、コミュニケーションが必要であるということは普遍的だと思います。新卒の募集要項に「技術力も大事だけどコミュニケーション力の方が大切」と書いちゃうのも分かります。

無限に続くであろう、チームの悩みやコミュニケーションの話題をこれからも皆様がアウトプットし続けてくれることで、コミュニケーション界(?)がより良くなることを期待します。

それでは、メリークリスマス。

9
12
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
9
12