ブログ

ryuzeeによるブログ記事。不定期更新

直近開催のScrum Alliance認定スクラムマスター研修のご案内

チームへの期待を明らかにする

みなさんこんにちは。@ryuzeeです。

この記事は現在発売中のアジャイル同人誌Ultimate Agile Stories2に掲載させていただいたものを転載するものです。

1.はじめに

アジャイルコーチという職業柄もあって今まで多くのチームを見てきた。良いチームもあれば、「うーん、これは単なる人の集団で、チームじゃないなぁ」と嘆きたくなるようなことも中にはあった。本稿では私自身がチームに期待することを明らかにしつつ、読者のチームでもこのような整理をすることをお勧めするものである。

2.1 私がチームのメンバー個人に期待すること

給料をもらえるのは、自分が会社に所属しているからではなく、その先にお金を払ってくれるお客様がいるからだ、ということを理解しよう。したがって、お客様の期待に応えられるようにふるまう責任があることを理解しよう。

こんなの当たり前じゃないか!と思うかもしれない。しかし、コマンド・コントロールに慣れたチームでは、顧客の価値や期待に関係なく、上司やプロジェクト・マネージャの言うとおりにやっておけばよいし、給料が貰えればそれで良いと考えてしまう人が思った以上に多いものである。このような思考がチームに蔓延していると、自分たちのやり方を改善する動機が生まれにくく、やっつけ仕事、力仕事になりがちである。

お金をもらう以上プロなので、プロとしてふるまうようにしよう。プロとして無理なものは無理と言おう。

顧客はあなたのことを当然プロだとみなす。プロができるといえば顧客はできると思うのは当たり前だ。そしてできないことをできるというのはプロとして誠実な態度ではない。なんとかなるかもしれない、という淡い期待は多くの場合裏切られる。

会社は自分の将来の面倒を見てくれるわけではないことを理解しよう。

世の中の変化の速度は思う以上に速い。以前は企業の寿命は30年と言われたが、グローバル化やネットワーク化によって寿命が10年以下になっていると言われている。たとえ会社が存続してもリストラや給与削減といったことも容易に起こりえる。このような状況において、会社が将来に渡って社員の面倒を見てくれると期待することは確率の悪い賭けだと理解する必要がある。

他でも通用するスキルを身につけよう。それが自分のためであることを理解しよう。

したがって、社会の速度の変化を踏まえれば、他で通用するスキルを身につけることは、自身の生存戦略の一環として考えなければならない。

プロとして自分に投資しよう。勉強は会社のためにやるのではなく自分のためにやるものだ。

会社が勉強のために投資してくれない、研修に行かせてくれない、といった話も聞くが、勉強する方法はいくらでもある。往々にして何かができない理由を外的な要因に求める人に限って、その外的要因が解決しても、別のものを言い訳にする傾向が大きい。自分に投資することで価値が上がり、選択肢も増える。どの分野に投資をするのかの見極めが重要であることは言うまでもない。

2.2 私がチーム全体に期待すること

長時間働くのが善という考えを捨てよう。

端的に言えば、労働時間の長さとその労働によって提供された価値は比例しない。長時間労働は結果的には生産性が下がるという話もある。持続可能なペースで与えられたタイムボックスの中で最善の成果を出せるようにすべきである。自分の時間を売るのか、自分の能力や成果を売るのかを考えること。

もっとうまくやる方法がないか考えよう。

同じことをずっと同じやり方でやっているのは現状維持どころか後退だ。従来型のプロセスの大きな問題点がこれで、プロジェクトの最中に継続的な改善がなされにくい。そしてプロジェクト終了後の反省会で色々な改善案やあの時こうしておけば良かった、という話が出るが、次のプロジェクトに反映されることは稀である。継続的にうまくいく方法を考えトライし続ける。もちろんうまくいかないこともあるが、その時は速やかにやめれば良い。巧遅より拙速。

チームで決めたことをなし崩しに破らないようにしよう。チームで決めたことに不満があるなら、その時に不満を表明しよう。後から他人ごとのように、「やっぱりダメだと思ってた」とか言うのは卑怯であることを理解しよう。

チームで決めた、ということはチーム全員が合意し、かつ「決まったことはやる」ということだ。またチームで決めたことがうまくいかない場合も多い。小さい挑戦を続ければ、その分小さい失敗はたくさんするのは自然な話だ。しかし決めたことは、やめることを合意するまではチームの一員としてやる。それがコミットメントだ。なし崩しを許してしまう文化では往々にして改善が掛け声で終わりやすい。アジャイル開発では責任は個人ではなくチームにある。しかしそれはメンバーが誠実な態度をとって初めて成り立つ。

