【プロジェクトマネジメント】プロジェクトを立ち上げる際に整理すべき観点としてのプロジェクト憲章

プロジェクトを立ち上げてますか?

プロジェクトと、仰々しい名前で呼ばずとも、日々の業務の中で何か新しい仕事や、新しいタスクが発生して取り組むことは多々あるとあります。

 

もちろん、すぐに終わるような短期間のタスクや定例タスクは、すぐにやって終わりで良いですが、誰かを説得して動いてもらう、ある程度の期間を必要とするような場合には、最初にいくつかのポイントを整理すべきです。

プロジェクトの立ち上げも、新しい仕事に取り組む際も、プロジェクト憲章に従って必要な観点を整理していきましょう!

 

今回の記事ではプロジェクトを立ち上げる際に整理すべき観点をプロジェクト憲章に基づいて説明していきます。

f:id:yoshiya_na:20200506173052j:plain

 

プロジェクト憲章とは?

プロジェクト憲章とは、プロジェクトの立ち上げ時に最初に作成する成果物です。

PMBOKの定義上、プロジェクト憲章はプロジェクトを正式にスポンサー(あるいは、イニシエータ)に認可してもらうための文書と定義されています。

 

すなわち、これからこんなプロジェクトを始めると宣言するための文書であり、その内容を判断いただき、問題が無ければ予算をつけてもらいます。

そのため、承認者、つまり、誰が読んでも分かる言葉でプロジェクトの全体感が分かるような文書にしなければいけません。

 

プロジェクト憲章を作る意味

プロジェクト憲章を作る意味は大きく2つあります。

 

f:id:yoshiya_na:20200809142210p:plain

  1. スポンサーの承認をいただく
    前章で説明した通り、予算を出す権限を持っている方々に「プロジェクトの内容」を理解いただき、「このプロジェクトを進めて良い」と承認をいただくためにプロジェクト憲章を使います。つまり、予算承認者の意向からずれていないことを確認して、必要な予算を出してもらいます。

  2. プロジェクトの参加者が全員同じ方向を向く
    プロジェクトに参加しているメンバーがプロジェクトの目的、ゴールを共有して、同じ方向を向いて意思決定をしていくための重要な指針として使います。

    プロジェクトを進めている内に目的を見失うことは多々あります。

    f:id:yoshiya_na:20200607104448j:plain

    Gerd AltmannによるPixabayからの画像



    例えば、全体最適のためのアーキテクチャ改善のプロジェクトのはずが、特定の制約のために、一部個別最適を作ってしまい、それが全体に悪影響を及ぼすことはよく見かけます。

    例えば、事務コスト削減のためのシステム更改のはずが、既存機能を残さないと業務が回らないから、あれもこれもそのまま残して欲しい!と言う意見がまかり通ってしまい、結果的にシステムは変わったが、業務フロー改善もなされず事務コストも減らないなんてこともあります。

    もちろん、各メンバーに悪気は無いです。各メンバーは各課、各部署の最適を求めています。しかし、それがプロジェクトとしては最適ではないことが多々あります。

    プロジェクト憲章を作っておくと、このような本来達成したかった目標から逸脱することを防ぐことができます。プロジェクトを進める上での意思決定、判断するための指標を作成しておくことができます。
    逆に言うと、プロジェクト憲章に記載されていることがプロジェクト立ち上げ時に整理されていないと、プロジェクトはブレていきます。結果、後から振り返ると失敗プロジェクトになります。

プロジェクト憲章に記載すべき内容

プロジェクト憲章に記載すべき内容、すなわち、プロジェクト憲章の目次は以下のとおりです。

  • プロジェクトの目的
  • 計測可能なゴール
  • 大枠のスコープ
  • 前提条件、制約条件
  • コスト
  • スケジュール
  • リスク
  • 体制

 

プロジェクトの目的

プロジェクトの目的を最初に記載します。

ここで大事なのは、どんな課題が存在するか?、なぜそれを解決する必要があるか?(ここまでが背景)

だから、何をしなければいけないのか?(目的)までが表現されていることです。

 

以前、別記事でも記載しましたが、目的だけでは人を動かすことはできません。そこにストーリーが必要です。「なぜ、そんな目的が生まれたのか?」に対する答えとして背景が必要です。

www.yoshiyoshiya.com

 

よくありがちなのが、WhatとHowを混同してしまうことです。

「帳票を電子化しよう 」

目的に見えなくなも無いですが、実際には目的では無いです。

その後ろに本来やりたいwhatが隠れていています。

 

それを見極めるには、以下を問います。

「それは何のためにやるのでしょう??」

 

「帳票を電子化しよう 」

→「コスト削減、すなわち、紙を伴う事務コストの削減や、プリンタ等の設備費、紙の保管コストをそれぞれ〇〇円削減するために、帳票を電子化します。」

→「来年、事務センターを設立するので、センターと支店間のコミュニケーションコストが上がることを避けるために、今のうちに電子化してワークフロー上でやり取りできるようにするために、帳票を電子化します。」 

 

目的(=What)があり、そのためにこう言った方策(=How)を打ちます!

ということが言えない限りは目的が見えていないプロジェクトです。

残念ながら、目的がクリアになっていない限りこのプロジェクトはうまくいきません。

 

このプロジェクトが実現したら、何が得られるのか?という質問が経営から来た際に答えられ無いため、そもそも予算がつきません。

(※ 実際にはそんなプロジェクトはゴロゴロ転がっており、プロジェクトを止められないところまで来ていることも良くあります。その際には、まず目的を立てて、立て直すことが重要です。)

f:id:yoshiya_na:20200809141525p:plain

 

この目的が無いと、何かおきた際の判断がブレます。

プロジェクトでは必ず、想定外のことが発生します。その際に、立ち返る基準としてプロジェクトの目的は必須です。

プロジェクトの目的に照らして、想定外の事象に対する方針や方向性が正しいかを判断することができます。あるいは、目的に向けてあるタスクが最短距離になっているかを精査することができます。

 

逆に言うと、目的が明確になっていないと、念のために、あれもやって、これもやってと、スコープが大きくなっていきます。

 

計測可能なゴール

次に必要なのは、ゴールです。

どのような状態になっていれば、前述の目的を達成したと言えるのかを整理します。

そして、その状態が計測可能であることが重要です。

 

過去記事の「プロジェクトの成功の定義」で記載したとおり、計測可能でなければいけません。

www.yoshiyoshiya.com

 

ここの定義が曖昧だと、プロジェクト内で混乱を生みやすいです。

