PMstyleプロデュース

◆デザインという言葉の意味

デザインという言葉が市民権を得てきました。デザインという言葉は、典型的なカタカナ英語の一つで、従来、分野によってその意味するところが微妙に異なる言葉でした。

美術工芸品・工業製品などの世界では、形・色・模様など、いわゆる「意匠」という意味でデザインという言葉は使われています。図案という言い方をすることもあります。一般的にもこの意味がもっとも通りがよいのかもしれません。

技術の世界では、機能、方式、構成などの「設計」の意味で使われます。この場合、意匠と比べると、抽象度の高い使い方になります。この世界では、デザインという言葉より、設計という言葉の方が通りがいいようで、設計というと、機能の設計を意味することが多いように思います。

デザインという言葉は、何かを決めること、つまり、意思決定ですが、工夫をめぐらすというニュアンスが強くあるように思います。工業製品で使う意匠という言葉は、意も匠もそういうニュアンスの言葉で、含蓄があります。モノの形を決めるというのは、単に形状を決めているだけではありません。たとえば、カトラリー（洋食器のうちナイフ、フォーク、スプーンなどの金物類）を考えてみるとよく分かります。デザインは形と機能を決めます。そして、形は性能を構成しています。賛否はあるようですが、先割れスプーンなどはその典型だといえるでしょう。

プロジェクトとは特別な業務のイメージですが、商品開発をしている部門や、受注で開発をしている部門など、部門によっては業務の大半をプロジェクトとして行っている組織が増えてきています。

そのような部門においては、部門長や管理職は、業務オペレーションのマネジメント（ＰＭＢＯＫのような現場レベルのプロジェクトマネジメント）とは別に、成果や収益のマネジメントをするためにもう一段上の立場でプロジェクトをマネジメント（管理）する必要があります。彼らがマネジメントしなくてはならないのは、個々のプロジェクトではなく、自部門で実施しているプロジェクト全体です。

プロジェクト全体をマネジメントするには、個々のプロジェクトを適切に現場のプロジェクトマネジャーに権限委譲した上で、全体をコントロールするために必要な情報を収集するとともに、各プロジェクトに配分する経営資源を管理する必要があります。

このような活動を戦略的プロジェクトマネジメントと呼びます。管理者向けのプロジェクトマネジメント講座は、部門長や管理職を対象にした、戦略的プロジェクトマネジメントの講座です。

現在、以下のようなラインナップになっています。

◆リスクの構造

組織のリスクマネジメントに取り組んでいる企業の多くは、プロジェクトのリスクマネジメントの支援をすることを中心的な役割にしています。簡単にいえば、リスク計画のレビューや、リスクチェックリストの提供などです。これは適切なマネジメントなのでしょうか。今回はこの問題を考えてみます。

リスクの構造というのは

根本原因　→　脅威　→　（リスク）　→　損失

という構造になっています。よく使われる漏電による火事の例でいえば

根本原因：漏電
脅威：漏電部分の近くに引火物がある
リスク：引火物が火事を起こす（確率）
損失：火事

という構図でとらえます。

プロジェクトリスクマネジメントでは対応策は、回避、緩和、受容などを取ります。受容はなにもせずに火事が起こってから対応するための準備だけをしておくことです。たとえば、火事が発生したときに消火手順を決めておくといったことです。緩和は火事が起こってもそのダメージが小さくなるように対応することで、たとえば、消火器を準備しておくなどの対応策が考えられます。

ロベルト・ベルガンティ（佐藤 典司監訳、岩谷 昌樹、八重樫 文、立命館大学経営学部DML訳）「デザイン・ドリブン・イノベーション」、同友館（2012）

イノベーション論のバイブルの一冊がやっと翻訳された。ロベルト・ベルガンティのデザイン・ドリブンイノベーションである。

◆技術によるイノベーション

イノベーションブームの中で、技術によるイノベーションの時代は終わった。コンセプトの時代だと盛んに言われるようになっています。そして、イノベーションの対象はビジネスモデルに変わってきたと言われます。今回はこの問題について考えています。

まず、技術によるイノベーションとはなんだったのかについて考えてみましょう。この３０年間くらいを考えて、もっともイノベーションが起こった分野の一つは、情報技術です。僕が仕事を始めたころに、空調がきいた部屋一杯に置かれていたコンピュータが、パソコン一つになり、さらにはネットワークでつながっているわけですので、大変な革新です。

これは技術の進歩によってもたらされたイノベーションです。プロセッサーの高速化、半導体の集積密度の向上、記憶デバイスの大容量化、ファームウェア技術の進化、基本ソフトウエアの進化など、あらゆる分野の技術のイノベーションがもたらした結果です。

