アジャイル、ナレッジ、個人の成長
はじめに
この記事はDevLOVE Advent Calendar 2020 19日目のために書いた記事です。
今回は、アジャイルに開発するチームにおいて、ナレッジマネジメントと個人の成長をどのように進めてゆくのがよいか、という問いかけを行う記事になっています。
個人の成長
組織行動学者のデヴィッド・コルブにより理論化された「経験学習モデル」。おおまかに説明すると、起きた事象に対し反射的に行動するのではなく、省察と概念化によって学習を深め、実践からまた新たな経験ループに入っていくというものです。
ここで提示されている経験学習サイクルがひとまわりするのにかかる時間、作業量は一定ではなく、個々人の経験や学習対象への習熟度によって異なる、というのが私の考えです。
みなさんは「学習曲線」という言葉を聞いたことがあるでしょうか。下記のリンクでわかりやすく解説されているので、ご存知ないという方はぜひご一読ください。
上記リンクでも紹介されているピロリとアンダーソンの式によると、 "学習量が2倍になると反応時間が84.7％になる"、つまり"学習量の累積が増えるほど、反応時間が短くなる"。さきほどのコルブの経験学習モデルに当てはめると、習熟度が上がるほど学習サイクルの回転が速くなっていくことになります。
チームの成長
ナレッジマネジメントの分野で有名なフレームワークとして「SECIモデル」があります。一橋大学の野中郁次郎氏と竹内弘高氏らが提示したフレームワークで、個ではなく組織としてナレッジを蓄積し進化させていくプロセスがわかりやすく整理されています。
アジャイル開発とナレッジマネジメント
拙著「いちばんやさしいアジャイル開発の教本」からの引用になりますが、Chapter4においてアジャイル開発の中核にあるコンセプトを「チーム」「インクリメンタル」「イテレーティブ」と定義しています。
前提としてチームが成長していくことが織り込まれており、その成長戦略を立てる際にはSECIモデルが有効な参照元となります。
また、アジャイル開発は経験主義に基づいたものでもあります。よってコルブの経験学習モデルとも相性がよいと私は考えています。
しかし、アジャイルが「インクリメンタル」で「イテレーティブ」であるがゆえに、個人の成長と衝突してしまうことがあると感じています。
経験学習サイクルと開発サイクル
アジャイル開発では、1~4週間程度の開発サイクルでイテレーティブに開発を進めていきます。また、このサイクルの最後には必ず成果が伴います（インクリメンタル）。つまり、チームとしては「必ずサイクルの終端で何かしらのインクリメンタルがあること」が求められます。
未知の事象が壁となり立ちふさがったときに、人は省察し、行動していきます。そこで経験学習が発生するわけです。チームとして習熟度が高い状態であれば、そういった個人の経験は「チームの成長」へとつなげるために共同化・表出化されるプロセスが整っていると想定されます。(朝会での共有、ナレッジ共有ツールへの登録など）表出化されていれば、チームとしては連結化へもつながりやすい状況でしょう。
しかし、内面化はどうでしょうか。ここはそれぞれがナレッジを咀嚼し、自分なりに理解していくことが必要でしょう。ここで学習曲線の話を思い出すと、学習速度というものは個人によってばらつきがあるものです。
チームの開発スピードが上がるということは、開発サイクル内での学習の機会が増加するということです。すると、習熟度が高くないメンバーにとっては「経験学習サイクルのスピード＜開発サイクルのスピード」となってしまいます。
チームとして開発サイクルの終端でインクリメンタルを届けられている状態。チームとしてはそのケイパビリティがある、というのは間違いないでしょう。しかし、個々人のケイパビリティまで解像度を上げると、実はばらつきが出ているということが起こりえます。
もう一度学習曲線について思い出してみると、「学習すればするほど学習サイクルのスピードが上がる」わけです。これは開発サイクル内で経験学習サイクルを回すことに成功したメンバーはどんどん成長していき、そうでないメンバーは足踏み感を感じてしまう、差が開いていってしまうということにもつながります。
いかに学習を設計するか
メンバー間のナレッジ、そしてスキルに大きな差異が出てしまうと、そこには依存性だったり属人化だったりといった課題が入り込む余地になってしまいます。では、我々はいかに、チームでの学習を設計していくべきなのか。
例えば、私のチームでは以下のような試みを行っています。
ラーニングセッションの導入
こちらの記事で紹介されているほどガッツリは取り組めていませんが、メンバーたちが自分たちに不足している、と感じているスキルだったり、単純に興味があったりする内容を業務時間内に学ぶ時間を設けています。少し前だと「チーム・ジャーニー」の読書会、今はDockerの使い方についての勉強会を実施しています。（昨年は有志でCode Kataを解く会もやってました）
アサインメントの工夫
これはマネジメント寄りのアクションになりますが、あるナレッジやスキルを習得してほしいメンバにその期待値を添えて「やってみない？」と促すことをやっています。
基本的にはサインアップ形式でやっていきたい気持ちはあるのですが、そうすると得意なことや好きなことに偏ってしまったり、興味はあるけど自信がないものに手をあげられなかったりするため、こういった背中を押す意味でのアサインメントを実施することがあります。
1on1
これもマネジメント視点の話になりますが、メンバーとの1on1で期待値を伝える、学習を深めるための動き方のアドバイスなどを行っています。ここで個人の興味や意欲、心配事をキャッチし、上記アサインメントにつなげていくことが少なからずあります。
モヤモヤの共有
そして、やはり有効なのが「ふりかえり」の場の活用です。
経験学習サイクルが回せていない、と感じているメンバーは「成長している実感がない」というモヤモヤがありますし、経験学習サイクルが回り加速度的に成長しているメンバーはメンバーで負担の高まりを感じていたりします（タスク的な意味でも、心理的な意味でも）。
こういったモヤモヤをふりかえりで共有するのも有効です。
ただ、こういった心理的なモヤモヤについてはなかなか切り出しにくいものです。明確に「今回は心理的側面について話しましょう」とテーマ設定をするのがよいでしょう。
余談ですが、私のチームでも最近こういった心理的側面にフォーカスしたふりかえりを実施しました。「メンタルどうですか？」というストレートなテーマ設定にちょっと笑ってしまいましたが、それぞれがモヤモヤを共有し、どう解消していくかを話しあう有意義な時間になりました。
みなさんどうしてますか?
チーム全体の習熟度と成果、個人の成長のバランスについて感じている葛藤と、そこに対して現在行っているアクションを紹介させていただきました。
アクションについてはそれなりに有効だという実感があり、同じような悩みを抱えている方の参考になるようであれば幸いです。
そして、このテーマについてはまだまだ悩んでいる、というのが正直なところです。みなさんが現場でどう取り組んでいるか、そもそもこのテーマに対してどう捉えているか、など、DevLOVEのDiscordでお話できれば幸いです。ジョインお待ちしています。
この記事が気に入ったらサポートをしてみませんか？