そのため、プロジェクトの大きなゴールと、それを分解して、個別のチーム単位や、システム単位のゴールを作成することで、できるだけプロジェクト参加者の思いがブレないようにします。


大枠のスコープ

次に、その目的やゴールに向けて何をするかを定義していきます。

どのようなタスクを想定しているか、作業範囲がどこまでかをここでは記載していきます。

 

後半に出てくる体制と絡めてどんなタスクを想定して誰がやるかを定義しておくことで、関係者を巻き込みやすい状況を使っておくとプロジェクト運営しやすいです。


前提条件、制約条件

このプロジェクトを進める上での前提条件を提示します。

特にプロジェクトで不足しがちな人、モノ、金についてプロジェクトを進める上で必要になる場合には、承認者に提示しておくことが重要です。

 

あるいは、プロジェクトの性質上、他のプロジェクトの成功を前提としていることもあると思います。そこを可視化して承認者に事前に理解いただくことも重要です。

承認者にはどんなリスクが発生しそうかを事前に伝えることが重要です。そのため、他のプロジェクトの成否が、今回のプロジェクトの成否に関わる場合には必ず伝えなければなりません。

 


コスト

ここは会社毎に違いが出てくる部分と思います。

概算を伝える。

予算の出元を伝える。

予算の最大値を伝える。

 

それぞれの会社のルールに応じて提示するコストを変えていきます。

とはいえ、「このプロジェクトでかかる予算」の規模感を理解いただく必要があります。

実施しようとしているプロジェクトがリスクを加味して、これだけのコストをかけてやるかやらないかを判断いただくためにはコスト規模感は必須です。

 

ちなみに、予算の最大値をここで提示しておくことは、スコープ拡大の抑制に繋がります。

ただし、立ち上げ時点ではスコープも未確定なため、段階的にコストを詰めていく等の宣言も重要です。


スケジュール

プロジェクト規模が大きい場合、スケジュールもコストと同様、大枠しか決められないことが多いと思います。

 

どのようなフェーズをどのような順番で実施するかを提示する。

フェーズ定義をプロジェクト立ち上げ後に決める場合には、マイルストーンを提示することが重要になります。

特に、プロジェクトの継続要否を判断できるような場が今後どのタイミングで来るかを承認者にご理解いただきましょう。

 

プロジェクトはリスクにさらされており、時には止める決断も重要です。そのためにも、どういったタイミングで、情報をお耳に入れられるかは提示しておくべきです。

 

リスク

プロジェクトにリスクがつきものなのは、過去の記事の通りです。

リスクの内部要因、外部要因をそれぞれ提示しておきましょう。立ち上げの段階でリスクが整理できていると対策の検討に時間が取れるため、プロジェクト成功の一助になります。

できるだけ立ち上げ時に整理しておくべきです。 

www.yoshiyoshiya.com

 


体制

プロジェクトのステークホルダーを可視化します。

ある意味、前提条件にもなりますが、ここで記載したステークホルダーがプロジェクト参画できない場合、プロジェクトはうまくいきません。

 

それぞれのプロジェクト参加者の役割と責任を可視化しておき、承認者の力も借りて、関係者をプロジェクトに巻き込むことが重要です。

この際、組織の壁を超えなければいけないことが多々あります。承認者(えらい人)の力を存分に使いましょう。

担当間ではらちがあかない場面もあると思います。えらい人を有効活用するためにも、ここの体制は確り練りましょう。

 

プロジェクト憲章を活用できる場面

プロジェクトの立ち上げ時に作成するものですが、プロジェクトと同じ性質を持つ仕事やタスクを実行する場合には、プロジェクト憲章の観点が役に立つと思います。

ここで言う同じ性質とは、独自性、有期性、変化、機能横断、リスクを指しています。

詳しくは過去記事参照。

 

www.yoshiyoshiya.com

 

また、プロジェクトを進める上で何か課題が発生した際には、プロジェクト憲章に立ち返り目的からずれていないかを確認すべきです。

立ち上げ時に作る資料ですが、活用は、プロジェクトを通してできます。

 

ただし、プロジェクト計画書等に、その内容を取り込んでプロジェクト憲章を破棄することもあるので、状況に応じてご活用ください。

 

まとめ 

今回の記事では、プロジェクトを立ち上げる際に整理すべき観点を、プロジェクト憲章を用いて説明しました。

プロジェクト立ち上げの際に参考にしてください。

 

立ち上げ時に多くの観点が整理できていれば、それだけプロジェクトを成功に導ける確率が上がります!

 

皆様のプロジェクト成功をお祈りしております!

 

では。

【ビジネスハック】トレードオン思考でトレードオフを超えた案を出そう!

世の中には何かを得ると何かを失うトレードオフの関係がよく転がっています。

 

例えば、よく言われるのは、品質とコストです。

何らかの製品、ソフトウェア、料理、あらゆるもののクオリティを上げようとすると、その分、時間やお金というコストが増えることになります。

言い方を変えると、品質を得るためには、コストが必要となるというトレードオフの関係にあります。

 

トレードオフの関係はその辺によく転がっています。

  • 勉強と遊び
  • 仕事とプライベート
  • 健康とジャンクフード
  • 出勤前の朝の時間と睡眠時間

 

トレードオフの関係を前に、どちらを取ろう??と考えていませんか?

それではもったいない!

まずは、そのトレードオフの良いとこ取りができないかを考えてみましょう。

片方を得たら、片方を失うという「トレードオフ」を打破して、両方得るという「トレードオン」してしまいしょう!!

 

今回の記事ではそのための思考法であるトレードオン思考について紹介していきます。

 

f:id:yoshiya_na:20200531141800j:plain

mohamed HassanによるPixabayからの画像

 

トレードオン思考とは

トレードオン思考とは、トレードオフの関係となっている相反する2つの観点を整理して、その2つを同時に得られるように考える思考法です。

 

通常トレードオフの関係となっているものは、以下の図のように、どちらかを得るとどちらかを失うことになります。

縦軸を品質、横軸をコストにします。

横軸がわかりづらくなってしまいましたが、右に行けば行くほどコスト安と捉えてください。原点に近づけば近づくだけコスト高になることを表現しています。

f:id:yoshiya_na:20200531143058g:plain

この図から分かるように、品質を上げようとすると、丸が原点に近づくためコスト高となることが分かります。

トレードオン思考では、このような状態から考え方を切り替えて、縦軸も横軸も両方を得られるように思考していきます。

以下の図のような点を考えてみることなります。

