カテゴリ

Powered by Six Apart

PMstyle 2021年1月~4月ZOOM公開セミナー(★:開催決定)

Twitterアカウント(PMstyle)

PMstyle facebook

コンセプト力 Feed

2020年7月 2日 (木)

【マネジメントスタイル:雑談2】コンセプチュアル思考の各軸を極めるための本

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

PMstyleでは、「コンセプチュアル思考」という思考法を提唱しています。

4532320623
好川 哲人「コンセプチュアル思考」、 日本経済新聞出版社(2017)

https://www.amazon.co.jp/exec/obidos/ASIN/4532320623/opc-22/ref=nosim

コンセプチュアル思考は5つの軸の軸の行き来で実践します。

大局/分析
抽象/具象
直観/論理
主観/客観
長期/短期

の5軸です。大局や長期は経営者やマネジャーのスキルとしては古くから重要性が指摘されていたものですが、この5年くらいで他の軸についても急速に認知されるようになってきたように感じています。

そこで、この記事では、抽象/具象、直観/論理、主観/客観の3軸に関する書籍を簡単にコメントをつけながら紹介してみたいと思います。

続きを読む »

2020年3月 5日 (木)

【PMstyleコラム】3,000人が実施しているPMstyleコンセプチュアルスキル診断

PMstyleプロデューサーの好川哲人です。

PMstyleコンセプチュアルスキル診断について共有しておきたことがあり、コラムを書きました。
 
 
◆コンセプチュアルスキル診断の概要
 

Skill_sindan

PMstyleコンセプチュアルスキル診断は、PMstyleで2015年から正式に運用を始めた診断で、PMstyleがコンセプチュアルスキルの提唱者である、ロバート・カッツのモデルをベースに発展させたコンセプチュアルスキルの診断を行うシステムです。2019年までで3000人強の方に実施して頂いています。
 
この診断では、25問の質問に答えることにより、コンセプチュアルスキルを思考軸のバランス行動の2つの視点から評価し、診断結果を表示します。思考軸としては、コンセプチュアルスキルに不可欠だと考えている
 
・抽象的/具象的 のバランス
・主観的/客観的 のバランス
・直観的/論理的 のバランス
・大局的/分析的 のバランス
・長期的/短期的 のバランス
 
の5つで、これらのバランスを評価し、診断しています。また、行動はコンセプチュアルスキルの高低によって違いが出てくる行動特性を評価するもので、
 
・構想
・計画
・問題解決
・意思決定
・対人
 
の5つの行動に注目して、どれだけコンセプチュアルスキルが高いかを診断しています。これらの2つの視点の評価から、最終的に10点満点のスコアで診断しています。
 
PMstyleコンセプチュアルスキル診断はこちらから実施できます。
 

続きを読む »

2019年10月17日 (木)

【お知らせ】「コンセプチュアル講座探訪」をはじめました

「コンセプチュアル・マネジメント」ブログで、コンセプチュアルスキル講座、コンセプチュアル・マネジメント講座の各セミナーの背景にある問題意識や考え方を紹介する連載

 
「コンセプチュアル講座探訪」
 
を開始しました。
 
受講検討の際の参考にして頂くのはもちろんですが、記事としても読みごたえがあると思いますので、ぜひ、読んでみてください!
 

2017年10月 4日 (水)

【「コンセプチュアル思考」でプロジェクトを動かす】第1回 なぜ、ITプロジェクトは混乱するのか

◆なぜ、ITプロジェクトは混乱するのか

Conceputual_2

次のようなプロジェクトを考えてみよう。

ある通販会社で経営層から「ロイヤルカスタマー戦略のテコ入れによる収益向上」と
う戦略が打ち出された。その実行の一環としてロイヤルカスタマーへの新たな働きかけをする、これまでにはない仕組みの構築を課題としたプロジェクトを実施することになった。

これまではロイヤルカスタマーに対する値引きは行っていたが、即日配送、特別な情報提供などできそうなことはいくらでもある。加えて、これまでには行われていない方法を取ることを前提にすれば、考える範囲はほぼ制約がない。一方でコストは決まっているので、その制約は守らなくてはならない。

このようなプロジェクトにおいて、いきなり、具体的にどのような仕組みを持たせるかを決めようとしても、新しい独自の仕組みを固定的に考えることは非常に難しく、試行錯誤してみなくては決まらない可能性が高い。また、強引に決めてもプロジェクトを進めていくうちに、実現できない、予算が足らないといった問題に直面することが多い。

そもそも、ロイヤルカスタマーの定義は今のままでいいのかといった話にもなってくるだろう。

たとえば、注文の仕組みを変えて、ロイヤルカスタマーになれば他の人に商品を奨めた場合のロイヤリティが入る仕組みを取り入れようとした。ところが、ロイヤルカスタマーがそれなりに満足するにはどういう仕組みにすればよいかは実際にやってみないと分からない部分が多い。仕組みによって、システムの仕様だけではなく、範囲も変わってくるだろう。

このようにシステムとして開発すべき範囲や仕様を明確にした上で、システムを開発するという方法が通用しにくい「ITプロジェクト」が増えている。

にも関わらず、要求仕様を強引に決めようとする。プロジェクトを進めていくうちに、結果として要求仕様は変化し、ステークホルダーの間でプロジェクトの目的に対する共通の認識がなく、また、チームにおいても指針がなく開発を進めていくケースが増えている。

従来のプロジェクトではプロジェクトの目的はシステム目的によってほぼ決まっていたし、システムの要求仕様もプロジェクトの初期で決まっていたので、あえてプロジェクトの目的を意識する必要はなかった。

ところが、問題としているタイプのITプロジェクトでは、プロジェクトの目的とシステムの目的は必ずしも一致しない。つまり、明確なゴールを設定しないままで、プロジェクトを開始することになる。

プロジェクトのゴールが明確になっていない状況でプロジェクトを進めると、プロジェクトは例外なく混乱する。これが、いま、ITプロジェクトが混乱しているもっとも大きな原因である。

続きを読む »