Close
Enter your
text here

プロジェクトマネージメント

仕事の進め方は段取り8割！スケジュール/タスク/ToDoの立て方コツ
 仕事の進め方は段取り8割！スケジュール/タスク/ToDoの立て方コツ 1024 768 Biz Tips Collection

「段取り」＝「作業の設計」
特定の業界や職種ではよく聞く言葉ではあるが、馴染みのない人にとっては違和感のある言葉かもしれない。

ここでは、”目的達成に向けて、自身が行う業務を明らかにし、To-Doやタスクを検討してスケジューリングする、一連の行為”と定義しよう。実はこの作業設計こそが全ての仕事の基本と言っても過言ではない。作業設計の出来不出来が最終アウトプットに大きく影響を与えるのだ。

本稿は主に新人ビジネスマンを想定したものではあるが、ぜひ、中堅以上の皆様も一度目を通してみて、正しい作業設計が日々出来ているか確認してもらいたい。上司と仕事のソリが合わない、仕事が遅いと指摘されているといった方がこれを知って劇的に改善した例がある。

理解を深めるために以下のような状況に置かれたと想定して欲しい。

日々業務に頑張るあなたは上司から次のような言葉を掛けられた。

「翌月曜日朝一の定例会議の場で君に調べてもらっている範囲の検討状況をプレゼンすることとなった。君の最近の頑張りを見ていて、資料にどう落とし込むかも含めプレゼンを一度任せてみたい。もちろん、事前に私の確認を通してね。あ、それと、検討状況の1つの◯◯に関しては他部署の石井さんも別の切り口から進めているから、彼の検討状況もプレゼン内容に含めておいてね。」

初めてのお客様へのプレゼンのチャンス。ここで頑張りと能力を伝えてこの先につなげたいと意気込むあなた。さあ、どうやって進めていこうか。順を追って解説していきたい。

ゴールまでの道筋を描こう

① 関係者（ステークホルダー）を把握する

業務に関わる関係者（または社）を洗い出そう。

一概に正解と言える指標はないが、初期の段階（全体像を把握する段階）ではあまりに細かすぎる粒度は避けたほうがよい。意思決定または作業の代表者程度にとどめておくのが望ましいだろう。
本件の場合だと上司、石井さん、自分となるだろうか。

②ゴールの確認とマイルストーン(中間地点)の設定

簡単に言えば、「いつまでに何をしなければいけないかを把握して、ゴールから逆算してやらなければならないことを洗い出していく」作業だ。
小学生でもできると思っただろうか。もちろんだ。難しいことはやっていない。
本件の状況において、自分ならどうするだろうか、少し読み進むのを止めて考えていただきたい。
ただし、1つだけ留意してもらいたいポイントがある。それは、可能な限り具体的に日時を検討することだ。誤っていても構わない。「所与の条件を考えればそれくらいはいるよね」を繰り返して、お尻から頭までのスケジュールをひいていってもらいたい。

改めて本件について、ゴールを確認した上で逆算していくと、、

ゴール-1：上司への説明
⇒ダメ出しを受けて修正を行う可能性がある。上司は木曜の朝一と金曜の午後しか空いていない、、、となると、遅くとも木曜日の朝9時には説明に行かなければいけない

ゴール-2：資料完成
⇒上記に則り、水曜日中には資料を作っておかなければ。

ゴール-3：資料素材収集
⇒資料を作るために必要な素材はどうなっているんだっけ。石井さん以外のパートは私の方で集まりそうだ。となると、石井さんから水曜日中にはヒアリングする必要があるぞ。石井さんの予定は、、火曜日の午前しか空いていない！もう月曜日の夕方だ！今すぐに石井さんに明日の打合せの依頼をしなければ！

いかがだっただろうか。

まずはじめに、初めてのチャンスに意気揚々として、資料の構成をどうするか、見せ方をどうするか考えた人も少なくないのではないだろうか。
そう、少なくとも本件の場合においては、調査内容の検討や資料構成の検討などより、まず第一に石井さんにアポを取らなければ上司がオーダーした内容を満たすことすらできない可能性が高かったわけだ。

③成果物と主要な検討項目の洗い出し

石井さんにアポを取ったら次は、それぞれのマイルストーン間での成果物を洗い出す。
ここまでくれば全体像の把握まで後一歩だ。マイルストーンを実現するためには、何が必要なのか（何ができている必要があるのか）を洗い出そう。併せて、成果物作成にあたって主要な検討項目も洗い出そう。
ここまでの一連の取り組みにプレゼン当日までの流れも含めて図示してみると以下のようになる。
もちろん、こんなに大仰なものを毎回毎回作る必要はないが、作業にのめりこみ全体像を忘れないためにも頭の中に絵を描いておくか、ノートに記しておくと便利だ。
さあ、これでゴールまでの道筋が明確になった！あとは一直線に走るだけ！
※別稿で触れるが、プロジェクトマネージメントの基本も上記の通りだ。より複数のステークホルダーが存在し、複雑化したプロジェクトであればあるほど、全体像を一枚でまとめた図は非常に重要になる。図を基にWBSを作成する、プロジェクト全員の合意をとる、運用する、などなどは別の機会でお話したい。