f:id:yoshiya_na:20200531143934j:plain

  1. まあまあのコスト(最大値の6割)で高品質(最大値の8割)を出す方法が無いかしら?
  2. 低コスト(最大値の3割)で少々の品質向上(最大値の4割)ができないかしら?
  3. 低コスト(最大値の3割)で高品質(最大値の8割)ができないかしら?

 

品質かコストかどちらかしか得られないと言う状況を打破します。

このように各軸に対して、適当に4つの象限に分割して考えるだけでも、3つくらいの案を出さなきゃいけなくなります。

 

一方で、このように整理することで、これまで「トレードオフだ。どっちを諦めよう、、、」という思考から一歩進むことができます。

ここから、捻り出してみれば良いのです!

これがトレードオンです。言うは易しですが、ここからがまた難しいですね。ただし、闇雲に考えるよりも、少しは検討しやすくなっていると思います。


トレードオン思考の方法

トレードオン思考については、以下の順番で進めます。一つ一つ解説していきます。

  1. 何を得たいかを定義する

  2. 得るために失うものを定義する

  3. トレードオンを挙げ出す

 

何を得たいかを定義する

いつも通り、論点の設定です。ここでは何が解決したい課題なのかを定義します。

 

例えばですが、傘について考えましょう。

新しい傘を考えましょう。(毎度、傘ですみません。傘が好きなんです。)

傘は持ち運びが面倒です。そして、私はいつもどこかに置き忘れます。

また、傘を持っていると、電車で本を読むにも手が塞がっているので、なかなか鬱陶しいです。

 

そこで「手元の自由さ」を得たいものとして定義します。

新しい「手元の自由な」傘を考えます。

 

得るために失うものを定義する

次に、得たいものを得るために、現状失っているものを考えます。

これは、反対の事例を考えてみると考えやすいです。

 

例えばですが、傘に対して、他の雨具を考えます。手元が自由な雨具として合羽が思い浮かびます。

傘を持たずに、合羽を着ることで失うものは何でしょうか?

オシャレ感ですね。

 

縦軸を「だささ」 ⇅ 「オシャレ感」

横軸を「手元の自由さ」 ⇆ 「手元の不自由さ」

として定義します。

 

この定義に基づきプロットすると以下のようなグラフができます。

f:id:yoshiya_na:20200531150413p:plain

 

本当にトレードオフか?と言う疑問は湧きますが、雨具界隈では、合羽と傘が2強であることを考えると、あながち、間違っていないのかもしれません。

 

トレードオンを挙げ出す

最後に、トレードオフとなっている2つの軸について、どちらも得ることができる方法を考えます。

 

手元が自由でかつオシャレなものを考えれば良いのです。

ちなみに、図は4象限にしていますが、必ずしも4象限で挙げ出そう!と言うものではございません。ただ、それくらいの意気込みで複数意見を出してみることをお勧めします。

 

【トレードオン】

  1. オシャレで普段使いできるアウターのような合羽の作成
  2. 肩掛けの傘袋の作成

項番1のイメージ

もう世の中にありますね。

shop.adidas.jp

項番2のイメージ

刀のようにかつぐ、差すができれば、一つの傘の進化ではと思いました。腰に差しているとそれはそれで公共の場では邪魔になりそうですが、、、、

www.touken-world.jp

 

使い所 

傘の例でここまで説明してきましたが、使いどころは以下のような場面と思っております。

二項対立する論点が出てきた場合

何かを成し遂げるために、何かが制約となる場合

すなわち、トレードオフに直面した時です。

 

トレードオフを超えて両方を得る思考法のため、ある意味当たり前なのですが、ここで大事なのは、トレードオフを理由に思考を止めないことです。

超えられる壁だと思って取り組むと不思議と何か出てきます。

 

トレードオフだからと思考停止に陥らないこと!

これを肝に銘じておきましょう。

 

まとめ

この記事では、トレードオン思考について紹介しました。

トレードオフの関係を俯瞰して、両方の利を得ることができる思考法となっています。

 

日々の業務でお役に立てば幸いです!

 

では!

【プロジェクトマネジメント】プロジェクトマネジメントする際に忘れてはいけない観点としての知識エリアとプロセス

先日、そもそもプロジェクトとは?というお話をしました。

 

 

www.yoshiyoshiya.com

 

 

今回はプロジェクトマネジメントをしなければ!となった方に向けて、

プロジェクトマネジメントの全体感を捉えていただけるようにマネジメントする際の観点を紹介します。

また、その観点に基づいて、何をすれば良いのか?に踏み込んでいきます。

 

私は、IPAのプロジェクトマネージャを取得してますが、PMPは取得してません。

そのため、紹介する事例がITのシステム開発寄りの記載になります。ご了承ください。

 

f:id:yoshiya_na:20200506173052j:plain

 

 

PMの10の知識エリア

マネジメントする際の観点は、抜け漏れが無いようにPMBOKに従いましょう。そのため、以下の10の知識エリアに従ってプロジェクトをマネジメントしていきます。

  1. 統合
    プロジェクト、フェーズをどのように進めるかを定義
  2. スコープ
    作業範囲、成果物を定義
  3. スケジュール
    納期管理
  4. コスト
    承認予算
  5. 品質
    成果物、プロジェクトの品質
  6. 資源
    人的資源、物的資源の管理
  7. コミュニケーション
    会議体、コミュニケーション方法
  8. リスク
    リスクの特定、分析、対応、監視
  9. 調達
    契約締結、ベンダー管理
  10. ステークホルダー
    ステークホルダーの関与度、管理

f:id:yoshiya_na:20200506174903j:plain

ご自身がプロジェクトマネジメントをすることになった際には、上記の観点が全て考慮できているかを考える必要があります。

PMのプロセス

プロセスについては、以下の5つのプロセスで構成されます。ちなみに、PMBOKでは、知識エリアを縦軸とプロセスを横軸にとって、それぞれの成果物やタスクのイメージがマトリクスになっています。(後述)

  1. 立ち上げプロセス群
    各フェーズでステークホルダーを特定
    例えば、開始時には必要なスキルセットの特定
  2. 計画プロセス群
    各ステークホルダーの要求事項をもとに、
    各フェーズを進める上で必要な実行計画書を作成
  3. 実行プロセス群
    その実行計画書に基づき成果物を生成する作業
    その際に発生した課題への対処
  4. 監視コントロールプロセス群
    プロジェクト状況の定期的な評価
    計画と現実のGAPへの対処検討
  5. 終結プロセス群
    クライアントへの成果物の納品及びその承認
    次フェーズのための成果物作成

 

