「世界で一番やさしい会議の教科書」榊巻亮 著


ここ数年で「~の教科書」というタイトルの書籍が増えてきた気がします。「教科書」という響きからは学校の授業で使う教材をイメージしてしまうので、個人的には入門書の意味合いで教科書と命名するのはいかがなものかと思っております。なぜなら、教科書は浅いけれども必要なことは万遍無く盛り込まれていますが、「教科書」というタイトルが付けられた書籍には必ずしもそうではないものもあるからです。とはいえ、本書は社会人になりたての方々に会議の心得を身に着けさせるための適切なガイドブックと言えるでしょう。

皆さんは会議は好きでしょうか。おそらく出席して良かったと思える会議とそうではない会議があることでしょう。無駄だなぁと思う会議はいろいろありますが、「報告事項を報告者が口頭で発表し、参加者一人一人が手帳にメモする」というのがその最たるものかもしれません。そんなものは資料化して配布すれば済みます。また、「議事録を次回の冒頭で読み上げる」というのもあります。これは開催頻度にも依りますが、例えば1か月前の議事録を次の会議で確認するというのではさすがにスピード感がありませんし、思い出すのも疲れます。議事録は開催直後に配布して認識を合わせておくべきだと思います。

私はどれだけの会議に出席したかは把握していませんが、社会人1年目の時に出席した会議が原体験となっているような気がします。当時はPCが一人一台という状況では(少なくともその職場では)なかったですし、会議もPC+プロジェクタではなくホワイトボード(感熱紙にプリントはできる)を使っていました。会議の「いろは」も分かっていませんでしたが、誰が進行するかによって会議の質も異なっているということは分からないなりにも感じていました。会議の進行については師匠から種々の心得を叩き込まれまして、いつの間にか難なく会議をこなせるようになってきました。進行だけでなく、本書の前半に書かれているような立場で会議の成果を何とか見える形にしようとしてきました。

そんなこともあり、上で述べたような経験を通して私の会議術というのは磨きをかけて行ったものですが、一方では私が身に着けたことをどのように若い人たちに伝えたらよいかという課題があります。本書はその観点でも参考になる部分が多くありました。というのも本書では、「確認するファシリテーション」⇒「書くファシリテーション」⇒「隠れないファシリテーション」⇒「準備するファシリテーション」という風に徐々にステップアップできるように組み立てられているからです。この順序に従うことで、読者ひとりひとりがご自身の成熟度に合わせて取組むことができると思います。

ファシリテーションというといわゆるフレームワークやファシリテーショングラフィックのようなものを連想される方も多いと思いますが、そのような高度なものではありません。会議に参加する心構えを変えるだけなのですが、すぐに効果が出ることが期待できる内容だと感じました。会議を効率化したい、効果が出るようにしたいと思われている、あるいは、そのようなテーマで人に教えたいと思われている方には是非読んでいただきたいです。


 書名:世界で一番やさしい会議の教科書
 著者:榊巻亮
 発行:日経BP社/2015年12月15日
 ISBN:978-4-8222-7178-7

限られたリソースで最大の効果をもたらすトリアージ


もう随分前になりますが、このブログの中で「デスマーチ」そして「パーフェクトソフトウェア」という2つの著作をご紹介したことがあります。両者に共通するポイントはリソースは有限であるため全てのバグを取り除くことができないという点と、その有限のリソースの中でバグをどのように分類し優先順位を付けて対応するかという点であろうと思います。いずれもソフトウェア開発に関する著作ですので「バグ」が対象にはなっているのですが、もっと広くプロジェクトマネジメントという観点に引き上げてみると、バグだけではなくバグ対応を含めたToDoの捌き方のアドバイスということになります。

前者の「デスマーチ」ではトリアージという戦争時における負傷者救護の優先順位づけのアイデア(これは今の災害時の救急医療現場でも活用されているようです!)を紹介していますが、後者の「パーフェクトソフトウェア」ではトリアージを実践するための具体的なバグの分類方法を提案しています。当時のブログ記事の中でも私なりにアレンジした分類方法をご紹介しましたが、今回はより進んだ分類方法をご紹介します。

システム開発では、開発中のシステムに対する仕様の変更や追加の要求が出されることが良くあります。要求を出す方としては当然のことながらすべてに対応してもらいたいと思うものですが、要求を受ける方としても当然のことながらプロジェクトとして実施している場合は納期も予算もありますので(これがリソースが有限であるということの意味ですが)出された要求の全てに応えることができないという状況に陥ることがあります。

そんな時、要求を一覧化して対応するかしないかを選別しても良いのですが、もっと明確な基準があると判断にも迷わないですし、なされた判断も客観的で納得感が出てくると思いませんか。例えば、次のような分類を考えてみましょう。

レベル0:そもそも技術的に不可能であり、対応できない要求
レベル1:対応できなければリリース延期またはプロジェクトを中止する要求
レベル2:リリース時に無くても良いが、対応しないと業務に支障のある要求
レベル3:可能なら対応したいが、対応しなくても止むを得ない要求

これらの分類をするだけでも客観的な評価となり得ますが、次のような設問フローを作るとより客観的で論理的な判断を下すことが可能になり説得力が増します。

トリアージの判定フロー

(1) 要求が技術的に不可能であるか。
[Yes⇒レベル0/No⇒(2)へ]
(2) 対応されなければリリース延期するか。
[Yes⇒レベル1/No⇒(3)へ]
(3) 対応されなければ業務に支障があるか。
[Yes⇒レベル2/No⇒レベル3]