作業設計は百利あって一害なし！絶対やろう

作業を設計することで、重要なポイントを逃さずに余裕をもって業務を進められることをおわかりいただけただろうか。
それだけではなく、進捗状況を上司や周囲へ正しくわかりやすく伝えることも容易になるし、結果、信頼を獲得することもできる。
最初のうちは一々面倒くさいと思うかもしれないが、結果、最も効率的かつ効果的に業務を進めて評価を獲得することができるのだ。
ここまでお付き合いいただいたが、いかがだったろうか？
何も特別なことはなく、何なら我々が日常でやっているプロセスを明確化して肉付けしただけに過ぎない。
にもかかわらず、ことビジネスの現場になると、これが途端にできなくなるケースが散見される。自分が興味のある分野から取り掛かったり、簡単そうな箇所から取り掛かったり。
あなたが得意かどうか、好きかどうか、これらは二の次なのだ。あくまでも、やらなければならないことをやらなければならない期日までにやることこそが求められていることなのだ。
こう書くと冷たい言い方に聞こえるが、一方で気が楽にならないだろうか。人間性や趣味嗜好は関係ない、ある種のゲームのようなものだと思ってもらうといいかもしれない。ビジネスというゲームにおいて、本サイトで有利になる攻略法を身に着けながら、ぜひとも大海へと漕ぎ出して行って欲しい。進めば進むほど、ゲームは面白くなる。
健闘を祈る。
組織の知識創造プロセスSECIモデルとは？| ナレッジマネジメントのフレームワーク
 組織の知識創造プロセスSECIモデルとは？| ナレッジマネジメントのフレームワーク 1024 683 Biz Tips Collection

SECI（セキ）モデルとは、組織内の知識創造プロセスについてのモデルだ。いかに組織の知識・知見を高めていくか考える際に役立つ。現代は知識社会と呼ばれ、過去のように巨大な資本と労働力がモノをいう社会から、知的労働や組織に蓄積された独自の知見の役割が高まっている。そんな中、組織としての集合知を能動的に管理していこうということで、ナレッジマネジメントという言葉が生まれた。SECIモデルは、ナレッジマネジメントの基礎理論として知られる。

SECIモデルは、暗黙知と形式知の相互転換のプロセス

SECIモデルでは、知識を暗黙知と形式知の２つに分け、これらの相互転換により知識が創造されるとしている。
暗黙知とは、言語化されていない知識のことだ。個人の経験によるテクニックやくせとしてしみついている技などかもしれない。
形式知とは、言語化された知識だ。例えば熟練の営業マンの会話テクニックを文章化してマニュアルにすれば、それは暗黙知から形式知に転換したと言える。

共同化、表出化、結合化、内面化の4段階のプロセスで知識創造

SECIモデルは、組織内の知識創造プロセスを、以下の4段階のプロセスで表現する。また、これらの4つのプロセスは、一方方向ではなく、ぐるぐる回るサイクルになる。