大事なことは、以下のプロセスを各フェーズで実施できるように準備しておくこと。この立ち上げ、計画、実行、監視、終結がフェーズ毎に繰り返し必要になることを理解してそもそもの計画に入れておくことです。

 

ちなみに、知識エリアとプロセスを軸にして、成果物、タスクが以下のように定義されています。

f:id:yoshiya_na:20200524151248p:plain

 

おそらく、この表を見た方は、プロセスが計画と監視に偏っている!ということに気づかれたと思います。

そのため、先ほど大事なことは事前準備だと言いましたが、さらに端的に言うならば、次フェーズにおいて、各知識エリアをどのようにマネジメントするかの計画ができているか?また、それを監視する仕組みが構築できているか?の2つに重要なポイントを集約することができます。

 

例えばですが、システム開発においては、基本設計時に設計書の品質をどのように管理するか?レビュー指摘の数や質を設計書単位で確認する。ベンダー毎に確認する等々のマネジメント方法を考えておきます。その上で、設計書の本数がトラッキングできるか?レビュー指摘の数や内容がトラッキングできるか?を詰めていくことになります。

 

トラッキングについては、ベンダーに対して、指摘の分類を提示しておくことでその内容を把握できるようにすると言った準備が重要になります。

要件の矛盾、不十分と言った分類と、設計自体の不備、あるいは、記載の分かりやすさ、誤字脱字、レベル感の違うものを一緒くたにすると、原因分析、対処の検討がうまくできません。

そのため、定期的に上記をレポーティングさせるようにテンプレートを作成しておく、報告の時間を設けておくことが重要です。

 

知識エリアから考えるマネジメント観点の詳細化

大枠の考え方がわかったところ、一つ一つの観点をさらに詳細化していきましょう。それぞれの観点が漏れていないかご自身のプロジェクトに当てはめて考えてみることが重要です。

 

統合

  • プロジェクトにおけるフェーズ定義が決まっているか?
  • 各フェーズのクライテリアゲートが決まっているか?(何をすると、フェーズ完了と言えるか?)
  • 変更管理(スケジュール、コスト、スコープ等々)のプロセスが決まっているか?

スコープ

  • 各フェーズの作業範囲が決まっているか?
  • 各フェーズで作成する成果物が決まっているか?
  • 関係チーム、ステークホルダーとの作業分担の境界線が明確になっているか?

スケジュール

  • 各フェーズの期間が決まっているか?
  • 各フェーズのマイルストーン(プロジェクト上の重要な会議や、イベント)が決まっているか?
  • 各成果物を作成可能な期間が決まっているか?
  • 納期(完成)に向けての作業順序が決まっているか?
  • スケジュールの変更要望が収集できるか?

コスト

  • 使える予算が明確になっているか?
  • 必要な予算が明確になっているか?
  • 使える予算が承認されているか?
  • 予算の使い道毎に、必要な予算が明確になっているか?
  • 消費コストが収集できるか?

品質

  • 成果物に求められる品質が定義されているか?
  • 品質を測る情報が収集できるか?

資源

  • 人的資源の総量が把握できているか?
  • 必要な物的資源が把握できているか?
  • 既に利用可能な資源が把握できているか?

コミュニケーション

  • 必要な会議体が設定できているか?
  • 必要なチーム間のコミュニケーションパスができているか?
  • 全体の状況把握、チーム内の状況把握、ラインの状況把握と規模毎の状況把握の仕組みが構築できているか?
  • 各種決定事項に対する承認者及びその権限が明確になっているか?(変更管理を承認できるのは誰か?成果物についてOKと言えるのは誰か?フェーズ完了にOKと言えるのは誰か?)

リスク

  • リスクを収集する仕組みが構築できているか?(要員の病欠、進捗の遅延、品質の低下、外部要因の把握、例えば今だとコロナによる在宅勤務)
  • リスクの影響度、発生確率が計測できるか?
  • リスクに対して対策を立てられているか?
  • 適切なメンバーで対策できているか?(場当たり的な対策でなく、プロジェクト全体への影響を鑑みた対策にすること)

調達

  • 必要なベンダースキルと人数が明確になっているか?
  • 契約体系、成果物、品質、期間等が明確になっているか?(請負、派遣、オンサイト、オフサイト等々)
  • 契約サイクルが明確になっているか?
  • 契約時の承認プロセス、承認者が明確になっているか?

ステークホルダー

  • ステークホルダーが明確になっているか?
  • ステークホルダー毎のタスクが明確になっているか?
  • 各フェーズ完了の承認者が明確になっているか?(予算承認を伴う立ち上げや、設計の完了、あるいは、プロジェクトの完了) 

 

ここまで、私の普段の仕事から思いつくものを羅列しています。今後も定期的に見直して行きますので、参考にしてください。

まとめ

この記事では、プロジェクトマネジメントの全体感を捉えていただけるようにマネジメントする際の観点を紹介してきました。

私は、PMを生業としていますが、改めて書き出してみると色々なことをしているなあと思いまました。(アウトプットって重要ですね)

 

ただ、個人的には、プロジェクトを進めるのはもちろんプロジェクトメンバーであり、プロマネでは無いと思っています。

PMはプロジェクトに必要な色々な仕組み作り、調整を行い、監視して改善するという裏方だと思っています。プロジェクトメンバーが働きやすいような環境作りが一番の仕事です!

 

今後、さらに、一つ一つの知識エリアを細かく説明して行きます。

 

では!

【ビジネスハック】水平思考で新たなアイデアを捻り出そう

 新しいアイデア出してますか?

 

仕事をしていると、新しいアイデアを求められる場面は多々あると思います。

商品開発はもちろんですが、現場で何らかの改善や施策出しをすることもあるでしょう。

 

そういった場面で、「う〜ん、思いつかないなあ、どうしたもんか。。。」となることがあると思います。

そんな場面に適した思考法として水平思考があります。

この記事では、水平思考とはどんな思考法か、また、どういった使い方をするか例を用いて紹介します。

 

これを読み終わる頃には、意見出しができるビジネスマンになることでしょう。 

 

f:id:yoshiya_na:20160923180808j:plain 

ZeZe SEOによるPixabayからの画像

(ちなみに、画像はタイトルに合わせて水平線です。) 

 

水平思考とは

水平思考とは、論点に対して通常のセオリーに要素を分解して、その要素を水平に移動して、これまでのセオリーとは異なる観点で着想する思考法です。

 

f:id:yoshiya_na:20200517164405p:plain

この図でイメージを持っていいただければと思います。

