投稿者: @Stephen_Li
元の英語での投稿はこちら: A diagnosis from the Asana Doctor 🩺
まずは例え話から
病気になったとき、薬局に行って片っ端から薬を買ったりはしません。医者に行って診断してもらい、治療のプランを立ててもらうはずです。変革の原動力となる「問題点についてよく考える」ことをせずに、新しいソフトウェアの導入などチェンジマネジメントに取り組むことは、すべての薬を 1 つのビンにまとめて、うまくいくように願うようなものです。理論的にはうまくいく可能性はとても低く、病院送りになる、つまり導入前よりプロセスが悪化する可能性の方がはるかに高いでしょう。
現実に置き換えてみます
少し極端な例でしたが、これを Asana の導入や最適化を検討しているチームに当てはめてみるとどうでしょうか？チェンジマネジメントを効果的に行うには、今の状況と、その状況を変えたい理由を体系的に評価するところから始める必要があります。これを怠るとその後のステップが難しくなり、効果も低くなります。今の課題点を明確に把握していないのに、よりよいものができるでしょうか。明確な動機なくして、「働き方を変えよう」とチームのやる気を引き出すことができるでしょうか？
「なぜ」と「どうやって」を明確にする
この定義づけの手段はさまざまで、例として以下のようなアプローチが挙げられます。
- Asana フォームなどを使って、組織全体でアンケートを実施する: 何がうまくいっているか、どんな作業の時間を減らしたいか、「ここが変われば業務が大きく改善する」という点はあるか、メンバーに聞きましょう。
- 各チームから代表者を選んで、アイデアサミットに参加してもらう: 各代表者に一連の同じ質問を行い、回答を比較して、一致していない点や潜在的な改善点を見つけましょう。
- 外部コンサルタントを雇う: 時間がなくても資金はあるという場合 (または単純に先入観のない公平な視点を求めている場合)、コンサルタントは現状を文書化する上で貴重なリソースとなるでしょう。コンサルタントは日々の業務に影響を与えることなくチームメンバーの動きを観察し、社内のメンバーであれば越えられないようなヒエラルキーの壁を越え、内部関係者であれば入手しにくいような広範な情報源からデータを出すことができます。
この作業の成果物は、「私たちは {根本的な問題点を改善} するために、{変化を起こす}」という形式の、理想的には 1～2 文の簡潔なミッションステートメントです。たとえば、「私たちの組織はプロセスを簡素化し、コミュニケーションを一元化し、仕事の重複を排除するために、Excel スプレッドシートとメールを Asana へ移行する」のようになります。
このステートメントは、何をどのように構築し、それをどのようにチームに浸透させるのかなど、その後のプロセスにおけるすべての意思決定に影響を与えるものになります。具体的には、以下のような意思決定が行われます。
- ローンチ時は、複雑でオートメーションを多用したプロジェクトテンプレートではなく、シンプルで繰り返し使えるものを優先させる (簡素化)
- タスクへのコメント、プロジェクトのメッセージ、外部の連絡手段の使い分けを定義し、ベストプラクティスを定着させる (一元化)
- 理想のテックスタックを特定し、それらを統合するための戦略を立てる (排除)
アイデアを実践する
ミッションステートメントと、その材料となった情報が揃えば、さまざまな方法で理論的なものを実現できます。さらに Asana を使うことで、計画と目標の対称性を確保し、個々の導入の進捗状況を把握し、チームメンバーとのオープンなコミュニケーションを継続できます。具体的には、以下のようなことを実践できます。
- これから行われる変革について意欲的であることを表明した人、または影響力の大きい人 (理想的には、その両方を兼ね備えている人) で構成された、ステークホルダーの小さな集まりを作る。これを導入を担当するコアチームとし、導入先チームを盛り上げ、継続的な使用を奨励してもらいます。
- すべての非効率な点を、それを報告したチーム、優先度、軽減にかかる工数で分類するプロジェクトを作成する。このプロジェクトのフォームを配布し、ソフトウェアのバグ報告のように、他の非効率な点も追加で報告できるようにして、将来的にトリアージできるようにする。
- 工数の多い、または優先度の高い「タスク」を優先したロードマップを作成し、チームメンバー全員に公開する。プロジェクトのメッセージ機能を使って、全員に定期的に最新情報を伝え、オープンなフォーラムでフィードバックを集めましょう。これにより、当事者意識やインクルージョンを促進し、変化へ向けて人々のやる気を大きく高められます。
- プロジェクトを使ってテックスタックとその依存関係を視覚化し、効果的なリソースの投入方法と投入先を理解する。これにより、「Asana の自動割り当てルールを作成する前に、Asana と Google ドライブの連携から行う」など、一部のチームの希望には沿わないニュースを伝えることになるかもしれません。しかし、それには「Google ドライブとの連携を今すぐ必要としている人が多い」など、必ずデータに基づいた理由も伴います。
- プロジェクト関係者に送っている週次の進捗報告メールなど、多くのチームメンバーが行っている、手作業の多いプロセスを特定し、それをシステム化する方法を特定する (Asana の新しい AI スマートサマリー機能を使うなど)。
つまり、何がどういった理由で変化し、日々の仕事にどのような影響を与えるのか全員が理解できれば、その変化に対する人々のやる気も高まり、長続きするようになるのです。アプローチの方法は無数にあり、今回ご紹介したのはほんの一例です。よく検討し、継続的なフィードバックを奨励していれば、成功する可能性は十分にあるでしょう。
あなたはチームに Asana を導入する際、最初にどんなアプローチを取りましたか？「あなたならこうする」というアイデアがあれば教えてください。