判断をするときには設問に答えていくだけで客観的な優先付けを行うことができ、レベル0は除外して優先度の高いものから残されたリソースの範囲で対応できるものを決定していくことになります。これも救急医療現場で使われるABCDEアプローチのようなもので、判断を急ぐときにはシンプルで強力なツールとなります。分類の数が多くなっても設問を増やすだけで良く、状況に応じてアレンジもしやすいです。


東京都福祉保健局によるトリアージの説明

タスクかんばん(タスクボード)のレーン設計


以前、タスクかんばんを導入する肝はレーンの設計にあるということを述べたのですが、では具体的にどのようにレーンを設計すべきかというテーマについて考えてみたいと思います。

レーンとレイヤーのイメージ

レーンとレイヤーのイメージ

その前に、レーンをさらに横のレイヤーに区切って使うかどうか迷うと思いますが、個人で導入する場合はともかく、チームで導入する場合にはレイヤーに区切った方が良いです。また、区切るとしてもメンバー毎のレイヤーとするか案件毎のレイヤーとするか迷うのですが、案件毎にした場合、時間の経過による案件の増減に合わせてレイヤーを増減させなければならず、それはそれで運用に手間がかかります。メンバー毎のレイヤーにしておけば案件の増減に比べればメンバーの増減は少ないと思いますので、比較的手間はかかりません。それとメンバー毎としておけば、メンバーの生産性と抱えている作業量についてもある程度可視化できるので、チーム運営はしやすくなります。

そうはいってもメンバー毎のレイヤーにすると、案件ごとの状況が見えなくなってくることがあります。(だから案件毎のレイヤーにしたいという衝動に駆られるのですが。)私はタスクかんばんは目の前の仕事を片付けるためにチーム運営を円滑化するツールだと理解しているので、案件毎の進捗管理などはWBS(ガントチャート)のような全体を俯瞰できるツールを使って補う方が良いと考えています。

オーソドックスなレーン設計はToDo、Doing、Doneです。ToDoはやるべきことで未着手のタスク、Doingは現在仕掛中のタスク、Doneは仕上がったタスクです。タスクを付箋に書き出し、ステータスが変化するごとに貼るレーンを変えていきます。あるいはチーム内で完結する現場であればこれだけで事足りてしまうかもしれません。週次でマイルストーンを決めてToDoに落とし込み、週末にToDoが全て捌けてDoneに移動していればよいのです。週末(または週の頭)にはチームでミーティングを行い、翌週(または今週)やるべきタスクを棚卸してToDoに貼り付けていきます。

しかし、業種業態や活動の目的によってチーム外の関係者の多少が違うので一括りには出来ません。チーム内だけで完結しない場合、先ほどの3つのレーンだけでは管理できない局面があります。それは、チーム外の関係先に依頼するような場合、こちらの都合ですぐに返事があるわけではありません。つまり相手のタスクが終わるのを待っている状態、自分ではなく相手がボールを持っているということを表現する必要があります。そのタスクを例えばWaitingのように表します。

また、逆にチーム外の関係者から依頼を受けるパターンや、自分が完遂した作業を確認してもらったり承認してもらったりするパターンがあると思います。既に自分の手を離れていて、最後の確認や承認を待っているという状態です。そのタスクを例えばFinishingのように表します。ここまではメンバー毎のタスクです。


タスクかんばん(タスクボード)導入の肝


タスク管理の手法というのはいくつかあると思うのですが、その中の一つに「タスクかんばん」(あるいはタスクボードとも言うらしいですが)という見える化によるタスク管理手法があります。基本はアナログですが、タスクかんばんを実現するアプリも存在するようです。

タスクかんばんの原理は簡単で、チームが持っているタスクを全て付箋に書き出してホワイトボードに貼り付けるのですが、ステータスによって貼り付ける位置を変えていくというものです。でも、これを本格的に取り組もうと思っても教科書的なものが見当たらない。ネットで調べると多少それらしきものは見つかるのですが、いざ取り組んでみようと思うとなかなか難しいのではないかと思います。

やってみると分かるのですが、実はタスクかんばんを使いこなす肝はレーン(ステータス)の設計ではないかと思うのです。レーンというのはボードを縦に区切った言わば列のことで、通常はステータスを割り当てています。(但し、必ずしも列という形にこだわる必要はなく、自由にレイアウトを決めて良いと思います。)Redmineなどのタスク管理ツールでタスクを管理する時もステータスの設計が使い勝手に影響してきますよね。

例えば参考になるのが以下のサイト。
Web開発チームをタスクボードだけで見える化する 5つのコツ
http://engineer.blog.lancers.jp/2012/07/task_board_tips/

文献を見る限り一番オーソドックスなレイアウトはToDo、Doing、Doneという3つのレーンで区切る方法。ですが、杓子定規にこれを運用する必要はなく、現場の判断で変えて良いと思いますし、変えていくべきです。タスクのステータス設計にはどんな業務を対象とするかによっていくつものバリエーションがあり得ます。例えば開発現場でも設計工程と開発・テスト工程とでは管理すべきタスクが異なりますよね。

まずは導入しようと思う時に、この現場ではどのようにステータスを管理・運用しているかということを分析することになります。業務によっては併せてワークフローの設計もした方が良いケースもあります。具体的なステータス設計の例は追々ご紹介できたらと思います。