ある論点に対して、その通常のセオリーを要素分解して、それぞれの要素を水平移動して観点を変えてみる。

新しい観点を用いて、これまでのセオリーには無かった新たなアイデアを出すことができます。

 

水平思考の方法

水平思考については、以下の順番で進めます。一つ一つ解説していきます。

  1. 論点の設定
  2. セオリーの洗い出し
  3. 水平移動
  4. アイデア出し

 

論点の設定

まずは、いつも通り論点の設定です。

これは、以前の記事で書いたディベート思考の時と一緒です。

 

www.yoshiyoshiya.com

 

改めて、今何を解決しなければいけないのか?何が課題なのかを明確にします。

その課題を論点として設定します。

 

例えば、今回は、傘を題材に水平思考を展開していきたいと思います。

 

論点を傘に変わる新しい商品の開発とします。

 

セオリーの洗い出し

その論点に対して、通常のセオリーを要素として並べていきます。

通常のセオリーと言っているのは、一般的な性質や使い方を指しています。

 

傘の例で言うと、以下のような性質や使い方を要素として並べることができます。

  • たたむもの。
  • 持ち運ぶもの。
  • 手に持って使うもの。
  • 雨に濡れないようにするもの。
  • 視界を遮るもの。(透明なものもありますね。)

 

f:id:yoshiya_na:20200517172019j:plain

Pete LinforthによるPixabayからの画像

 

要素を並べるにあたっては、思いついた順に並べるでも良いです。

要素が出ない場合、例えば、利用する場面を想像しながら時系列に並べてみても良いです。

 

水平移動

次に既存のセオリーを打ち破るように、そのセオリーを水平に移動させて、新しい観点を出していきます。

水平移動させるとは打ち消すように考えることを指します。

その観点を考えずにすむように横に横に移動させるイメージです。

 

例えば、先ほどのセオリーを水平に移動して観点を出していきます。

  • たたむもの。
    → たたまない傘ができないだろうか?
  • 持ち運ぶもの。
    →持ち運ばない傘は実現できないだろうか?
  • 手に持って使うもの。
    →手に持たずに使えないだろうか?
  • 雨に濡れないようにするもの。
    →雨に濡れても良いようにならないものか?
  • 視界を遮るもの。(透明なものもありますね。)
    →視界を遮らずに使えないものか?

 

アイデア出し

最後に、それぞれの観点でアイデアを出していくことで、これまでのセオリーを打ち破るアイデアを出すことができます。

  • たたむもの。
    → たたまない傘ができないだろうか?
    →たたまないけど、邪魔にならないサイズに縮小した傘。
    →開いていることで、孔雀のようなファッションを実現し、そもそも、たたむという状態にしない傘
  • 持ち運ぶもの。
    →持ち運ばない傘は実現できないだろうか?
    →シェアサイクルのように傘を共有。マンションの共有傘をシェアするような仕組みが構築できないか。
    →持ち運ぶのではなく着るものにしてしまう。(これはカッパですね。)
    →一緒に移動できるようにタイヤをつける。(これは車ですね。)
     あるいは、自分の一歩後ろを傘をさしながらついて来てくれるロボットですね。
    →相合い傘のマッチングの実現。傘に入れて上げる代わりに、100円、200円もらえるようなオンラインサービスどうでしょう?セキュリティ上の問題がありそうですね。
  • 手に持って使うもの。
    →手に持たずに使えないだろうか?
    →着る。
    →被る。

    www.asahi.com

  • 雨に濡れないようにするもの。
    →雨に濡れても良いようにならないものか?

    →移動する先々に乾かす仕組みを設置する。
    →すぐにお風呂に入れるように、お風呂を遠隔で沸かしておく。

  • 視界を遮るもの。(透明なものもありますね。)
    →視界を遮らずに使えないものか?
    →一部透明な傘が既にありますね。
    →今後は、ARやVRで傘の先の道を表示しても良いですね。夢のような話です。

途中から、意見出しがおかしな方向にいってますが、必ずしも、すべての観点で意見を出さなければならないものではございません。

ただ、無理やり捻り出した先に面白いものが出るかもしれませんので、チャレンジはしてみて良いと思います。

  

使い所

繰り返しになりますが、商品開発はもちろんですが、現場で何らかの改善や施策出しが必要な場面で利用できます。

新しいアイデアを求められる場面で有効活用できる思考法になっています。

 

普段から面白い意見を出せる人は、このような思考法が自然と身についているのだと思います。

一方で、意見出しが苦手だなあと言う人はここで学んだことを日々の業務の中で訓練すれば意見出しできるようになると思います。

 

大事なのはやってみること。

やってみて、その思考法を習慣にしてしまえば良いのです!

 

まとめ

この記事では、新しいアイデアを出すための思考法である水平思考について解説しました。

 

水平思考を用いることで、考えるきっかけを観点として並べることができます。

 

アイデアマンになっていくために、日々思考法を使っていきましょう!

 

では!

【プロジェクトマネジメント】そもそもプロジェクトとは

日々プロジェクトを進めてますか?

プロジェクト という単語をよく耳にします。

 

改めて、プロジェクトとは何かを学ぶことで、プロジェクトというものを理解して、うまく付き合っていきましょう。

 

そのため、この記事では、「プロジェクトとは? 」、「プロジェクトの特性とは?」、「一般的な制約事項は?」、「プロジェクトの成功とは?」を取り扱います。 

f:id:yoshiya_na:20200506173052j:plain

 

プロジェクトの定義

PMBOK Guideでは「独自のプロダクト、サービス、所産を創造するために実施する、有期性のある業務」と定義されています。

いくつか難しい単語で説明されているので調べましょう。

 

独自とは、「他と違って、そのものだけにあること。また、そのさま。(※)

所産とは、「ある事の結果として生み出されたもの。作り出したもの。(※)

創造とは、「新しいものを初めてつくり出すこと。(※)

有期とは、「期間・期限の定められていること。(※)

(※)goo辞書より。

 

すなわち、プロジェクトとは「他には存在しないプロダクト、サービス、成果を、新しく作り出すための期間、期限の定められた業務」となります。

f:id:yoshiya_na:20200506174903j:plain



 

プロジェクトの特性

先ほどの定義に出てきた独自性、有期性以外にも、ルーチンの業務と比較した時に、プロジェクトには以下のような特徴が存在します。

変化

プロジェクトの実施前後で、組織、業務に対して、何らかの変化を起こす。

プロジェクトが成功した場合には、そのプロジェクトで作成された成果に基づき何らかの利益を得ることになります。

