働き方：アジャイルな働き方を定着させるには：アジャイルな働き方の具体例

このコラムは、ビジネスパーソンの方々を対象に書いています。

新型コロナウイルスが流行する以前からVUCA（ヴーカ）は言われていました。VUCAとは、Volatility、Uncertainty、Complexity、Ambiguityの頭文字です。不安定で、不確実で、複雑で、不明確といったところでしょうか。

コロナ禍になり、不安定性、不確実性、複雑性、不明確性は増していると感じます。

このような環境の下、アジャイルという言葉を最近良く見聞きするようになりました。
アジャイル、英語のagileで「機敏な」という意味の形容詞です。
アジャイルはソフトウェア開発で使われている開発方法の1つです。ソフトウェア開発で使われている方法が、ソフトウェア開発以外でも見聞きするようになっています。例えば、働き方、経営、組織文化。

私は今までにアジャイルな働き方に関して、下の2つのコラムを書いています。

このコラムでは、アジャイルな働き方を定着させるにはどうしたら良いのか、について考えます。

はじめに、今一度アジャイルな働き方の本質を説明します。
次に、アジャイルな働き方を定着するためのキーポイントである「振り返り」について説明します。
最後に、アジャイルな働き方の具体例について考えます。

私がアジャイルな働き方と出会ったのは2014年頃です。アジャイルな働き方が腑に落ちるまで時間がかかりました。試行錯誤しながら約4年間アジャイルな働き方を実践しました。コロナ禍でVUCAの今、アジャイルな働き方は1つの有力な選択肢ではないか、と私は思っています。自身の経験を踏まえて、このコラムを書きます。

このコラムは次の3つの章で構成します。10分程度で読める内容です。

1. アジャイルな働き方の本質

2. 振り返り

3. アジャイルな働き方の具体例

私は、ファシリテーションを核としたコンサルティング・サービスを営んでいる個人事業主です。屋号を BTFコンサルティングといいます。BTF は Business Transformation with Facilitation の頭文字をとりました。トランスフォーマーという映画をご存知の方がいらっしゃると思います。クルマがロボットに変身したり、ロボットがクルマに変身したりする映画です。トランスフォーメーション（transformation）とは変身させることです。ビジネス・トランスフォーメーションとはビジネスを変身させてしまうことです。ビジネス変革とも言われています。「ファシリテーションを活用してビジネス変革を実現して欲しい、そのために貢献したい」と考え、この屋号にしました。

ファシリテーション。Facilitationという名詞です。「人と人が議論し合意形成をする。この活動が容易にできるように支援し、うまく合意形成できるようにする。」これを実現するためにはどうしたら良いのかという課題を科学的に考え、試行錯誤を繰り返しながら作りあげられた手法、これがファシリテーションです。

ファシリテーションをする人をファシリテーター (facilitator) と言います。

1. アジャイルな働き方の本質

この章では、アジャイルな働き方の本質について、以前書いた私のコラムをまとめる形で、リマインドします。

新型コロナウイルスが流行する以前から、変革のスピードが速く、破壊的な変革が起こる時代になっていました。
そして新型コロナウイルス感染症の流行と、変異株の出現もあり先が見通しにくい状況が続いています。

いつ何が起こるかわからない。上の画像は悪路を自転車で走っている様子です。画像の出所は、Google画像（クリエイティブ・コモンズライセンス）です。

石を踏んでバランスを失い転んでしまうかもしれません。転んだら骨折してしまうかもしれません。鋭く尖ったものを踏んでパンクするかもしれません。危険が伴っています。それでも走っています。上の画像はレースをしている感じに見えますが、レースでなくても、少し危険でも風を切って走る爽快感は良いものです。そもそも100%の安全なんてあり得ませんし。

VUCAで先が見通しにくい時代にいる私たちは、上の画像のように、悪路を自転車で走っているような感じなのではないか、と私は考えています。

悪路を自転車で走る時には怪我をしないように注意をしながら走りますよね。何が起こるかわからないので。街中を走る時でも歩行者やクルマが飛び出してこないか注意して走っていると思います。

そうした事態をできるだけ避けるために、機敏に対応すると思います。例えば、「うまくいかなそう」という状況を機敏に察知し、機敏に打ち手を考えて行動し、機敏に振り返りを実施すると思います。例えば、「以前このくらいの大きさの石を踏んだ時バランスを失って転びそうになって危険だった」という体験をしていれば、とっさに「数秒後にうまくいかなそう」と判断できます。それで、石を踏まないようにバランスを失わないようにしながら石を避けます。うまく走れたら「よかった。また集中しながら走ろう。」と思うでしょう。