誰かがやってくれるはず、という考えは捨てよう。そう思った時は自分がやる時だ。問題に気づいたらすぐ言おう。必要なら助けを求めよう。助けを求めるのは恥ずかしいことじゃないことを理解しよう

誰かがやってくれるはず、と考えてしまうのはチームの一員としての責任を果たしていない。みんながそう思っていたらどうなるだろうか?例えば、CIサーバでテストが落ちていたら、気づいた人が修正するも良し、テストが落ちていることを騒いで伝えるのも良いだろう。もちろん自分でなんでも解決できるわけでもない。そういう場合はチームの問題として遠慮無く助けを求めよう。できないことは恥ずかしいことではないが、チームを信頼して助けを求めることができないのは恥ずかしいことだ。

他人のよいところは褒めよう。そして真似しよう。

日本人は人を褒めるのが下手なように思う。が、チームとして成果をあげるためには、お互いを認め合っていることが必要だ。言わなくても分かるではなく、言葉に出すことによってチームの力が強くなる。そして自身で学ぶことはもちろん重要だが、他人から学ぶことも併せて重要だ。

自分がチームの人に何を期待しているのか明らかにしよう。

よく、空気を読め、と言われるかもしれない。しかしそれは時間のムダだ。他人に期待することがあるなら、どういう期待をしているのか、なにができていると期待に応えていることになるのか(期待の完了の定義)を定めれば良い。そうすることで進むべき道が明らかになる。

人にはそれぞれ価値観があり多様性があることを理解しよう。なのでここに書いたことに同意できない人もいることを理解しよう。

多様性はチームにとっては重要だ。みなが同じようなバックグラウンド、思考パターンをもっていると、チームとしての問題解決能力の加速度があがらないケースもよくある。お互いの違いを尊重しあうこと。ただし、どうしてもここで書いたようなチームでの仕事のやり方や姿勢に合わない人がいることもある。そういう場合は、チームとして一緒に仕事をすることが難しいので、チームとは別の仕事をしてもらうことを決断しなければならないこともある。悪貨は良貨を駆逐する、という言葉もあり、そういうところからチームの文化が壊れてしまうこともあるからだ。しかし、それは合わない人が悪いわけではない。働き方があわないだけだ、ということは理解しておこう。

3. さぁあなたのチームで!

さて上に書いたのは私がチームのメンバー個人とチーム全体に期待する内容だが、このような期待はいつチームで合意すれば良いかといえば、理想的にはプロジェクトの開始時点で合意できるのがベストだ。毎回同じチームで仕事をすることが理想だが、そうではない場合、プロジェクトの初期ではまず、単なる人の集団をチームに変える必要がある。またずっと同じチームで仕事をしていたとしても、改めて全員でチームの期待や価値観について合意をしておきたい。もちろんプロジェクトの途中だからといって遅いということはない。

どういう内容にするかはチーム次第だが、一番大事なのは、チームみんなで作るということだ。マネージャーやスクラムマスターやコーチが勝手に作ったところで絵に書いた餅だ。価値観が合意できれば改善のプロセスの第一歩はできたとも言える。是非頑張っていただきたい。

アジャイル開発チーム向けのコーチングや、技術顧問、Scrum Alliance認定スクラムマスター研修などのトレーニングを提供しています。お気軽にご相談ください(初回相談無料)
前の記事 Selenium + PHPUnitで簡単エンドツーエンドテストを実現する
次の記事 Robot Framework + Selenium2Libraryで簡単受け入れテスト

プロダクト開発で、こんな課題を感じていませんか?

  • 何を作るべきか、順位の決め方が定まらない
  • プロダクトの方向性をチームで共有できていない
  • 開発組織の体制や役割がうまく機能していない
  • 開発プロセスが形骸化し、目的を見失っている
  • アジャイルを導入したが、組織に定着しない

プロダクトマネジメント、組織構造、開発プロセスの課題について、組織全体の視点から支援します。

お問い合わせ(初回相談無料)

契約を前提にした相談でなくて構いません。相談に際して事前の整理や準備は不要です。

Aligned ―プロダクト開発におけるステークホルダーとの関係性の築き方
ダイナミックリチーミング 第2版
Tidy First?
脳に収まるコードの書き方
プロダクトマネージャーのしごと 第2版
エンジニアリングマネージャーのしごと
チームトポロジー
スクラム実践者が知るべき97のこと
プロダクトマネジメント
SCRUM BOOT CAMP THE BOOK
みんなでアジャイル
レガシーコードからの脱却
Effective DevOps
変革の軌跡
ジョイ・インク
アジャイルコーチの道具箱
カンバン仕事術
Software in 30 Days
How to Change the World