プロジェクトの成果にもよりますが、例えば、業務効率が向上する、組織構造が変わる、業務内容が変わる、新しい製品の作成が始まる等々何らかの変化があることが想定されます。

 

逆にプロジェクトが失敗した場合には、何らかの損失が発生します。

人、もの、金、および、プロジェクトにかけた期間が失われ、その他の投資機会が消失します。結果的に、組織や業務を縮小せざるを得ない状況にあるかもしれません。

 

プロジェクトが成功しても、失敗しても、何らかの変化を起こします。

 

機能横断

プロジェクトは複数の部署を跨ぎ組織横断的に実行される。

ある特定の部署のみでプロジェクトが実行されることがあるかもしれませんが、多くのプロジェクトでは複数の部署を巻き込みます。

独自性のあるプロダクトや、サービス、成果を生むためには、多くの部署を巻き込み、組織のあり方や定常業務のやり方を変えて実現しなければならないことがあります。

特に、プロジェクトに対する要件、要望が複雑化、高度化すればするほど、この傾向にあると思います。

 

リスク

プロジェクトは常にリスクに晒される。

プロジェクトはどれだけうまく計画を立てても、想定外の出来事が発生します。

外部要因として、会社の経済状況が変わり、予算や要員を減らさざるを得ない状況になるかもしれません。当局からの指摘により、当初よりもプロジェクトとして作成する成果物を増やさないといけない状況になるかもしれません。

内部要因として、プロジェクトの運営方法が悪かったがために、スケジュールが遅延するかもしれません。体制が適切で無いために、成果物の品質に問題が発生するかもしれません。

プロジェクトにおいてはリスクを事前に把握し、対策することが重要になります。

(※)Risk Managementは別途記事を予定。

f:id:yoshiya_na:20200506175216p:plain
 

プロジェクトの制約事項 

そもそも制約とは何かから考えます。

制約とは、「ある条件や枠をもうけて、自由な活動や物事の成立をおさえつけること。また、その条件や枠。(※)

(※)goo辞書より。

 

つまり、プロジェクトを進める上で、満たさなければならない条件を指します。

 一般的には、スコープ、コスト、スケジュールがプロジェクトの制約となります。

スコープ

プロジェクトで実施しなければいけない範囲を指します。

例えば、プロジェクトがトップダウンで発生した場合には、経営からここまでやって欲しいという要望が存在することがあります。

その要望を満たすことができない場合には、プロジェクトのスコープが不足することになります。

経営層のような重要なステークホルダーからの要望を取り込まないと、プロジェクト開始後、そのスコープが膨らむことになります。

 

コスト

プロジェクトを実現するための予算は有限である。

これは想像に易いかもしれません。何かプロジェクトを為す上で、予算が無限にあることは無いです。必ず有限です。そのコスト制約の中でプロジェクトを成功させることに意味があります。

プロジェクトも投資の一つです。投資対効果が無いプロジェクトは実施すべきは無いです。

 

スケジュール

プロジェクトには必ず有期性がある。

独自の商品や、サービス、成果はある期間内に提供されなければその価値を失うかもしれません。

商品やサービスは時代遅れになると売れません。あるいは、別の会社に先を越された場合には、もうそのマーケットでは優位に立つことはできないかもしれません。

ある期間までにプロジェクトを成功させることが重要です。

 

 

f:id:yoshiya_na:20200506175644p:plain

プロジェクト成功の定義

では、そもそも、プロジェクトの成功が何かを考えていきます。

プロジェクトの成功は、実際には、各プロジェクトに依存します。

 

一方で、どういった観点で成功を定義すべきかは考えることができます。

以下の3つの観点で定義することが重要です。

  • このプロジェクトの成功とはどのようなことか

  • どのような要因が成功に影響するか

  • 成功はどのように測定されるか

 

このプロジェクトの成功とはどのようなことか

プロジェクトが成功した際に、どのようなメリットが得られるかを整理することが重要です。

このプロジェクトが成功すれば、xxxというサービスが実現し15億円の売り上げが出るはずだ!

このプロジェクトが成功すれば、xxxという業務が改善され、3億円のコストカットが可能なはずだ!

これらの例の場合、xxxサービスの実現や、xxx業務プロセスの改善、開発が完了すれば成功と言えます。

 

どのような要因が成功に影響するか

xxxというサービスや業務がどのような構成要素で成り立っているかを分解します。

xxxサービスの内、初期登録による売り上げ、月次の定期的なサービス利用による売り上げ、関連サービスによる売り上げ等、それぞれの要素を分解します。

あるいは、xxxサービスを運用するのに必要なシステムA、システムB、システムCそれぞれが稼働できるように開発が完了していることのように分解します。

 

成功はどのように測定されるか

成功したかどうかを測定する方法を定義することも必要です。

売り上げの場合には、その売り上げを各要因毎に拾う方法を定義する必要があります。

業務改善の場合には、業務にかかっている時間を算出、測定する方法を定義する必要があります。測定できなければ成功か否か判断がつきません。

 

f:id:yoshiya_na:20170207014025j:plain

まとめ

ここまで、「プロジェクトとは? 」、「プロジェクトの特性とは?」、「一般的な制約事項は?」、「プロジェクトの成功とは?」を取り扱いました。

 

プロジェクトの特性を理解して、プロジェクトを進めることは重要です。

 

いつだって基本、基礎が大事。応用はその基礎の土台の上!ということで、プロジェクトマネジメント、プロジェクト運営をするにも、まずは、プロジェクトが何ものかを押さえましょう!

 

皆様のプロジェクトが成功することをお祈りいたします!

では!

【ビジネスハック】ディベート思考で考えや意見を深めよう

「君は何も考えていないな。。。」って言われたら悲しいですね。

もしかすると、理由や根拠の説明がうまくできないからそう言われているのかもしれません。

あるいは、思考の深さが浅いのかもしれません。

 

意思決定をする際に、その決定理由を説明できるように意見を深めることは重要です。

ビジネスにおいては、その理由が説明できない限り、誰かを納得させて物事を進められないことが多々あります。

そのためにも、考えや意見を深めて、その意見の根拠を他者に向けて説明できるようにしましょう。

 

今回はそのための思考法として、ディベート思考を紹介します。

 

f:id:yoshiya_na:20200503201455j:plain

 

 

ディベート思考とは

論点に対する仮説を「賛成派だったら」、「反対派だったら」それぞれどんな意見を出してくるかを想定して、意見出しを行い、さらにその意見に対してまた「賛成派だったら」、「反対派だったら」と意見を繰り返し出すことで意見や考えを深める思考法です。

 