以前に危ない体験をした、失敗とまではいかなかったものの結構ヤバい体験をした、その体験を振り返って「あのくらいの大きさの石を踏むと危険だ」と学習する。次に走った時に、学習したことを活かしながら走る。そしてまた振り返る。「前回学習したことを活かせた。集中して走ることは大切だな。」と学習する。このサイクルを繰り返す。こんな感じです。

自転車を例に出して、機敏に自転車を走らせること、すなわちアジャイルに自転車を走らせることを説明しました。

この章では、アジャイルな働き方の本質をリマインドしました。
次章では、アジャイルな」働き方を定着するためのキーポイントである「振り返り」について考えます。

2. 振り返り

あなたのチームは振り返りの習慣がありますか？
あなたのチームには反省する習慣がありますか？

冒頭から質問した理由は、反省と振り返りには大きな違いがある、と私は感じているからです。

ウィキペディアによると、『反省（はんせい、英: self-reflection）は、単純には、何らかの有用な知見を期待して、自分がしてきた行動や発言に関して振り返ること。一般的には、振り返ったあとそれについて何らかの評価を下すこと、あるいは自分の行動や言動の良くなかった点を意識しそれを改めようと心がけること。あるいは自己の心理状態を振り返り意識されたものにすること。中心的な考えである自分の過ちを認めることと改善を誓約する意味、文化。』とあります。

自分の過ちを認め改善を誓約する文化。「悪いことをしました。すみません。次からは気をつけます。」と言えば良いのでしょうか。反省文というものもあります。「反省の色が見られない」「過ちを素直に反省する」など、私は反省という言葉にはネガティブな雰囲気を感じます。そもそも、仕事をしているときに悪意を持って過ちを犯す人は極々少数だろうと思います。
他方、振り返りはポジティブなものです。

この章では、振り返りについて説明します。

ソフトウェア開発でアジャイルを導入している方々には、リトロスペクティブ（retrospective）という言葉で表現した方が伝わりやすいでしょうね。「振り返り」って名詞でしょ、リトロスペクティブって形容詞じゃないの？と思った方。私もそう思います。名詞ならリトロスペクション（retrospection）の方がしっくりくるかもしれません。他方、よく使われている言葉はリトロスペクティブです。

このコラムでは、「振り返り」という日本語を使います。

皆さんの中には、何かしらのプロジェクトに参画したご経験をお持ちの方がいらっしゃると思います。
新製品・新商品・新サービスを世に出した直後の数週間は、何か予期せぬことが起こるものです。
これに対応するために、会議室を一定期間占有してウォールーム（war room）を開設したことがある方もいらっしゃると思います。戦時下のプロジェクト専用の部屋、という感じでしょうか。ウォールームをご存知ない方のために、具体的によくわかる情報を見つけました。『一つの空間でプロジェクト情報を可視化。企業のウォールーム利用事例』です。

何か問題が発生したときに、自分たちで自律的に問題を分析し、自律的に課題を洗い出し、そして自律的に解決するための部屋。ウォールームとはそんな感じの部屋です。

そもそも予期していない問題に対応するのですから大変です。チームで自律的に協働して解決しなくてはなりません。
冒頭で簡単に説明したとおり、ファシリテーションとは「人と人が議論し合意形成をする。この活動が容易にできるように支援し、うまく合意形成できるようにする。」ということを実現するための手法です。
チームで自律的に協働して解決するためには、メンバーから自由闊達に意見を引き出し、引き出された意見をかみ合わせ、解決するための打ち手を合意する必要があります。この活動が円滑に行われるよう支援する人、ファシリテーターが必要です。

さて、問題解決に向けた打ち手が合意されたとしましょう。仮に、月曜に打ち手が合意され、金曜までに解決することが目標になったとしましょう。金曜まで進捗を確認せずに、金曜になってから結果を確認するのは、アジャイルな働き方ではありません。火曜の朝から打ち手を実施し始めるのならば、火曜の13:00頃には1回目の振り返りをしたいですね。もし、合意された打ち手に修正が必要ならば、早めに手を打たなければならないからです。さらに同じ日の終業時頃にも2回目の振り返りをした方が良いと思います。そして、水曜の13:00頃に3回目の振り返りを実施し、水曜の終業時頃に4回目の振り返りを実施する。これを金曜まで実施する。金曜の終業時頃の振り返りでは、来週も同じ1日2回のサイクルでの振り返りを継続するのか、1日1回に減らすのかを決める必要があるでしょう。

