第6章 より効果的なアジャイル:チーム文化
そのうち、ソフトウェア開発作業にとって重要となるのは内発的なモティベーション❷だけである。企業は事実上、人々の脳内のスペースを借り上げ、企業が従業員に考えさせたいことを考えてもらうために賃金を支払う。外発的なモティベーションがうまくいかないのは、何かについて考えることを人に強制するのは無理だからだ。あなたにできるのは、企業の問題について自主的に考えたくなるような状況を整えることくらいである。
これが言われて当たり前になってきたから、コーチングとかカウンセリングとか1on1とかOKRの重要性を企業レベルで認知できるようになってきているんだろうな。これが、20年前なら建前で終わっていたような話な気がする。
Drive ダニエルピンク
6.2基本原則:成長マインドセットを培う
リーダーがチームの成長に目を向けていないと、プロジェクトが進行する過程でチームがバーンアウトし(燃え尽き症候群に陥り)、プロジェクトの開始時点よりもキャパシティ(生産力)が低下するという事態が容易に起きてしまう
その結果、チームがバーンアウトしてしまい、最も優秀なチームメンバーが他の組織へ去ってしまい、組織のキャパシティ(生産力)が徐々に低下していくことが予想される。
新卒1,2年の頃は上記をうまくビジネス側(という括りが良いかどうかは置いておいて)の責任者に伝えられていなくてチームメンバーが疲弊して退職という自体を引き起こして大いに反省した記憶がある。ビジネス側は悪意があるわけではなく、上記の想像ができていないだけということがわかったので、最近はチームが将来的にどうなったら理想か(相手にとってのメリットがどうあるか)について定期的に雑談するようにしている。
今の周りのメンバーがそこそこ手練れ職人系プログラマーの多いので、バーアウトを防ぐ成長マインドをどう維持するかが最近の課題
ある程度、問題解決し終わったり、困らないレベルでスキルが見につくとそこで止まってしまう問題。問題に目が向いているのか、高い目標や顧客に目が向いているかの差なのかな?
「チームワークの改善」は実感しずらく、かつ計測ししずらいと思っている。今は、チーム内ではふりかえりで褒め合い(ウィンセッション)で確かめ合っているけど、外にチームワークがよくなっていることをアピールするにはどうすればいいのかな
まずは土台として持続可能なペースがあるんだな、というのが明確に書かれていてよかった
高度にマトリックス化された個人を集めただけで、本物のチームになっていない
アジャイル型人形の話だ。。。うぅ。。。避けられているのか自分でもわからない。。。
動くソフトウェアを作ることはもちろんプロジェクトの目的の1つだが、そのソフトウェアを作るチームの能力を向上させることも目的の1つである
半期ごとの目標管理がどこの組織に行ってもあるけど、プロジェクトごとだったり、プロジェクトのマイルストーンごとに目標を決めて振り返りや評価を行うほうが有意義なのかも。と思いました。
6.3基本原則:ビジネスフォーカスを培う
ユーザーと直接交流することで開発者は人生が変わるような体験をすることがよくある。これまで技術的な純粋さ(と称するものが何であれ)を唱え、ユーザーを不合理な機能要求をしてくる目障りな存在と決めつけていた開発者が、使いやすさとユーザーの満足度の番人になるのである。
ここで重要となるのは、ユーザーとの交流が1回限りの体験ではなく、継続的なプログラムとして実施されることである。そうしないと、ユーザーとの1回の交流で目撃した問題に開発者が固執するようになる可能性がある。ユーザーの問題をバランスの取れた視点で捉えるには、ユーザーとの継続的な触れ合いが必要である。
継続的なプログラムとして実施できているかというと...うーん。結構準備するのが大変で専門でやっていた頃に比べるとなかなか手が回らない。。でも、一度でもユーザーとの交流を体験するとプロダクトの使われ方に関して自分ごと感が一気に増すからなのか、その後メンバーから「ユーザーインタビューに同席したい」とか「ユーザーテストしたい」という話が出てくるようになった。初回実行できればその後はやりやすくなるかもしれない。
6.3(ユーザーと直接交流することで)開発者は人生が変わるような体験をすることがよくある
自律・熟達・目的を養うプラクティスのいずれも、既にその大切さを分かっていたり、興味があったりする人に刺さる。一方で、刺さらない人にはずっと刺さらない印象がある。他の方の認識を聞いてみたい。
ひと昔前の自分だったら、刺さらない側の人間だった。
開発エンジニアの方、ただでさえやるべきことが多いのにビジネスフォーカスを培ってもらうにはどうしよう
短いタイムボックスで、顧客や顧客の発した情報と少しずつ接する
具体的なユーザーを知ると実装時に色々考えるのがとても楽になる。
社内システムの開発だと、チャットですぐに聞けるし、デモも見てもらいやすいし、すぐフィードバックもらえるのはモチベーションの維持に良いなぁと思った。
「内発的なモチベーション」の維持、みなさんできていますか?
読書でも、初日と数日後ではモチベーションが下がっているのを感じます。同じ作業を数日続けた時も下がっているのを感じる。
新鮮さとか、楽しさが薄れていく
黙々と作業していると忘れがちなので、過去の日記とかで思い出そうと心がけている
チームの能力は自己実現と役割のバランスが取れている場合に最も発揮される傾向にある。
わかるわー。っていうかここのバランス悪いと、転職するよね。。。
「自己実現と役割のバランス」について理解できませんでした。チーム全体で必要な役割と、メンバの習得したいスキルがマッチしていないとかですか?
ベルビンが提唱している役割は次の9つである。
■Plant(高い創造力を持ち、難題を解決する)
■Monitor/Evaluator(すべての選択肢を公正かつ論理的に評価する)
■Specialist(専門知識を提供する)
■Shaper(障害を精力的に克服しながら目標を追求する)
■CompanyWorker/Implementer(アイデアを積極的に実践する)}
■Completer/Finisher(正確な作業を期日どおりに行う)
■Coordinator/Chairman(目標を明確化し、意思決定を促進する)
■TeamWorker(潤滑油としてチームの共同作業を支援する)
■ResourceInvestigator(チームの外で機会を発掘する)
なるほどみはあるな。網羅されているのかはわからないが。
期日通りに行うが入っているのが、理解できるけれど、ほんの少し違和感がありました
メンバーからの信頼とかありそうだと思いました(信頼は行動の結果なので、入らないと思いました。)
6.5推奨リーダーシップアクション
検査
■表6-1、表6-2、表6-3のリストを再確認する。それらの表の項目に照らして、あなたの対人スキルはどのように評価されるだろうか。
自律 => "高度にマトリックス化された個人を集めただけで、本物のチームになっていない" にYESと言える自信がない。YESというためにはどうなっていればいいのか。。。, 熟達 => OK, 目的 => OK
自律..."高度にマトリックス化された個人を集めただけで、本物のチームになっていない", "チームの解散と再編成を頻繁に行う"はNoかな。。熟達...OK, 目的..."組織にとって質の高い作業に価値があることを強調する"はできていない。なので、森さんの太い経験の話はぶっ刺さった。
自律…結果として自律性を損ねる方法をとってしまっている気がする。(部署内で進められている標準化で細かい部分に対して関心を持たざるを得なかったり、やってたことに対する方向性を変えたり…)、高度にマトリックス化された個人を集めただけで本物のチームになっていない⇒今のチームは今回の案件で集めたメンバーで自分以外が社外から来ている人なのもあり、依頼されたものを作りますっていう感じになりがちで、そこに対する対処ができていない。熟達…OK、目的…先に述べた背景もあり、ユーザとのやり取りを全部自分でやってしまうなど、意図せず目的意識を損ねる方法になってるなぁ…(キャパオーバーしつつあるけど振れる部分が少ないみたいな感じでツケを払うことになってますが。)
■表6-1、表6-2、表6-3のリストに照らして、組織の他の人はどのように評価されるだろうか。
自律 => チームを維持できている人は少ないがそれが仕方ないとされているような気もする。熟達 => OK, 目的 => 最低限はできている気がするけど、ほしい状態には到達していなさそう。
組織というか自分のまわりに限った話だと、これは割とやばそう。。自律..."高度にマトリックス化された個人を集めただけで、本物のチームになっていない", "チームの解散と再編成を頻繁に行う", "作業の実行方法の細かな点にリーダーが関心を持つ", "チームの経験に関係なく、あらかじめ決められたプロセスを共生する", "間違いを罪とみなし、チームを罰する"はNoかな。。熟達...レトロスペクティブは反対はしないけど週に1時間以上は多いと言われている、トレーニングに時間を割くことを許可しない(業務外でやってとなる)、ひたすらタスクに集中することを強要する(作業報告書でタスク以外の時間で無駄(と思える)ものがないかをチェック), 目的..."開発者が顧客と直接やり取りすることを制限する", "組織にとって質の高い作業に価値があることを強調する", "不定期に行われるミーティングでのみ全体像を伝える", "全体像はリーダーのみが知る情報である"は該当。
■各プロジェクトまたはリリースサイクルの最初と最後に、チームに自身のモティベーションとモラルを数値化してもらう。それらの数値から、チームが持続可能なペースで作業を行いながら成長していること、あるいはバーンアウトしていることがわかるだろうか。
チームのヘルシーに関するメトリクス取りましょうってJeffもやっていたな。やってみるかなぁ。。。なんか良さそうなテンプレがなくていつもやっていない。こういうのが結局のところタレントパレットとかに吸収されているんだろうな。
バーンアウトが何かの達成直後に突然来たりするから事前にはわからなそう。実際に数値を取ってみると、事前の兆候とかわかるのかな。
モラルのイメージが湧かなかった。。エンゲージメント的なものやモチベーションは継続的に取っているのと、プロジェクト後にはふりかえりの時間を入れて、そこではモチベーションがどう変化したかをみんなで書いている(プロジェクト前も、どんな感じになりそうか予想でモチベーション曲線を書いている)。持続可能かは分かるし、この運用をしてからバーンアウトは起きていないので、ある程度は効果あるのかな?
適応
■チームに自律性を与えるために、必要であればあなた自身の行動を変える。
自律的に振る舞うとは何かを勉強する、議論する、定着するという機会をまずは作らないとなーって思った。
まずは真面目にスクラムをやる、というところが自分には良いのかもしれない。
チームメンバーが頻繁に入れ替わる前提で仕事している所はあるな。。この節を読んで改めてふりかえると、この前提での行動がチームの自律性を損なわせている側面があるのかな、とは思った。
■表6-1、表6-2、表6-3で確認した内容に基づいて他の変更を行う。
"本物のチームになっていない"っていうのが禅問答なので厳しいが、なんかやりたいな。。。
チームを固定する、やりたいなあ。Product Wakeパタンの話を聴いて、なおさらチームが固定できていないことに問題意識を持つようになった。
■プロジェクトの終了時にチームがより健全化され、プロジェクトの開始時よりも能力が向上するような計画を立てる。サイクルごとに学習の時間を少し設けることをチームに伝える。
ここ1ヶ月くらい疎かになっているので、来月からは復活させようと改めて思った。今でも普通にはやっているんだけど、前まではアグレッシブにやっていたのでそれを取り戻したい。
チームで学習する時間を確保したりしていたのをまたやりたい。
一応継続的に学習の時間は取っているが、プロジェクトレベルで成長計画を立てるのはすごくいいと思った。是非やってみよう。
■開発者を顧客と直接交流させる計画を立てる。
今はたまたまコーチのプロジェクトが多いのでエンドユーザーと出会う機会が少ないが、ディスカバリー時にインタビューの話はよくしていて、してもらっているので、そこにお邪魔できるならしたいかもなー。確かに。
営業やカスタマーサクセスのオンボーディングに参加したいという気持ちはありつつもできていなかったので実行するぞい
これはやっている。(BPの人は特に)視点が大きく変わったと話していて、「ユーザが使ったらどう思うか?」「フィードバックをユーザからすぐにもらおう」「この機能ってこんなに長い時間かけてまで欲しいものですかね?」みたいな会話が頻繁に出るようになったので、効果は絶大だった。