f:id:yoshiya_na:20200503202154p:plain

ちなみに、ディベートとは、特定の論題に対して賛成派と反対派に分かれて討議することです。アメリカでは授業にもなっているらしいですが、日本だと道徳の時間に触れたことがある程度かもしれません。

 

ディベート思考の方法

ディベート思考については、以下の順番で進めます。一つ一つ解説していきます。

  1. 論点の設定
  2. 仮説の設定
  3. 賛成派、反対派からの意見出し
  4. その意見に対しての賛成派、反対派からの意見出し
  5. さらにその意見に対しての賛成派、反対派からの意見出し
  6. 必要に応じて仮説を変更する

論点の設定

何をするにもまずは課題設定が必須です。

ある意味当たり前ですが、今何を解決しなければいけないのか?何が課題なのかを明確にします。

その課題を論点として設定します。

 

日常生活においても、ビジネスにおいても色々な意思決定があります。

  • 雨が降るかもしれない。傘を持つか、持たないか?
  • お腹がすいた。パンにするか、ごはんにするか? 
  • コスト高騰している現状を踏まえて、どのようにチームの生産性を向上させるか?
  • コスト高騰している現状を踏まえて、どのようにコストカットを実現するか?

どんな課題に対して、どんな課題を設定するか。

どんな思考であれ、ここがしっかり考えられていない限り無意味になります。

何が課題なの?何が論点なの?には答えられるように準備します。

 

仮説の設定

論点が整理できたら早速仮説を設定します。

ここは今直感的に思ったことを設定するで構いません。

この後、意見の深堀をしていく中で、意見を切り替えても良いです。

論点に対する回答を一つ仮説として出します。

 

f:id:yoshiya_na:20200503204540j:plain

 

例えばですが、以下の論点に対して仮説を設定してみます。

論点:「雨が降るかもしれない。傘を持つか、持たないか?」

仮説:「傘を持つ!」

 

今思っている意見を出すだけでこのステップはOKです。

 

賛成派、反対派からの意見出し

では、ここからディベート思考の重要なポイントです。

先ほどの傘を持つか、持たないかの論点について賛成と反対について整理します。

論点:「雨が降るかもしれない。傘を持つか、持たないか?」

賛成:「傘を持つ!」

反対:「傘を持たない!」

 

つもり、現在の仮説は賛成派に属していることになります。

これに対して、自分が反対派だったら、どんな意見を出して反対するかを並べてみます。

  1. 雨が降る確率は、50%であり降らない可能性がある。
  2. 傘を持ち歩く場合、荷物が増え片手が塞がる。電車で携帯をいじることも、あの娘と手を繋ぐこともできなくなる。
  3. 傘を持ち歩く場合、どこかに忘れるリスクが発生する。実際に、自分は、飲み屋に持っていくとだいたい忘れる。

 

このように現状の仮説に対する反対派になりきって、反対意見をたくさん並べます。

 

その意見に対しての賛成派、反対派からの意見出し

もちろんディベートという言葉の通り、ここからまた別の派閥になり意見を出して議論をぶつけます

先ほど、反対派として意見を出したのであれば、賛成派として追加の意見を出します。

賛成派として意見を出していたら、反対派として意見を出します。

 

先ほどの項番1〜3に対して、意見を出します。

  1. 雨が降る確率は、50%であり降らない可能性がある。
    → 逆にいうと、50%の確率で濡れることになる。そもそも、濡れたくないのであれば、確率は問題とならない。
  2. 傘を持ち歩く場合、荷物が増え片手が塞がる。電車で携帯をいじることも、あの娘と手を繋ぐこともできなくなる。
    →折りたたみを持って、リュックでも背負ってください。手が空きますよ。
  3. 傘を持ち歩く場合、どこかに忘れるリスクが発生する。実際に、自分は、飲み屋に持っていくとだいたい忘れる。
    →折りたたみであれば、かばんに入れられるため、忘れることはないでしょう。

 

良い感じになってきました。

ただ、「傘を持つ」から、「どんな降水確率であれ濡れくないので折りたたみ傘を持つ」に意見が進化しています。

ただ、ディベート思考はまだまだ自分の意見を深められます。

 

さらにその意見に対しての賛成派、反対派からの意見出し

さらに逆の派閥からの意見出しを行います。 

  • 雨が降る確率は、50%であり降らない可能性がある。
    → 逆にいうと、50%の確率で濡れることになる。そもそも、濡れたくないのであれば、確率は問題とならない。
    →濡れたくないということであれば、傘を持つだけが対策ではない。雨が降った際にタクシーに乗るでも良いはずだ!
  • 傘を持ち歩く場合、荷物が増え片手が塞がる。電車で携帯をいじることも、あの娘と手を繋ぐこともできなくなる。
    →折りたたみを持って、リュックでも背負ってください。手が空きますよ。
    →残念ながらリュックや、肩掛けのカバンを持っていません。
  • 傘を持ち歩く場合、どこかに忘れるリスクが発生する。実際に、自分は、飲み屋に持っていくとだいたい忘れる。
    →折りたたみであれば、かばんに入れられるため、忘れることはないでしょう。
    →例えば、店から店に移動する間に傘をさしたとしましょう。雨が降った後のびしょびしょの折りたたみ傘を果たして鞄に入れられますか?

 

さらに意見が深まってきました。

ディベート思考の場合、ここからまだ反対、賛成の意見を繰り返し繰り返し出すことで、まだまだ意見を深めることができます。

 

自分の立場を切り替えるだけで、意見を深めていける大変お手軽な思考法です。

 

必要に応じて仮説を変更する

意見を深めた後で、再度論点と仮説に戻ります。

論点:「雨が降るかもしれない。傘を持つか、持たないか?」

仮説:「傘を持つ!」

 

ここまで出てきた意見から、仮説を検証します。

傘を本当に持つ必要があるのか?から疑いたくなります。

仮説を変えても良いのです。

 

新しい仮説:「もう雨が降ったらタクシーに乗るので、傘はもたない!」

理由:「なぜなら、傘は飲み屋に持っていくと失くすから!」

 

仮説を変えても、理由が説明できています。

この例が良いかはさておき、説明がしっかり説明できるレベルで意見を深堀できています。

これがディベート思考です。

 

使い所

傘を持つか持たないかという例でここまで進めてきましたが、どんな場面でも使えます

自分の意見を喋り出す前に、あるいは、何か資料を作成する前にこの思考法で意見を深めてください。

 