具体的にはどうすれば良いのでしょうか。

私はKPTというフレームワークを活用すると良いと考えます。ケー・ピー・ティーと言う人もいますし、ケプトと言う人もいます。下図はKPTを説明したものです。私のフレームワークのセミナー資料から取りました。

KPTはKeep、Problem、Tryの頭文字を取ったものです。左上にKの領域を置きます。左下がP、そして右半分がTの領域です。

Kの領域には、今回うまくいったので今後も継続することを書きます。付箋に書いて貼っても良いでしょう。
Pの領域には、今回うまくいかなかったこと、改善の必要があることを書きます。
Tの領域には、次回の振り返りまでに挑戦することを書きます。

なぜこのようにKとPとTを配置するかというと、左側に書いたことと、右側に書いたことを線でつなぎやすいからです。

Pに書かれていることは要改善なのですから、Tに書かれていることと関係があるはずです。1対1の関係の場合もあるでしょうし、1対多の場合もあるでしょう。1つのPに対して複数のTが対応することもあるということです。Pに書かれているのに、どのTにもつながっていない場合は、Tが不足していることが一目瞭然となるわけです。
ところで、Kに書かれていることと、Tに書かれていることをつないでもOKです。これの意味は「今回うまくいった、さらにもっとよくするために次回の振り返りまでに◯◯をする」ということです。

ところで、振り返りを実施する最大の利点は何でしょう。振り返りを実施する目標は何でしょう。
学び続けるチームを作ることです。

1章で書いた「自律的に問題を分析し、自律的に課題を洗い出し、そして自律的に解決できるようになること。そしてこのサイクルを振り返り、何が良かったのか（うまくいった理由は何か）、何が良くなかったのか（うまくいかなかった理由は何か）、次はどうしたら良いのか（次チャレンジすること）を振り返りながら学習して、次のサイクルは今より良いものにすること。」これを実現するための仕組みとして振り返りを活用するのです。

この目標に到達するために大切なことは叱責しないことです。特に、KPTのPについて叱責することはよくありません。うまくいかなかったことは事実として受け止めた上で、うまくいかなかった理由は何か、どうすればより良くできるのか、冷静かつ論理的に考えることが大切です。うまくいかなかった理由をヒトに求めるのではなく、コトに求めるべきです。

◯◯さんのスキルレベルが低かったためうまくいかなかった。「○○さん、スキルレベルを上げてね。」と個人に丸投げするのではなく、チームとして何が出来るのかを考えるべきです。◯◯さんのスキルレベルが低く荷が重かったというのがファクトなのであれば、ファクトはファクトとして認め、さらに◯◯さんの育成という目標もキープし次にうまくいくようにするために、例えば「□□さんをアドバイザーとしてつける」がTに書くべき打ち手となります。

また、ついつい叱責してしまいがちな人は、ソフトスキルのエモーショナル・インテリジェンス（Emotional Intelligence）を研鑽する必要があるかもしれません。エモーショナル・インテリジェンスとは、チーム内のメンバーとの関係性の構築、難しい局面での対応、こういったことをうまくできる能力です。

例えば、プロジェクトマネージャーとメンバーA。
メンバーAはいつも期限内に進捗報告しない。今回も遅れた。プロジェクトマネージャーはイラつき怒りを覚え、メンバーAにキツい反応をして、対決モードになってしまった。対決モードや権力で従わせるモードにするのではなく、お互いが納得してプロジェクトが前に進むように持っていく能力がエモーショナル・インテリジェンスです。

私はグローバルプロジェクトに長年従事しました。もちろん、うまくいかないことも多々ありました。そんなとき、グローバル側のリーダーとの電話やオンラインでの1 on 1をやりました。叱責されることはありませんでした。一方、何故うまくいかなかったのか、阻害要因は何だったのか、うまくいくためには何が必要だったのか、誰かに支援を求めるとしたら誰に何を求めるのか、等々を訊かれました。彼はエモーショナル・インテリジェンスのある人でした。多分、後天的に自ら研鑽したのだろうと思います。