Socialization（共同化）
↓
Externalization（表出化）
↓
Combination（結合化）
↓
Internalization（内面化）
↓
(共同化に戻る）

１つずつ見ていこう。

共同化（暗黙知→暗黙知）

共同化は、個々人の体験による暗黙知が、暗黙知のまま少ないメンバーで共有されていくことだ。例えば、OJTであったり、先輩に付きっきりの後輩が、先輩の技を覚えていくような場合だ。ここでは暗黙知の共有が行われているが、まだ言語化されていないので形式知ではない。また、言語化されていないので限られたメンバーにしか共有できない。
メンターやチーム制度、もしくはただ雑談する場を作るなどで促進することができるだろう。

表出化（暗黙知→形式知）

個人や一部の人たちの中に蓄積された暗黙知を、文章などで形式知化するのが、この表出化のプロセスだ。これで初めて、組織全体に共有することが可能となる。なんとなくの経験や勘といったものから、マニュアル化、ルール化、図や表でもよいので、概念として見える形にするのがこのプロセスだ。できる個人へのインタビューや、悩みや体験をチームでシェアするミーティングの結果を文章化するのも１つの手かもしれない。

結合化（形式知→形式知）

表出化で集まった形式知を、整理、統合、体系化などして、そこから新たな知を生み出すのが結合化だ。言語化された知見はより広く共有可能のため、別の人や部署から出てきた知見が組み合わさって新たな知見となるかもしれない。また、言語化された知見を体系化して整理することで、新たな視点が生まれるかもしれない。ポイントは、表出化で言語化された知識は、様々な人の視点を取り入れることが可能になるということだ。

内面化（形式知→暗黙知）

わかるとできるは別だ。新たに創造された形式知を、実際に実行するして、本人の暗黙知となるのがこのフェーズだ。そして形式知を実行していく中で、本人の中に新たな暗黙知が生み出される。この新たな暗黙知がまた、始めの共同化のフェーズに戻り、SECIのサイクルが回っていく。

このように、この4つのフェーズを通りながら、個人の暗黙知が組織の形式知となり、これがまた個人の暗黙知となり、と繰り返しながら知識が創造されていくのが、SECIモデルだ。
ナレッジマネジメントの観点からは、各フェーズがしっかり促進されているかチェックしたり、促進されるような仕組みを導入するような使い方になるだろう。表出化や結合化を促進するため、知識を共有するシステムを入れる例もある。

SECIは一回で終わるプロセスではなく、常に回していくサイクル

今回ナレッジマネジメントの基礎理論の１つとして知られるSECIモデルを紹介した。ここで忘れていけないのは、この一連のプロセスは、サイクルになっているということだ。例えば、表出化しなきゃとマニュアルばかり作っても、それがしっかり社内共有され個々人に実践されなければ、サイクルは止まってしまうのだ。
まとめると、以下のサイクルとなる。
Socialization（共同化）：暗黙知→暗黙知
↓
Externalization（表出化）：暗黙知→形式知
↓
Combination（結合化）：形式知→形式知
↓
Internalization（内面化）：形式知→暗黙知
↓
(共同化に戻る）

問題解決の幅が広がる！RACIの4つだけでないRACI図の発展版
 問題解決の幅が広がる！RACIの4つだけでないRACI図の発展版 1024 646 Biz Tips Collection

プロジェクトの責任分担管理表であるRACI。Responsible、Accountable、Consulted、Informedの4つの役割が基本だが、実はこれに役割を追加した発展版もいくつかある。必ず必要な役割ではないだろうが、発展版も把握しておくことで、プロジェクトの状況に応じて提示できる解決策の幅が広がるだろう。まだ、RACIの基本を学習していない方はこちらを先に参照してほしい。（→RACIチャートの意味とは？プロジェクトの責任分担を見える化する！）

Responsibleを分解したRASCI

通常のRACI図では、実行責任者であるResponsibleは複数人いても問題ない。しかし、あまりに多いと、タスクの実行・完了の最終責任が誰にあるのか不明確になるという弊害もある。そんな時に、あくまで実行責任者を一人に特定し、その他の実行者をSupportとして明確に区別したのが、RASCIだ。従来のResponsibleを2分割したものとも言える。

Responsible（実行責任者）：タスクの実行・完了に責任を負う者。
Support（サポート）：Responsible配下に当てられた者。Responsibleと共に実際にタスクを実行する。（実際にタスクを実行するため、Consultedとは違う。）

担当者だけでなく無関係者も明確化したCAIRO（RACIO）

通常のRACI図に、Oを追加したものだ。

Omitted、もしくはOut of Loop（部外者）：タスクに関係ない者。

通常のRACIでは、タスクに関与しないリソースを特に役割がなく基本的には部外者であると明確化することも有効な場合もある。（Oの人間は、特定の会議に呼ばないという規則を作って、リソースの効率化するなど）

検証者と承認者を追加したRACI-VS

RACIに新たな二つの役割を追加したものだ。

Verifies（検証者）：成果物が当初の基準を満たしているか検証する者。
Signs off（承認者）：Verifiesの検証結果を承認する者。承認し、次の工程への受け渡しに責任を持つ。

Verifiesは、Accountableが設定した基準などを、Responsibleが達成しているかを検証する役割だ。第三者的に検証する場合もある。
Signs offは、Accountableと同じ人物であることもあるが、クライアントなどAccountableとは別になることもある。Signs offが多すぎると、プロジェクトのスピードが落ちる。

いずれも成果物の結果に責任を持つ者(Accountable)と、その結果の判断をする者を明確に分けたい時に有効だろう。

バリエーションを知ることで、引き出しが増える。

RACI図さえ知っていれば、基本的な対応は可能だ。しかし、RACI一つしか知らないと、それが絶対だと思ってしまいフレームワークに囚われた状態になってしまう。派生系を知っていれば、プロジェクトの状況に合わせて柔軟に活用することもできる。また、フレームワークは本来作るものだ。状況に応じては、その状況にあったオリジナルな役割を追加するという柔軟性があってもよいだろう。

 

RACIチャートの意味とは？プロジェクトの責任分担を見える化する！
 RACIチャートの意味とは？プロジェクトの責任分担を見える化する！ 1024 683 Biz Tips Collection

RACI(レイシー)チャートとは、プロジェクトにおいて、プロジェクトメンバーの役割を明確にするためのフレームワークだ。コンサルタントがプロジェクトマネージメントでよく使用したりする。ステークホルダー（関係者や組織）が多い時に特に有効なツールとして利用できる。そんなRACIチャートがどんなフレームワークで、どのような場面で利用されるのか、解説する。

RACIチャートとは、役割や責任を定義するフレームワーク

「この件は誰がボールをもっているんだ？」
「渡辺さんが進めてたんじゃなかったの？」
それぞれの役割が明確でないと、このように、誰も進めていないタスクが発生したり、ボールの押し付け合いが発生したりする。
このような事態が発生しないようにプロジェクト、特にステークホルダーが多いプロジェクトでは、役割の明確化が重要だ。
RACIチャートは、そんな時のために使用されるフレームワークの一つだ。

RACIチャートは一言で言えば責任分担表だ。
RACIチャートでは参加者を以下の4つに分類する。
参加者は、人の場合もあれば、複数の組織が関わる場合は、組織単位の場合もある。

Responsible（実行責任者）：タスクを実際に実行することに責任を持つ人。複数いることもある。
Accountable（説明責任者）：タスクの結果に最終責任を持つ人。成果物やタスクの遂行に対して上層部などへ説明責任を持つ。タスクの承認者ともいえる。１人にすべきである。
Consulted（協業先）：タスクに対して相談を受ける人。実行や成果に明確な責任は持たないが、必要な専門知識などをもっており必要に応じてサポートする。
Informed（報告先）：タスクの進捗・完了や成果物について、報告を受ける人。

Consulted（協業先）とInformed（報告先）は、必ずしも必要でないが、Responsible（実行責任者）とAccountable（説明責任者）は必須となる。

RACIチャートを作る際、しっかりこの4つの定義を理解している必要がある。いざ作り始めて、作りづらさを感じる時は、ここの定義がしっかりわかっていないもしくは明確に決定されていない場合が多い。以下がよくごっちゃにされてしまう役割の違いだ。

あいまいにされやすいResponsibleとAccountableの違い

上司と部下で例えるとわかりやすい。部下はタスクを実際に実行するが、その結果を更に上の部長に報告するのはその部下の上司だ。部下がやらかしたら、上司が責任をとらされる。だから、上司は部下のタスク内容を管理や承認する。この場合の部下がResponsibleで上司がAccountableだ。

実際の現場でタスクの最終責任者が実際に実行する場合、つまりResponsibleとAccountableが同じ人物の場合も当然ある。

わかりにくいConsultedとInformedの違い

ConsultedとInformedもまた、区別がつかず混同されることが多い二つだ。
わかりやすい違いは２点。
・Consultedではコミュニケーションが双方向だが、Informedは一方通行の報告。
・Consultedでは主に動く前にコミュニケーション(相談)する。Informedでは主に動いた後にコミュニケーション(報告)する。
Consultedはどう進めるか困ったときに聞く人、Informedは進捗があった後に伝えておく人だ。

 RACIチャートの例

上記のRACIの各役割の定義を踏まえ、実際のRACI表（チャート）は例えば以下の通りになる。

縦軸に人（もしくは組織）、横軸にタスク、そして各マスに役割が記載されている。
見ての通り、ResponsibleとAccountableは同じ場合もあれば、ConsultedとInformedはない場合が多い。

多数のステークホルダーで責任分担の認識をしっかり共有することが重要

RACIチャートが最も効果を発揮するのは、多数の参加者（ステークホルダー）がいる複雑なプロジェクトの場合だ。逆に、少人数のプロジェクトでは、わざわざRACIチャートを作らなくとも、各タスクの担当者を決めているレベルで十分回るケースが多い。複雑なプロジェクトでは、ボールがどこになるのか不明確にならないよう、RACI図を整理して公開しておくとよい。

逆にうまく行っていないプロジェクトで、現在のRACIチャートを書いて、役割が不明確なところを特定するという、問題解決的な使い方も可能だ。役割の不明確さだけでなく、AccountableとResponsibleの担当部署が遠すぎて、うまく連携できていない、という課題を特定できたケースも過去にあった。
ステークホルダーが多く、複雑なプロジェクトでは、RACIチャートを整理するのも手だ。

→問題解決の幅が広がる！RACIの4つだけでないRACI図の発展版