【ビジネスハック】マネジメントするなら、行動を指示せず役割を定義して行動についてフィードバックする。
先日、相手の習熟度に合わせて、指示を抽象化したり、具体化したりすべきというお話をしました。
今回は、その指示の抽象化について深掘りしていこうと思います。
具体的な指示
まずは、指示の抽象化を考える前に、具体的な指示について考えていきます。
具体的な指示とは、Aをして、Bをして、というように、行動が示されているものです。
例えば、
- この文書をコピー機の上に置いて、
- 蓋を閉めて、
- コピーしたい枚数のボタンを押して、
- スタートボタンを押してください。
と言えば、何をしなければならないかの行動が示されており、誰でもこの指示に従って、行動に移すことができます。
業務プロセスが確立されているような現場では、このように、業務内容がマニュアル化されています。
ファーストフードのように、アルバイトがスピーディに商品を提供できるのも、このマニュアルが具体的に定義されており、すなわち、行動のレベルまで作業が分解、整理されているからです。
抽象的な指示
抽象的な指示とは、それらの行動を抽象化した指示です。
抽象化の軸は色々とありますが、例えば、その行動に対する目的を指示とします。
例えば、
- 役員会で報告資料が必要なため、コピーよろしく！
という指示があるとします。これは、実際の行動に落とそうとすると、具体的な指示の１−４を実施することになります。
さらに言うと、この指示を受けたい場合には、参加人数は最大何人か？いつまでに必要か？コピーした資料を誰に渡せば良いか？等々の行動を自分で設計する必要があります。
抽象度が高い場合には、どんな行動を取る必要があるかを設計する必要があります。
前述の通り、マニュアル化されている仕事の場合には、設計作業は既に完了しており、文章として既に存在するため、設計の必要はありません。
ここに具体的な指示と抽象的な指示の大きな違いがあります。
さらに抽象的な指示
抽象的な指示をする場合には、相手に権限を与え、行動を設計させると言う側面があると言いました。
ここから、さらに抽象度を上げて相手を成長させることを考えていきます。
相手をもう一段成長させるためには、目的を共有した上で、相手の役割を定義することです。
例えば、
- 今度の役員会でプレゼンをするのは、xx部長だが、君にはそれが成功するように主体的にサポートをお願いしたい。今回の役員会で決裁されれば、我が部で超巨大プロジェクトが立ち上がる。そのプロジェクトの立ち上げメンバーになってほしい。
こうなると、そもそものプロジェクトの背景の理解や、プレゼン資料の内容の作成、検討への噛み込み等々、大きく行動が変わってくるはずです。
その中で、プレゼン当日には、事前にコピーを取るという行動も入るかもしれませんが、
具体的な指示を受けている時よりも、より主体的な行動が取られるはずです。
主体的な行動や、自分事として業務への取り込みを期待するならば、役割を定義すべきです。
フィードバック
役割を定義したら、それで終わりでは無いです。
適宜、その役割が期待通りに遂行されているかをチェックし、フィードバックしていく必要があります。
その際には、行動についてフィードバックすることが肝要です。
ここからむしろ、抽象度を下げて具体的な行動についてのフィードバックが重要です。
しかも、その場合には、実施した行動とそのフィードバックの間は可能な限り短い時間でした方が良いです。
これは相手の中での納得感が上がること、手戻りや修正への時間を削減するという効果があります。
そのため、役割を定義した後に、どんな行動をこの後取ろうとしているか？どのように物事を進めようとしているか？という設計内容を聞いて、その内容についてフィードバックを与えることが重要です。
その設計がされていないとすると、まずは設計することの重要性を理解させる必要があります。そのための時間を取ることが指示した側には必要です。
例えば、
- 今回は、xxxという行動を取ったが、その前に設計という行動を取るべきだった。なぜなら、全体像が把握できていないままだと、作業の抜け漏れや、時間が足りなくなる等のリスクが発生するからだ。
このようなフィードバックを通して、次の行動が変わっていくはずです。
パーソナルなダメ出しや、根性論のように意識についてのフィードバックではダメです。相手も聞いてくれませんし、意味が無いでしょう。大事なのは行動についてのフィードバックです。それならば、相手はすぐに行動を変化させることができます。
まとめ
今回は、抽象的な指示についての深掘りでした。
マネジメントをする上で、重要なのは役割を定義してあげること。
その上で、行動についてフィードバックをして、相手を成長させていくことです！
実際これは、自分で自分に役割を定義して、それができているかをセルフチェックすることにも使えます！
マネジメントは、他人に対しても、自分に対してもしていきましょう！
日々成長！
では。
【プロジェクトマネジメント】期待値管理をしよう！Expectation Managementのススメ
どうも、みなさんプロジェクト運営していますか？
今回はプロジェクトオーナーからの期待値に関してのお話です。
プロジェクトマネージャーとして、プロジェクトオーナーからの期待とどう付き合うべきかお話させていただきます。
高い期待値とその弊害
「このプロジェクトがうまく行けば、弊社の重要課題のアレもコレも解消されて、新しくアレもコレもできる様になる！だから、よろしく頼むよ！」なんて、経営層から言われて、動き出すようなプロジェクトが存在します。
夢の様なシステムの開発や、新業務の企画等、頭の中に夢がいっぱいで期待ばかりが高まって、その様なプロジェクトは始まります。
そして、高い期待がさらに高まり、「アレもやってみよう！コレもやってみよう！」とスコープが広がり、タスクがどんどん溜まっていく。
どこかで誰かが止めないと、現状の要員では賄いきれず、残業の増加、成果物の品質の低下、スケジュールの遅延、最悪、体調不良での要員離脱等々恐ろしい未来が待っています。
このような弊害を回避すべく、そもそも無理なものは無理ということが必要です。
ここで必要となるのが期待値管理となります。
プロジェクトのオーナーもいじわるしたくて、期待値を上げていることは無いはずです。
そのため、想定されるリスクや懸念を提示して、釘を刺しましょう。
「他社で同じような検討に取り組んだ事例が存在しており、3000億円かかってまだ完了していません」
「アレもコレもやった場合には、XXタスクが想定され、それを実施するための準備期間が相応に必要になりそうです。アレか、コレだけに集中しない限り相当の時間がかかることが想定されます」
「それだけのことをやろうとすると、XXに関するプロフェッショナルや現場を理解しているメンバーがxx人以上必要となり、トータルでxx人は必要ですが、確保できそうでしょうか？」
まずは、相手の出鼻をくじくことで、期待値が上がっていかない様に予防線を張りましょう。
プロジェクトに対する期待と成功/失敗の関係
期待に胸を膨らませている人の期待を萎ませるのは申し訳ない気も少々しますが、そこはプロジェクトマネージャーとして心を強く持って、相手の期待を下げにいきましょう。
そもそも、期待値管理をする上で考えるべきは、プロジェクトの成功と期待値の関係です。
プロジェクトの成功とは、何かというと、期限内に完了させるや、相手が期待する品質で成果物を提供する、予算内で完了させる等々、色々な要素がありますが、一言でまとめると、プロジェクトオーナーの期待値を越えることです。
プロジェクトの失敗とは、その逆に、プロジェクトオーナーの期待値に至らないことです。
さて、ということは、申し訳ない言い方ですが、期待値は下げれば下げるだけ、プロジェクトの成功率は上がることになります。
そのため、プロジェクトマネージャーとしてはできるだけ期待値を下げるに限ります。
早ければ早いほど活きる交換条件
ただただ期待値を下げることも有効ですが、他にも有効な手段があります。
リスクや制約が把握できた際に、期待値を下げるのではなくて、交換条件を提示するというものです。
「これはなかなか難しいですね。。。では、以前、別プロジェクトで一緒だったxxのプロフェッショナルのAさんをこのプロジェクトに入れても良いですか？」
「xx人の要員を追加できない場合、期限通りの完了は難しそうですね。。。」
「ひとり専担で御社のメンバー（例えば、依頼主の会社がある場合）、特にxxができる人を1ヶ月張り付けていただけますか？」
「当初予定していた完了日のxx月待つから3ヶ月期間を延長すれば、取り込み可能です。」
そして、この交換条件はできるだけ早く提示する必要があります。
これがすぐに提示できないと、「なぜあの時に言ってくれなかったのか？できなかったことの言い訳を今するなよ！」という形で怒られます。
正直、これは怒られて当然です。リスクやその予兆を検知し、対応策を考えて提示することがプロフェッショナルには求められます。
まとめ
プロジェクトオーナーの期待値は下げるべき、また、下げられないなら交換条件を突きつける、という期待値管理について今回はお話ししました。
皆さんもプロジェクトの成功に向けてご参考になさってくださいませ！
では。
【ビジネスハック】人を育てるなら習熟度に合わせて指示の抽象度を変えよう
マネジメントをする上で人を育てることは重要な業務の一つです。
以前、プロジェクトマネジメントの記事でも人を育てることに触れましたが、
ここではさらに深堀していこうと思います。
習熟度
ある役割や新しいタスクの実施をプロジェクトメンバーに期待しているという状況だとします。
その際に、そのメンバーがその新しいタスクに対してどれだけ理解が深いかを習熟度と呼びます。
例えば、初めてのタスクで、かつ、類似のタスクも実施したことが無い場合、誰かからインストラクションをしてもらって、メモを片手に実施することかと思います。
それでも、初めてなので、時間がかかったり、失敗してしまったりすることもあるかもしれません。（ここでの失敗は目に見えるわかりやすいトラブルや、指示した人の期待値に足りない等が想定されます。）
一方で、例えば、同じタスクを既に経験済み、あるいは、類似のタスクを実施したことがあり、誰からのインストラクションも必要とせずメモも見ずにタスクを進められるような状況もあるかと思います。
あるいは、そこまでいかなくても、以前のメモを片手に問題無くタスクを進められるということもあるかもしれません。
明らかに、前者と後者ではタスクに対する習熟度が異なります。
さて、このような状況下で、指示を出す側は同じ指示を出して良いでしょうか？
また教育的な観点で見た時には、どのように指示を出すべきでしょうか？
前者のイメージ
後者のイメージ
※ 上記はイメージです。しかし、イラスト屋さんのイラストの種類は本当にすごいですね。無い画像が無い気がします。
習熟度が低い場合
習熟度が低い場合には、指示の抽象度はできるだけ低くして、具体的な指示を出すべきです。
前述の通り、そもそものやり方の分からないタスクを振っているため、具体的な手順を示さなければ、支持された側は何もできません。
簡単な例ですが、会議室を予約するには、このLINKを開いて、このボタンを押して、〜〜〜のように、一つ一つの手順を説明する必要があります。
他には、xxの調査資料を作成してもらうというタスクであれば、インプットとなる情報はxxから取って欲しいであったり、アウトプットのフォーマットはこちらで作成したものに合わせて埋めてほしいというように、より具体的な指示を出します。
育てるという観点で重要なのは、同じ説明を二度としなくて済むように、単独でできるようになるまで理解してもらうことです。
後者の調査資料作成の場合には、なぜ最終的なフォーマットにAという項目や Bという項目があるかといった考え方も合わせて教えるべきです。
プロジェクトメンバーが今後、単独で実施できるようになるためには、なぜ指示する側がこのようなことをタスクが必要となったかの背景や、それに照らしてどのような考え方でインプットやアウトプットを想定しているかを理解させることです。
ちなみに、習熟度という軸以外に、タスクの複雑度も存在します。どれだけそのタスクが難しいかです。
例えばですが、複雑でないタスクの例として、会議室の予約のようなタスクがあります。
複雑なタスクとしては、システム開発におけるコンパイルやリンケージのように、各社の開発環境に依存するようなものもあります。
この複雑度を考えると、前者と後者では手厚さを変えるべきです。
後者については、例えば実際に、そのやり方を見せても良いかと思います。あるいは、詳細なイメージ付きの手順書を配布することも手だと思います。
特に、他の人に迷惑をかけるような注意点がある場合にはしっかり伝える必要があります。
習熟度が高い場合
習熟度が高い場合には、むしろ、指示事項の抽象度を可能な限り上げて、プロジェクトメンバーに取っての自由度を上げます。
ここで自由度が高いとは、そのタスクについての進め方について、コントローラブルな状態を指します。
人間はコントローラブルな状態でない場合、ストレスを感じます。
また、言われたことをやっているだけでは自発的に考えることをせずに、指示待ち人間ができあがっていきます。
上司がうまく仕事を任せられない場合、部下はうまく育ちません。
そういった部下を前に、ストレスを感じているならば、自分が反省をした方が良いです。
そうしてしまったのは自分です。
そして、抽象度の高い指示が重要なのは、指示する側の期待値を超える可能性があることです。
進め方について、プロジェクトメンバーに考えさせるため、指示する側の考えを上回る新しいやり方や、新しい観点で進めてくれる可能性があります。（逆もまた然りです。）
そのため、何かの調査であれば、AAについて調査して、パワポ5枚くらいで送付よろしく！くらいの指示で大丈夫です。もちろん、背景やら観点やらを伝えた上でです。
ただし、気をつけるべきは投げっぱなしにしないことです。
作業に取り掛かる前に進め方を確認しておく、中間ポイントを設定して状況を確認する等で、最終成果物を作成する前に、方向性が修正できるようにします。
作業が先に進みすぎると、手戻りが大きくなり無駄な時間、コストが発生します。
また、そもそも、このタスクの責任自体は、プロジェクトメンバーかもしれませんが、その成果物自体の責任は指示した側にあります。
まとめ
ここまで人を育てる際の指示事項とその抽象度についてお話ししました。
人を育てるって難しいです。
一つ一つのタスクが相手にとっての成長になるように、マネジメントする側は常に考える必要があります。
もちろん、人によっては習熟度や、性質が異なるため、それぞれに適したやり方を常に模索する必要があります。
日々の積み重ねが大きな成果を産むようになるでしょう！！！
【プロジェクトマネジメント】プロジェクトの目的は抽象度を上げて設定しよう！
以前の記事では、プロジェクトの目的はWhatをちゃんと考えて、Howを混同するな！という話を記載しました。
最近、読んだ本の中で、より分かりやすく、私の言いたいことが表現されていたため、自身の考えを再度整理していこうと思います。
問題発見
プロジェクトは時代の流れや状況に応じて、期限が設定されて実行されるものです。
そのため、そのプロジェクトを「やる意味」が必ず背景に存在します。
個別のプロジェクトに降りてくる前に、おそらく、経営上の戦略や課題があることでしょう。
それを一段、あるいは、二段噛み砕いて目的を設定することが重要です。
そこで、必ず自分たちで問わなければいけないのは以下のような質問になります。
- そもそもの問題は何か？
- そもそものなぜ必要か？
- そもそもなぜこのプロジェクトを遂行する必要があるのか？
Whyのように抽象度を上げる言葉が目的設定には重要です。
問題解決
上記の問題発見がされて始めて、具体的な製品やサービスに落とし込まれます。
今度は与えられた制約の中で、どのようにそれを実行していくかを検討することが重要です。
- どのようにその問題を解決するのか？
- その必要なものはどのようなものか？
- （成功させるために）どのようにプロジェクトを遂行する必要があるのか？
今度は、Howのように具体度を上げる言葉が重要です。
抽象度の高い目標設定の意味
例えば、上記の考え方に応じて、システム投資プロジェクトを考えます。
単純に、幾らかのコストをかけて新規システムを構築するものとしましょう。
その場合、問題発見の観点から、「新しいシステム投資はなぜ必要か？」を問うことで、目的を明確にします。
ここで重要なのは、そのなぜ？を複数回繰り返すことで、抽象度を可能な限り高めることです。
システムを構築する
→ （なぜ？？）
（１つ目のwhy）ペーパレスを実現するためです
→ （なぜ？？）
（２つ目のwhy）事務コストを削減するためです
例えば、上記のように、一段目でwhyをやめてしまうとまだ抽象度が低く、目的としてはいまいちとなってしまいます。
一方で、二段目のWhyの深掘りまでできると、手段が適切に選択でき、かつ、何かあった時に手段が再選択できます。
事務コストを削減するために、システムを開発するのではなく、そもそもオペレーションを変更しよう！であったり、そもそも、その事務が必要なサービス自体から撤収するという選択も可能となります。
ここが目的の設定の重要なところです。プロジェクトにはリスクはつきものです。そのため、迂回路が設定できるような抽象度に初めから目的を設定しておくことが重要です。
改めて、再度整理すると、下記の図のようにプロジェクトとして実施すること(What)をベースに抽象度を上げて目標を整理するのにWhyという質問が有効です。そして、それは再帰的に適用できます。新たなWhatに対して、さらにWhyを質問できるのです。
一方で、上記の図の右側のHowも再帰的な性質を持っており、目標が妥当かの論理的つながりを検証することも可能です。
例えばですが、
「事務コストを削減するために、ペーパレスを実現します。」
「ペーパーレスを実現するために、ワークフローシステムを開発します。」
のように、 文脈のつながりを確認することが可能です。
実行時には目的の具体化
一方で、プロジェクトのゴール設定においては、定量的に評価が可能であることが求められます。
一度、抽象度を上げましたが、再度具体度を上げていく作業が必要となります。
例えば、前述の例においては、
- コストを削減すると決めたら、何％削減するか、いくら削減するかを具体的に数値として定める。
- ペーパーレス化するカバレッジは事務プロセス上の何割か。
- システムであれば、自動化されるプロセスの割は何割か。
- 事務ミスで発生するはずだったコストが、システム導入で何割削減されるか？
といった具体的な目的を定めていきます。
また、システム開発の非機能要件も具体的な目標値とされることもあるでしょう。
- ワークフローのレスポンスタイム
- 特定のバッチ処理の完了時間
プロジェクトマネジメントのベストプラクティスにおける具体的な目標の設定は、抽象度の高い目標を設定した後に実行時にするべきというのが、ここのポイントになります。
どちらか一方だけでは足りないと言えます。
最後に
改めてプロジェクトマネジメントにおける目的設定のお話でした。
大事なのは抽象度の高い目的設定です。
皆さんもご自身のプロジェクト開始時、運営時には、目的を改めて疑うことをお勧めします。
炎上や失敗を回避するためには、最初の目的設定が重要です。
今回は、細谷先生の書籍を参考にさせていただきました。
細谷先生の本はとても分かりやすく纏まっており、論旨に対する具体例もめちゃくちゃ分かりやすいです。
興味のある方は是非、読んでみてくださいませ！
ちなみに、私はこちらも読みました。どっちも良いです！
【ビジネスハック】逆説思考で常識に捉われない切り口で発想しよう
何か新しいアイデアを出さないといけない、、、！
ちょっと尖った意見を求められている。。。！
ビジネスの現場にいると、こういうことってありますよね。
そんなあなたのために、常識に捉われない思考法についてお届けしていきます。
ちなみに、過去記事の水平思考も常識に捉われないという意味では似た性質を持っています。
しかし、今回の逆説思考は一般論、常識、定説を疑うことに特化して、新たな切り口を考えていくものです。
新しいアイデア創出に向けて、行き詰っている方の一助になればと思います。
Gerd AltmannによるPixabayからの画像
逆説思考とは
逆説思考とは、世間的、一般的に正しいとされている常識に対して、その逆を考えることで新たな切り口で発想する思考法です。
新たな商品や企画を考える際に、枠にハマった意見になることは往々にしてあります。
これは中堅やベテランの方によく見られることで、決まったやり方や定説を知っているが故に、これまでの経験、パターンにすぐに当てはめてしまうことがよくあります。
こういった凝り固まってしまう組織内の常識や考え方を打ち壊していくためにも、組織に若手や新しい風が求められることは必然です。
一方で、常識に捉われずに新しいことを取り入れるような温故知新な中堅やベテランさんも、もちろんいらっしゃいます。
そういった方々は、元々、逆説思考が出来ているような方々です。
逆説思考の方法
逆説思考は以下の手順で進めます。ここから具体例を取り入れつつ説明していきます。
- 論点の設定
- 定説の検討
- 逆説の検討
- アイデアの検討
論点の設定
まずはいつも通り論点の設定です。今、取り組むべき課題が何かを考えましょう。
例えば、コンビニでも質の良い傘が手軽に買えるようになったため、傘の売り上げが著しく落ちている。
といった課題から、
新しい傘をデザインしてこの状況を打破しよう！！
といった論点を設定します。
ちなみに、ここでは、新しい傘の商品企画を論点として設定していますが、流通チャネルを増やすとか、リピートを増やすためにアフターセールスのメンテナンスに力を入れる等々、課題を深堀すれば、別の論点となっていきます。現場では、全員が腹落ちする課題をしっかり特定することが大事です。
定説の検討
論点に対して、世間的、一般的に正しいとされる定説を考えます。
大事なのは、当たり前すぎて触れられないようなことを確り可視化することです。
この当たり前すぎて誰も触れない部分に良い観点があったりします。
常識 → 逆説なサービス、商品
車は所有するもの → シェアカー
音楽は買うもの → spotify (サブスクの音楽サービス)
携帯は電話するもの → スマホ (携帯はインターネットへの入り口)
デリバリーはそのお店の従業員がするもの → Uber eats
世の中の革新的な商品やサービスは、「〇〇って商品、サービスは一般的にこういうものでしょ」という常識を打ち壊しています。
そのため、ここでは確り当たり前を出し切りましょう。それが出せれば出せるだけ、この後の手順で面白い観点が出せます。
ちなみに、傘の例でも考えてみましょう。
傘といえば、
- 手に持って、さして使うもの
- 使う前に購入するもの
- 所有するもの
- 雨の日に使うもの
- 雨に濡れないようにするもの
- 恋人たちが寄り添うもの
逆説の検討
次に、並べ出した定説に対してその常識を疑って逆説を考えます。
ちなみに、逆説をgoo辞書で調べると以下のような意味だそうです。
- 一見、真理にそむいているようにみえて、実は一面の真理を言い表している表現。「急がば回れ」など。パラドックス。
- ある命題から正しい推論によって導き出されているようにみえながら、結論で矛盾をはらむ命題。逆理。パラドックス。
- 実に反する結論であるにもかかわらず、それを導く論理的過程のうちに、その結論に反対する論拠を容易に示しがたい論法。ゼノンの逆説が有名。逆理。パラドックス。
全部の項目に「パラドックス」と書く意味が果たしてあるのか。
ここで考えるべきポイントは、１つ目の意味定義から、「その真理にそむいている」、すなわち、「常識と思っていたが、そうではないとしたら？」を考えることです。
「定説では〇〇なのに、××」を考えていきます。
傘の例で考えていきましょう。
- 手に持って、さして使うもの
→ 手に持たない、ささないとしたら？ - 使う前に購入するもの
→購入する前に利用する、つまり、利用後に支払いをするとしたら？ - 所有するもの
→所有すること無く利用できるとしたら？ - 雨の日に使うもの
→雨の日以外に使うとしたら？ - 雨に濡れないようにするもの
→傘なのに濡れても良いとしたら？ - 恋人たちが寄り添うもの
→パーソナルスペースと同じサイズが実現できるとしたら？
ここでは、「〜だったら？？」どうなるだろう？？と言う疑問を出します。
その疑問が、これまでには無い常識を疑った観点になっています。
アイデアの検討
最後のステップです。
整理した逆説の観点から、論点に対してのアイデア出しを行います。
既に、常識に捉われていない観点が並べられているため、それを利用して、常識に捉われないアイデアを出していきます。
- 手に持って、さして使うもの
→手に持たない、ささないとしたら？
→着る、背負う、かぶる、乗せる、浮いている、ついてくるといったキーワードが何となく思い浮かびます。ドローンで自動追従してくれるでも、自動運転で後ろから傘をさしながらついてくるでも色々とアイデアが出そうです。 - 使う前に購入するもの
→購入する前に利用する、つまり、利用後に支払いをするとしたら？
→シェアアンブレラ、同じ方向に進む方とマッチングして傘に入れてもらい、入れてもらった分、小額決済する。家に向かうみたいな場面ではセキュリティ上ちょっと怖いですね。
→シェアバイクのように特定の場所に置いておき、その間の利用を想定する。これはこれでラストワンマイルじゃ無いですが、そのポイントに行くまでや、そのポイントから目的地に移動するまでは結局濡れるので嬉しく無いですね。
→Uberのように傘を差すことを代行する。空き時間がある方に傘とそれを差すことを代行して、ついて来てもらう。何だか怪しいサービスになってきました。
- 所有するもの
→所有すること無く利用できるとしたら？
→傘のサブスクサービス。定期的に色々な傘が届き、色々なデザインの傘を代わる代わる使うことで雨の日もハッピー！（傘は交換方式にしましょう。）しかし、普通にめんどくさいですし、ペイしなそうな仕組みですね。 - 雨の日に使うもの
→雨の日以外に使うとしたら？
→日傘と雨傘を兼務にすることで、雨の日に限らず常備するものとしてしまう。既にありますね。
→差していない時は別の機能を提供する。例えば、アンクルウエイトのように、重くしておき、筋トレになるとか。S字フックとしての機能性を持たせるとか？自分で書いておいて、ちょっと何言っているかわからないです。 - 雨に濡れないようにするもの
→傘なのに濡れても良いとしたら？
→もうそれは傘じゃ無い。 - 恋人たちが寄り添うもの
→パーソナルスペースと同じサイズが実現できるとしたら？
→既にポケットに入る、物凄い小さい傘があるらしいです。
何だか途中から「ちょっと何言っているかわからないです」状態になってますが、逆説思考のやり方のイメージが湧いていれば嬉しいです。
使い所
逆説思考の使い所は、新商品、新企画、何かの意見出しの場面だと思います。
もう少し拡大解釈して考えると、与えられた前提を疑うと言う考え方でもあると思います。
そう考えると、ビジネスの場面では、常に意識しておく必要があります。
常に、前提が正しいかを疑ってかかる事で、課題や対策が正しく設定できます。
そして、それが無駄な作業の排除、効率性の向上に繋がります。
まとめ
今回の記事では、常識に捉われない思考法として逆説思考を紹介しました。
この思考法の名前を知らなくても、意識せずにやらている方もいらっしゃると思います。
一方で、普段できていないと言う場合には、是非使ってみてください。
考えの幅が広がる事間違いなしです！
では！
【ビジネスハック】内省、振り返りを効率化するKPTとYWTフレームワーク
内省してますか？
社会人経験がある程度進んでいくと、立場が上がり誰も指導鞭撻してくれないですね。
自分で自分の改善点を見つけて、成長し続けることがビジネスマンには求められます。
また、社会人経験が少ない頃から、内省の習慣が確りできていると周りの同僚よりも成長が速いです。
一方で、内省や振り返りと言っても、どうやれば良いの？と思っている方もいるかもしれません。そこで今回は２つのフレームワークを紹介します。
振り返りの必要性
日々の業務の中でも、人生でも、物事の計画に対して結果がどうだったかを可視化していますか？
計画と結果のズレを可視化して、計画通りに進まなかったのであれば、その理由を明確にして次の打ち手を考えます。
これは計画の精度を上げることや、作業効率、生産性を高めることに繋がります。
あるいは、何か課題解決をした際のやり方や、業務に対してどのように取り組んだかを言語化しておくことで、次の機会や、別の事象にも当てはめることができます。
すなわち、業務でも、人生でも、自身の経験を抽象化して、理論化することで、次に活かすことができます。
逆に、振り返りをしない場合には、生産性は上がらず、学びが無いまま、同じやり方を繰り返してしまいます。
振り返りのやり方
振り返りをするためのフレームワークが２つありますので、それぞれ紹介します。
KPT
まず、今回のプロジェクトでも、今週の業務でも振り返る対象を決めてください。
よかった点、改善点と思う事を挙げ出していきます（図の左側）。
この際、当初の計画があれば、それと比較して、結果がどうだったか、なぜその結果となったかを考えると、自ずと良し悪しが見えます。
その次に、良かった点、改善点を踏まえて次に何をすべきを考えます（図の右側）。
よかった点を、よりよくするためには何ができるか？あるいは、継続する仕組み、仕掛けが構築できないか？自身だけでやっていたことをチームに拡張できないか？見てみてください。
改善点に対しては、どうすれば改善できるか？何が原因でうまくいかなかったか、それを解消するための仕組みや仕掛けが構築できないか？チームとしての仕掛けで解消できないか？見てみてください。
ちなみに、自身の成長のためには、改善点を潰していくというProblemとTryに集中してしまうかもしれませんが、モチベーションの維持や、自分の強みをさらに強化させて尖らせていくという意味では、Keepも確り上げ出しましょう。
逆に、どちらかしか出ていないというのは、まだ挙げ出す余地があると思って良いでしょう。
KPTは、「計画に対して、良かった点、悪かった点を挙げ出して、次の行動に活かす」という一連の流れを踏んでいます。
YWT
こちらは、特に業務中に何らかのトラブルが発生した際や、課題に直面して取り組んだ際に活用できます。
課題を解消するために何をしたか？を時系列で良いので列挙してみます。
そのそれぞれのDOに対して、やった結果、分かったことを記載していきます。
例えば、課題解消のために、Action Planをまず立てた。しかし、Item AとItem Bが漏れていた。誰かに助言を貰った方が良かった。のように分かったことを整理していきましょう。
これは、良い点も悪い点もあると思います。
それを次やることに昇華させます。
先ほどの例の場合、誰かに助言を貰った方が良かったというところまで整理できたら、次は、隣のチームのxxに詳しい先輩に事前に確認してもらう！等のアクションに落とし込むことができます。
「経験したことを、振り返り評価して、次の行動に活かす」という一連の流れを踏んでいます。
振り返りのタイミング
プロジェクトの完了を待たずに、１週間に１度でも振り返りすることをお勧めします。
その気づきが明日のあなたの仕事を効率化する！と考えると、最初から計画に入れておきましょう！！
そして、人間は折角の経験も忘れていきます。振り返りを行い、言語化して、自身の行動を変えましょう。
毎週、毎週、やり方を改善して、成長していくやつと、1年に1回振り返りをしていくやつでは成長の速度が大きく異なります。
これは、最初の出来、不出来じゃ無いです。
周りにもいるはずです。
新入社員の頃、隣の席に良くできる同僚A君がいたかもしれません。
さらにその隣にこいつはうだつが上がらないと思ったB君がいたかもしれません。
しかし、そんなB君が今ではA君の上司になっていることもあるでしょう。
何度も言いますが、大事なのは、最初のスペックじゃないです。
どれだけ日々、成長できるかです。
今日の自分よりも、明日の自分の方ができる！と思えるように、振り返りの機会を作り、是非、成長していきましょう！（自戒を込めて）
まとめ
今回は振り返りの必要性と振り返りのフレームワークであるKPTとYWTを紹介しました。
KPTは、良かった点、改善点、次何するかを整理するフレームワークです。
YWTは、やったこと、分かったこと、次何するかを整理するフレームワークです。
どちらも活用して、人生を豊かに成長させていきましょう！！
では！
【プロジェクトマネジメント】人を育てること、ノウハウを蓄積することもプロジェクトスコープ
プロジェクトしていますか？
プロジェクトを成功させるだけではプロマネのお仕事としては不足しています。
プロジェクトマネジメントの中には、チーム育成、プロジェクト知識のマネジメントが存在します。
今日はその二つのお話をしていきます。
プロジェクトを通して人を育てる意味
資源マネジメントにおいて、実行プロセスの中にはチームマネジメント、チーム育成が入っています。
以下の全体像から確認してください。
プロジェクトを成功させるためには、人材の育成が不可欠です。
プロジェクトには期日が存在しますが、事業活動、事業継続には期日が存在しません。一つのプロジェクトを成功させれば終わりという訳にはいきません。
プロジェクトを通して、人材が成長し、より難しいプロジェクト、より難しい事業活動ができるようになっていく必要があります。
そのためにも、プロジェクトを通して人材を育成できるようにすることもプロマネの仕事です。
プロジェクトを通してノウハウを蓄積する意味
統合マネジメントの実行プロセスには、プロジェクト知識のマネジメントが含まれます。
プロジェクトを成功に導くためには、過去プロジェクトの成果物、ノウハウの利用が重要です。
過去プロジェクトの成果物がそのまま使えるわけでは無いですが、参考にすることで効率的に作業を進めることができます。
そのため、こちらもプロジェクトを通して残せるように最初から計画に入れておくことが重要です。
人を育てる
具体的にプロジェクト内で「人を育てる」ことを深掘りしていきます。
人を内部から調達する
事業形態にもよりますが、自社のメンバーをプロジェクトにアサインすることがあると思います。その際に、そのプロジェクトを通してどのように育って欲しいかを計画できていますか？
プロジェクトマネジメントのプロセスに照らして考えていくことが重要です。
人を育てるのにも、立ち上げ、計画、実行、監視、終結のプロセスが存在します。
立ち上げ
- どのような人材にしたいか？
- 現状のスキルセット、マインドから何が不足するか？
- そのプロジェクトでは何が取得できそうか？
→ この思惑をどれだけうまく伝えて、モチベーションを上げられるかが重要になります。確り言語化していきましょう。
計画
- 取得想定のスキル、マインドはプロジェクトを通してどのように取得するか？例えば、スキルセットの合致した先輩社員をつける、外部研修に行く等々
→ 絵に描いた餅にならないようにするためには、実行方法の検討も必須です。
実行、監視
- 当初計画通りに、取得が進んでいるか？
→ 新しく何かを学ぶということは、少し高めの球を投げることになります。
そのため、本人にとってはしんどいです。最初に思惑を伝えただけでは、潰れる可能性もあります。そこのフォローをしていきましょう。プロジェクトのリスク管理と一緒です。
終結
- 当初計画通りに、取得が完了したか？
- 次回に向けて取得すべきスキル、マインドが整理できているか？
→ 確り評価しましょう。OKかNGか。NGの場合には、計画の何がいまいちだったかを可視化する必要があります。モチベーションを継続できなかったのならば、その仕組みを構築する必要があります。外部研修がイマイチだったのなら、次回は、別の外部機関を使う等を考えていきましょう。
こういったプロセスを通して、人を成長させて、プロジェクトの成功、事業活動の継続を実現していきましょう。
人を外部から調達する
外部から調達する場合には、上記ほど綿密に実施する必要はないです。（自社にとっての利がそれほどないため）
しかしながら、プロジェクト成功に向けて、どんなスキルが必要か、どれだけのボリュームが必要か、現状のスキルや過去実績からそれが達成できそうか？等々を整理することが必要です。ここは調達マネジメントに譲りますので、ここでは割愛します。
重要なのは、大規模プロジェクトや新規プロジェクトの場合の学習プランの提出です。
例えばですが、大規模プロジェクトや新規プロジェクトのシステム開発の場合には、新人エンジニアの参画や、他システムからの支援エンジニアが大量に投入されることがあります。
この場合には注意が必要です。これまでいるメンバーとは成果物の品質や納期に差が出てくるがあります。
こういった場合には、どのように教育していこうとしているのか、調達先から提出を求める等の牽制が必要です。ここが会社として考えられているところは、すぐに提出いただけるのですが、一方で、場当たり的に人材を派遣しているようなところだと出てきません。。。
そうなると、根本的なテコ入れが必要になります。
https://chojugiga.com/2017/09/01/da4choju51_0038/
から引用。
ノウハウを蓄積する
プロジェクトマネジメントの各知識エリアで作成した成果物を作成しっぱなしにしてはいけません。また最後に纏めて、次につなげられるように整理しましょう。
一番のポイントは、アップデートをし続けることです。
プロジェクトを推進していく中で、一度作成した成果物に更新が必要になるタイミングはあると思います。更新しなくても、プロジェクトの推進はできるかもしれません。
しかし、次のプロジェクトに活かせるか？を考えてみましょう。
更新をしているということは、その成果物では何か不具合があったということです。更新されないままだとその不具合が次のプロジェクトでも悪さをしてしまいます。
そのためにも、必ずアップデートしましょう。
個人的には、プロジェクトの完了のタイミングでこれまでの成果物を再度まとめて、ノウハウとして残して置くことをお勧めします。
そのためにも、計画の段階で、完了時のタスクに入れておきましょう。それが明日のあなたを救います。
まとめ
プロジェクトマネジメントって幅が広いというお話でした。
プロマネをされる方は、人を育て、ノウハウを蓄積し、長い目で先々を見ていきましょう。
それが我々のお仕事です。
では。