意思決定は至るところに転がっています。

今日何着よう、今日何食べよう、すべて意思決定です。

この思考法を練習できる機会はたくさんありますのでやってみてください。

 

 

まとめ

この記事では、ディベート思考について紹介しました。

考え、意見を深めるための思考法で、手軽に利用することができます。

 

自分の立場を反対派や、賛成派に変更して、視点を変えることで、総合的な意見を出すことができます。

 

日々ディベート思考ができるようになれば、「お!しっかり考えてるね!」と言われるようになるはずです!

日々成長!

 

では!

【ライフハック】やりたいことをやるための強制スケジュール表を作成して連休をより良いものにしよう!

2020年のゴールデンウィークが始まりました。

おじいちゃん、おばあちゃんの家に家族みんなで行くことや、久しぶりの実家に帰省することが、例年のゴールデンウィークだったかと思います。

 

一方、今年はコロナでStay home状態のため、ゴロゴロしたり、あつ森したり、オンライン飲み会で昼から浴びるように飲んでいることでしょう!

それも良い!

 

しかし、

さらに、より良い連休にしてみませんか?

 

そこで今回の記事では、新しいことにチャレンジするための仕組み「強制スケジュール表」を紹介していきます。

f:id:yoshiya_na:20160210110313j:plain

 

強制スケジュール表とは

強制スケジュール表とは、あなたの人生をより豊かにする仕組みです。

この仕組みは大変簡単です。

やってみたかったこと、チャレンジしてみたかったこと、ルーチンを明日のスケジュールに入れるだけです。

f:id:yoshiya_na:20200429144003p:plain

本来はGoogleカレンダーのようなサービスを利用しているのですが、縦長で見づらかったためEXCELで二段で表示しております。

色付きの予定を見てください。これらが私のやってみたかったことの一部をスケジュールに詰め込んでいるものです。

運動 … リモートワークが続き背中が痛いため、家でできる運動をしたい!

ブログ作成 … しばらく、放置していたブログをそろそろ更新したい!

動画作成 … 流行りの動画作成をしてみよう!

読書 …  インプットも大事!勉強しよう!

投資 … コロナで経済が停滞している今こそ投資をしたい!

日記 … いまさらだけど日記を始めてみよう!

 

このように、自分のやりたいことをスケジュールに入れて、明日はそれに従って行動すれば良いのです!明日の自分にやりたいことをやるように約束するようなものです!

 

いつかやりたいと思っていることは普段の生活では忘れさられてしまいます。

コロコロしたり、しょうもないテレビやyoutubeを見ていたら、いつの間に夜になっていた!一日が終わっていた!となることはよくあるでしょう。

しかし、スケジュールに入れるだけで、不思議とできるようになります。

昨日の自分との約束しているので、守らざるをえません。 

下準備:やりたいことリスト

強制スケジュール表を作成する上で、大事な準備があります。

やりたいことリストの作成です。

強制スケジュール表に記載する「やってみたかったこと、チャレンジしてみたかったこと」を書き出してリストにします。

 

f:id:yoshiya_na:20200429145305j:plain

 

普段から、面白そうなことをメモする習慣をオススメします。

まずはその第一歩として、今書き出してみましょう。

書き出す先は、Evernoteや、ToDo List、メモ帳のアプリでも、実物のノートや手帳でも良いです。

 

いきなり、やりたいことを書けと言われても難しいかもしれませんので、いくつか観点を並べておきます。

 

  • 仕事や学校が長期の休みになった時にやりたいと思っていたことは何でしょう?
  • 家族や友人と何をしている時が楽しいでしょうか?あるいは、何を一緒にしてみたいでしょうか?
  • 自分が小さい頃に夢中になったものは何でしょう?
  • 将来どんな生活を送りたいですか?そのために、何かを始めるとしたら何を始めますか?

 

個人的には、常に携帯しているスマホでいつでも更新ができるEvernoteをオススメします。

パソコンとも常に共有されるため、使い勝手が良いです。

 

下準備:強制スケジューリング 

やりたいことリストができたら後はスケジュール表に入れるだけです。

f:id:yoshiya_na:20200429154739p:plain

まず最初に、絶対に必要なルーチンの時間を埋めます。

朝ごはん、昼ごはん、夜ごはんをだいたいの時間で良いので埋めましょう。

細かく書き出すとキリが無く、手間も大きくなるので、お皿洗いの時間や準備の時間を含めてざっくり埋めます。

後は、お風呂や洗濯、掃除といった日常的に必要な家事を入れて、睡眠時間を埋めると残りの時間が見えてきます。

 

f:id:yoshiya_na:20200429143907p:plain

そして、後は、やりたいことを適当な時間で埋めていきます。

やりたい度に応じた時間を設定するようにします。私の場合は、ブログ作成、動画作成に時間をかけるようにしています。

また、同じ作業ばかりだと集中力が持たないため、5、6種類のやりたいことを入れるようにしています。

何種類入れるかはそれぞれの性格に合わせて適切な数を見つけていってください。

 

ちなみにツールとしては、Evernoteと同様、スマホからもパソコンからも入力が可能という理由で、Googleカレンダーが個人的にはオススメです。

 

当日の心構え

そもそも、やりたいことをどう始めれば、、、!という方のために最後にお伝えしたいのは心構えです。

自分のできる細かさまで作業を分解してみましょう。

f:id:yoshiya_na:20200429153025j:plain

例えばですが、投資してみたい!と思ったとしましょう。

投資したことなんか無い!ということであれば、まずは、投資の種類を調べてみる!から始めれば良いのです!株、為替、土地等々、そもそも投資先の種類に何があるかを調べるだけであれば、誰でもできるはずです。

 

また、投資を始めるのに必要なものがあるか?を調べてみることも良いでしょう。

株や投資信託を始めるには証券口座が必要なのか!と分かれば、次に、各社の手数料や特徴を調べることができます。

 

やりたいことを実現するために、やらないといけないことが何かを調べてみましょう!

難しく考えずに、まずはできることをやってみる。

始めてみたら、新しい発見や、次に何をすれば良いか見えてくることがあります。

 

とりあえず、始めてみる!くらいの心構えで良いでしょう。

 

まとめ

新しいことにチャレンジするための仕組みとして強制スケジュール表について紹介しました。

コロナで家に引きこもっている今こそ、チャレンジしてみたかったことをやってみましょう!

(※ 家でできることに限る)

 

とりあえず、始めてみるの心構えで、一歩でも前進しましょう。0より1!

 

みなさんの人生が豊かになりますように!

 

では。