このような産業の成長の中で、いわゆるＩＴのハイテク企業では、新技術開発＝イノベーションという構図ができてしまった。そして、その中で技術の競争の方向が変わるときに、イノベーションのジレンマが起こる。そして、新しい土俵で新しいプレイヤーによる技術イノベーションが始まる。これを繰り返してきました。

そして、今、盛んに言われているのは、技術ではイノベーションを起こせないということです。つまり、新しい技術がイノベーションになるという構図は終わったということです。

よく例に挙げられるのはアップルのiPodです。iPodは技術を組み合わせることによって非常に革新性の高い商品を作り上げたと言われています。彼らにとって、技術は自分たちのゴールを実現するための商品を組み立てる道具に過ぎないわけです。

ただし、ゴールの実現にもっとも大きな影響を持つ（広い意味での）ユーザインタフェースについては徹底的にこだわるわけです。ここでいうユーザインタフェースとは、単に画面や（物理的な）ボタンの場所などだけではなく、ユーザが持ったときの感覚や、持ち運びができるかどうかなど広範にわたる、いわゆる「デザイン」です。

Harvard Business Review (ハーバード・ビジネス・レビュー) 2012年09月号
「最強チームをつくる」

今月のハーバードビジネスレビューはチームマネジメントの特集です。過去のチームマネジメントの重要な論文の大半はハーバードビジネスレビューから生まれているのではないかと思いますが、この特集も読みごたえがあります。

中でも、エイミー・エドモンドソン教授の論文は新しい視点を与えるもので、非常に示唆に富んでいます。

◆プロジェクトリーダーは割にあわない

ＰＭスタイルプラスも今回で５０回になります。小さな節目ですので、今回は少し大きな問題として、リーダーのあり方を考えてみたいと思います。

プロジェクトリーダーを引き受けると、割に合わないという話があります。

権限がない割には苦労が多く、成果を上げるのが当たり前だとされ、報われず、プロジェクトが終わったら疲れ果てている。

このような先輩の苦労を見ている部下たちは、自分はプロジェクトリーダーなどやりたくないと思うようになるとも言われます。なぜ、そのように考えてしまうのでしょうか？

◆iPhoneやiPadはなぜシンプルなのか

シンプルというスタイルについてずっと書きたいと思っていましたが、難しいので躊躇していました。ケン・シーガルのThink Simpleという本を読んでいたら、何となく、考えがまとまってきたので、一度、チャレンジしてみたいと思います。

ケン・シーガルの本とは関係なく、シンプルというと真っ先に頭に浮かんでくるのは、スティーブ・ジョブズであり、アップルであり、iシリーズです。iPhoneやiPadはどうしてシンプルなのでしょうか？

この問題を考えるには、なぜ、ものごとが複雑になるかを考えてみる必要がありそうです。なぜ、複雑になるのか？

iPhoneが誕生したときに、話題になったのはボタンが一つしかないということでした。これは、ユーザがマニュアルを見なくても使えるということへのこだわりでした。ハードのボタンが２つあれば、まず、その機能を理解しなくては使えません。本当はボタンをつけたくなかったのではないかと疑りたくなります。

ここで注意したいことは、ボタンが一つだからシンプルになったのではないことです。たとえば、マウスのように、ボタンを１回押したら○○の操作で、２回押したら△△の操作でと、状態を持たせることもできるわけです。

シンプルである理由は、ユーザがマニュアルを見なくても使えるという方針にこだわったことです。蟻の一穴という言葉がありますが、シンプルはまさにこれで、例外を認めた瞬間にシンプルではなくなります。

Harvard Business Review (ハーバード・ビジネス・レビュー) 2012年 08月号
「イノベーション実践論」

ハーバードビジネスレビュー、待望のイノベーション特集です。読み応えがある論文が並んでいます。「模倣の経営学」の井上先生の論文も採録されています。

じっくり読んでみてください。

◆経験でマネジメントを極める

よく、マネジメントには正解がないといいます。なんか、これも最近では思考停止ワードの一つになっているようで、「自己流でいいんだ」と解釈している人が増えているようです。

もちろん、自己流でいいのですが、無条件というわけではありません。

マネジメントに正解はないということはどういうことか。マネジメントは結果で評価されるということです。マネジメント自体は業務を円滑に遂行するための手段です。その業務がうまくいけばマネジメントはよかったといえますし、うまく行かなければマネジメントが悪かったと評価されるでしょう。

しつこいようですが、うまくいったマネジメントの方法が「正解」というわけではありません。たまたま、その状況でうまく機能しただけかもしれません。似たような別の業務で、同じマネジメントをしてもうまく行くとは限りません。

このようにマネジメントというのは大変厄介なものですが、マネジメントの道を究めるには何をすればよいのでしょうか？

そこで注目されるのが、経験です。