「何故うまくできなかったんだ。もっとしっかりしろ。」「すみません。がんばります。」という意味のわからないやりとりは許されません。ある意味、うまくいかなかった事実を分析し、説得力のある改善のための打ち手を提案することを求められるのですから、厳しいとも言えます。

振り返りを習慣化して、学び続けるチームを作ろうとするか否か。
数週間後には明確な差が出てくるはずです。

この章では、振り返りについて説明しました。
次章では、KPTも活用したアジャイルな働き方の具体例を考えます。

3. アジャイルな働き方の具体例

2章では、新製品・新商品・新サービスを世に出した直後数週間は、何か予期していなかったことが起こるものなので、ウォールームを開設して、発生した問題を解決するために振り返りを頻繁に繰り返すことを説明しました。振り返りのフレームワークとしてKPTを紹介しました。

振り返りを頻繁に回すだけではアジャイルな働き方を実践することはできません。

この章では、アジャイルな働き方の具体例を考えます。

KPTのTに書かれたことは、いわゆるTo Doです。カンバン管理することが必要です。ウォールームのホワイトボードやフリップチャートなどに、未着手、作業中、完了済の3つの状態を書き出し、各To Do項目を3つの状態のどこかに置きます。よくやるやり方は、1つのTo Do項目を1枚の付箋に書いて、最初は未着手のところに貼ります。担当者が作業を始めたら、付箋を作業中に移します。完了したら、付箋を完了済に移します。これがカンバン管理の基本的な考え方です。

カンバン管理にITツールを活用している方もいらっしゃるでしょう。
一例として、Trelloで説明します。
下図がTrelloでカンバン管理をしている様子です。下図の出所は Trelloの『カンバン管理（使い方）』です。
状態として、バックログ、着手待ち、進行中、完了、中断の5つがあります。私は、少なくとも最初はとてもシンプルに始めることをお勧めしているので、上の段落で書いた未着手、作業中、完了済の3つの状態で始めると良いと考えます。下図の一つひとつの四角が1枚の付箋に対応します。カンバン管理することで、未着手状態のものが何で、作業中のものが何で、期限切れや期限間近のものが何で、何が完了しているのかが一目瞭然になります。

紙の付箋の場合は、紙なので、そこに書かれている情報しかありません。ITツールの場合は、付箋に書かれている情報に加えて、より詳しい情報を付加することができます。しかもカンバン管理に使える最近のITツールはクラウドのツールなので、オフィスのパソコンからでも、自宅のパソコンからでも、タブレットでもスマホでも使うことができます。 Trelloの『カンバン管理（使い方）』のリンクを開いて、どれかの四角（付箋に相当するもの）をタップやクリックすると、詳細な情報をみることができます。

付加情報として何を記述するべきか。
私は誰が何の役割を持っていつまでに何をするのかを記述することをお勧めします。

下図はRACI（レイシーと読みます）というフレームワークを活用して、ある家庭の家事分担について誰が何の役割を持って何をするのかを表形式で見える化しています。下図の出所は『会社の会議：会議の変革：RACIを活用して実施可能なTo Doを合意しよう』です。

RACI は、役割と責任を見える化するものです。R、A、C、I 各々の役割と責任は下記です。

R：実行責任者（RはResponsibleの頭文字）：当該 To Do 項目を実行することに責任を持つ人（複数人可）
A：説明責任者（AはAccountableの頭文字）：当該 To Do 項目について内容や進捗・状況を組織内外に説明することに責任を持つ人（通常ひとり）
C：相談される人（CはConsultedの頭文字）：当該 To Do 項目が円滑に実行されるよう相談を受け助言する人（複数人可）
I：報告を受ける人（IはInformedの頭文字）：当該 To Do 項目の進捗・状況について報告を受ける人（複数人可）
R と A は誰かを必ず任命します。兼任可です。
C と I は誰も任命されなくてもOKです。この2つも兼任可です。

カンバン管理対象のTo DoとRACIについて。
ある人は能力があって、ひとりで問題なく完了できるかもしれません。
他方、ある人には信頼できる C の役割の人を付けることで円滑に完了まで持っていけるかもしれません。複数の C の人が必要かもしれません。I の役割の人も付けた方が良いかもしれませんね。
アジャイルに対応する必要があるのですから、確実に実施され完了できるような役割を割り振ることが大切なのです。

RACIをカンバン管理と組み合わせることで、良い効果があります。
未着手状態のTo Doに対してRACI表を作ります。
また、作業中状態のTo Doに対して、別のRACI表を作ります。
未着手状態と作業中状態のTo Doに対して、現状を反映したRACIを作るのです。最新の状況を反映したのもにするべきです。このRACIを見ることで、今今チームメンバー個々の負荷がどのくらいで、今後どのくらいの負荷がかかるのかが見えます。ウォールームのホワイトボードやフリップチャートにRACI表を書きます。

例えば、頼りになる人がいたとしましょう。その人には C の役割を持ってもらいたいとしましょう。多くのTo Do項目に対して、その頼りになる人に C の役割を振ってしまうと、その人がボトルネックになってしまい、全体の進捗に悪影響を出してしまう危険性があります。優先順位をつけて、全体を見ながら能力配分することが大切です。上の段落で書いた複数のRACI表を見える化することは、この能力配分するときの助けになります。

このコラムでは、ここまで下記の3つを説明してきました。

振り返りのフレームワーク（例：KPT）
カンバン管理（例：Trello）
個々のTo Do項目に役割を割り当てるフレームワーク（例：RACI）

コロナ禍になり、テレワークが要求されました。
チームメンバーの何人かはテレワーク、何人かはオフィス、という働き方をしている場合を念頭において、「KPT、Trello、RACIをどのように使えるのか」について具体例を考えます。

クラウド上にウォールームを開設する

ウォールームをクラウドに開設します。
具体的には、クラウド上のホワイトボードになります。ホワイトボードには、MURAL、miro、Lucidespark などがあります。私がセミナーなどでよく言っている表現は、クラウド上のホワイトボードは東京ドームのグラウンド一面に紙が敷き詰められているような感じの広大なホワイトボードです。紙とは異なり、ITツールなので、文字や付箋に加えて図形や画像やリンクを貼ることができます。

クラウド上で振り返りを実施しカンバン管理する

例えば、振り返りのフレームワークとしてKPTを用いたとします。そしてカンバン管理にはTrello、個々のTo Doに割り当てる役割はRACIを活用するとします。

クラウド上のホワイトボードにKPTを書きます。KPTのTがTo Do項目になると説明しました。KPTのTに書かれた項目には、TrelloのTo Doへのリンクを貼ります。

Trelloの各々のTo DoのタイトルはKPTのTの記述と同じものにします。そして、RACIを活用した「誰が何の役割を持っていつまでに当該To Doを実施するのか」を内容記述に書きます。加えて、To Doの進捗も内容記述に書きます。
例えば、進捗状況を色を使って表現することも良いと思います。信号のように緑、黄、赤の3色を使うとして、チームで各色の定義を決めて運用します。

クラウド上のホワイトボードには、未着手状態と作業中状態のTo Doに対して、最新状況を反映したRACIを書きます。

セキュリティ対応

これら、ホワイトボードとTrelloには、プロジェクトメンバーだけがアクセスできるようにします。
このように制御することで、プロジェクトの外に情報を漏らすことなく、しかし、プロジェクトメンバーは全員が最新の状況を把握することができるようになります。

このコラムでは、クラウド上のツールとして、ホワイトボードのMURALとmiroとLucidesparkを紹介しました。カンバン管理ツールのTrelloを紹介しました。また、資料や情報をファイルの形で保管するboxなどを活用している会社は多いと思います。

プロジェクトで無料のアカウントを使うべきではありません。
会社として管理者が行うセキュリティ設定と、各担当者が行うセキュリティ設定とをしっかり区別すべきなので、そういうことができるツールを使うべきです。例えば、会社のセキュリティ管理者は、間違ってもツールの情報をインターネットに晒すことができないように設定する。プロジェクト責任者はプロジェクトの情報にアクセスできるユーザーを追加することができる。プロジェクトメンバーはセキュリティ設定はできない。例えばこのように運用することが必要です。
会社にはセキュリティ・ルールが既に決まっていると思いますので、そのルールを遵守することが必須です。

終わりに

今回のコラムでは、アジャイルな働き方を定着させるために、頻繁に振り返りを実施することを提案しました。また、一例として、できるだけ具体的にどうするのかを説明しました。実は、アジャイルな働き方を成功させるためには、たくさんのコツやノウハウがあります。今回はコツやノウハウの一部を紹介させていただきました。

最後までお読みいただき、ありがとうございました。
　
　
　