「実践 デザインシンキング」のまとめ

ものづくりに於いて考えるべきことがよくまとまっていてわかりやすい本でした。

デザインシンキング

■共感

他の人が感ていることを感じる

・目的

インサイト(気づき)の発見

・ポイント

  • 抽象的ではなく具体的な行動(いつどうしたのか)
  • 行動→態度→価値観

※答えを聞くのではない

■問題提起

・目的

事実から問題解決に向けた着眼点を定めること

・ポイント

「発言」「行動」に分けて、そこから相手の「考え」「気持ち」を推察

e.g.
発言:残業は嫌だ
行動:残業ばっかり

考え:早く帰りたい
気持ち:業務が終わらないので残業は必要

こうした事実を踏まえて、

どのような「ユーザー」が、     
どういった「インサイト」が背景にあって
どのような「ニーズ」を必要としている

という着眼点を導き出す

■創造

「問題定義」に対応してテーマを設定し、できるだけ多くのアイデアを出していく

・ポイント

アイデアのポイントを評価しない

  • うまくいきそうなもの(実用性)
  • ユーザーがわくわくするもの(有用性)
  • 革新的なもの(革新性)
  • に分類

■プロトタイプ

・目的

アイデアを手にとったり、その場で試したりすること

・ポイント

作成には15分くらい

■テスト

ユーザーが使っているシーンを想定し、その場面を自分たちで演じてみて疑似体験し不具合を確認する

・ポイント

素早く作り、素早く失敗すること

経営者

■NG

  • 市場規模はどうか
  • いつまでにできるのか

■OK

  • どんな発見があったか
  • 何を学んだか
  • 次は何を知りたいか

事例

■Yahoo!

ユーザーファーストで問題を解決するための思考法

 「なにか不便なことはありますか?」などとユーザーに質問しても本音は出てこない
 むしろユーザーの行動や操作しているときの気持ちについて質問した
 どんな画面を見ているのか。使用時間はどれくらいか

などを具体的に掘り下げて聞くようにした

アイデアの発想法

クリエイティブな発想を記録する
自分のベストなタイミングを把握し、その瞬間をキャプチャーできるようにする
内容の良し悪しはその場では判断しない

いいアイデアを生み出すの近道は、できるだけたくさんのアイデアを考えること

アンディ・グローブ 上のまとめ

インテルの元CEO、アンディ・グローブの伝記的な本の上巻。
経営者を題材にした本としては、かなり実務的で学びが大きい本でした。

マネージャーとしての仕事

1969年、グローブは海軍のR&D担当次官補が電気電子技術者協会のプレゼンの内容を切り抜き日誌に張り付けた。

「プロジェクトマネージャーが、マネージメント情報を眺めてばかりいずに、実務の最前線に足しげく足を運ぶ必要がある」

グローブは事業マネージャーへの道を試行錯誤で進み、雑誌の記事を切り抜いて、そこに書かれた中身が自分の果たすべき役割かどうかを自問した。

  • マネージャーは現場をちゃんと見て行く必要がある。正しい情報を得るために全力を尽くす必要がある

ピーターの法則

「人々はみな昇進を通して、やがては自分の手に負えない職責を担うまでになるため、結局は全体として何もかもがうまく運ばない」

  • グローブが生涯、意識し続けてきた法則
  • 昇進に限らず、自分の限界を超えるまで責任の範囲が増大するため、結果に於いて全体として責任を果たせなくなってしまうという事象
  • 実体験としてもこういうことは起きているなと感じている

トラブル対応について

1971年、グローブの日誌にフローチャートや組織図がお目見えする。 僕らはトラブルを切り抜ける能力に頼りすぎていて、そもそも平穏な舵取りをしようという気概が足りない。

  • 問題が起きてからの対応は素早く正確であったとしても、根本的にそういった問題にぶち当たらないようにするための施策を打つ必要がある

マネージャーとは

マネージメントとは、上から与えられたいくつもの業務をうまくこなす術を指す。 業務を小分けにして一つ下の階層に割り当て、部下たちがそれぞれの業務を引き受けてくれたら、業務全体を完了する目処がついたと言える。

効果的に仕事をこなすには、各階層が自分達の仕事速やかに下の階層に割り振る必要がある。

また、グローブは、「ご自身に正直になり過ちへの責任を潔く認めてください」という内容をロバート・ノイスに送っている。 神とも崇められたロバート・ノイスにこのように直言する人物は、アンディグローブの他はまずいないだろう。

  • グローブは、マネージャーとして下の階層に対して責任を発揮し、かつ、上の人に対しても適切な指摘ができる人物であったのだろう
  • 成績を上げている人物にも臆せずに意見を言っていくことも大切

ダメなマネージャーの特徴

  1. 部下に仕事を任せない
  2. 業務の切り分けがうまくできない
  3. 小分けにした業務を各担当者がこなしているかどうかを確かめない

会社の成長について

1973年インテルにとっての課題は、会社の成長と複雑性の増大にどう対処するかであった。

はじめは成長率が高くなるにつれて脱落者の数が減っていく。その後、一定の成長率を越えると脱落者の数が成長率に比例して増大する。

問題は、成長が早すぎると誰もそのスピードについていけないこと、するとすべてがカオスになる。

経営層を占め、なおかつ働き手の失敗率を見極めることのできる立場である以上、成長率がどれくらいを越えたら、全体の歯車が狂い始めるかを見通すのが、自分にとって何よりも大切な役割だろう。 この成長率の上限値は、必ずしも会社が望む成長率とは一致しない。 むしろ脱落者の数を、新規採用者の数よりも少なく抑えたいのだ。

  • 会社が成長するに連れて、社員の能力の総和も成長していく必要があるが、業務の複雑さと量の増大を、業務のシンプル化と社員の成長、人材の増加などの要素で埋めていく必要がある
  • 実体験に基づくと、人が増加することによって、業務が複雑化することも多く、業務のシンプル化の継続的な実施は会社の成長に欠かせないことだと感じている

1975年に、グローブは自分のために文章を書いている。 30代にもかかわず、いくつもの政治体制に接してきた(グローブはハンガリー出身のユダヤ人なので)ばかりか、様々な事業状況を目の当たりにしてきた。そこから得た教訓は、何事も容易ではないということ

教訓

全速力での成長には大きな困難がつきまとうが、成長が穏やかになれば、肩の荷も降りるだろうなどという考えは間違っている。

成長は伴ったがいくつもの過ちがその影に隠れてしまった。供給が不足している状況では、取り組み内容を減らしててを抜いたとしても、なんとか切り抜けられる。

成長の途上では、仕事はきつく、体には堪えるかも知れないが、精神的には楽ではないだろうか。

成長が止まると好調時に見過ごされてきた事柄に取り組むチャンスがやって来たと気づく。製造コストを引き下げ、エンジニアリングを加速させ、新しい事業機会を探求することもできる(もっとも現実には、新しい事業を始めるのは容易ではないが)。

要するに、成長の速度にかかわらず、問題に適切な対処ができない、適材適所を実現できないといったことは必ず起きる。こうした問題はいずれ必ず頭をもたげてくる。不意に頭をもたげてきたように思える場合があっても、実際には長い間くすぶっていたのだ。結果として、みんなが絶えず緊急事態に対処しなくてはならず、ピリピリした空気が社内に広がるだろう。

グローブは適切な組織を設け、適材を探してそこに送り込むことに絶えず心を砕いていた。それによって、問題を見通して不必要な危機を避けようというのだ。

  • 確かに、問題が表面化したときに、根本的な問題を分析すると今までたまたま表面化していなかっただけの事柄がほとんどであるように思う
  • そういった問題の種を放置しておくという事態をできるだけ避けなくてはならないのだろう

心配性

  • 以下にあるように、業績が良かったとしてもグローブは決して満足せず、好ましくない事態が起きうることを知っているだけに、批判的な物の見方をしていた

1976年

業績が絶好調の最中、グローブは自身の見通しを日誌にしたためた。悲観的な内容だった。 会社と一心同体なのである。 インテルの業績がパッとしないと自分を責めるのだ。 自分が社内に範を示さなくてはいけないといつでも心得ていた。 自分が立ち止まったら会社も立ち止まる。

1978年

インテルは快進撃を続けていた。 が、グローブの日誌やメモにはそのことは記載されていない。 7月に、なぜ売上高が10億ドルに届かないのかを考え込んでいた。

答えは、「活力と管理」だった。

活力と管理

インテルが小粒だった当時は、個人や少人数のグループが、会社の業務を動かしていくのに必要な活力(自発性や熱意)を産み出すことができた。

しかし、今は「活力」はもっぱら経営陣が産み出していたが、その活力は日々の責務を果たすために費やされていた。目の前の課題にばかり追われ、長期的な視点での発想やプランニングができていない状態が続いていた。 中間管理職は、積極性に欠ける内向きの人材しか見当たらなかった。みんな、誠実さ、能力、品位、善意に溢れ、一生懸命に仕事をしたが、論争には耐えられなかったのである。厄介なこととして、人柄は変えられないし、しかも、人柄と結び付いた行動も、変えることは至難の業である。

グローブの考えでは、充実した管理体制が全社的に欠けており、どうすれば、充実した管理体制を築けるか、考える力が足りなかったのである。

そこで、グローブは中間管理職層からより大きな活力を引き出す必要があると考え、以下のことを行った。

  1. 下層マネージャーの中から「積極的で進取の気質に富んだ」人材を選り抜き、猛スピードで出世させる
  2. 採用基準を変更して、起業家的な素質を重んじる

マイクロプロセッサ事業

1979年に始動したクラッシュ作戦によりIBM製品にインテルのマイクロプロセッサ8086が採用された。 大きな要因として以下の事が挙げられる。

  1. 経営陣が、現場マネージャーの意見に耳を傾ける度量の広さを備えていた
  2. 中間管理職たちが危機感に刈られ窮状を訴えると、それを見過ごさずに対応した
  • 経営陣が現場の意見に基づく判断が出来る状態にあり、実際に判断し行動をとったことが要因で成功をあげられたのであろう

125%の解決策

1981年、IBMからの採用にも関わらず、インテルは初めて売上高と利益が共に減った。利益にいたっては、72%も落ち込んだ。

しかし、「125%の解決策」が生まれ社内に根付いた。 新製品を予定よりも早く投入できるよう、従業員たちが「自発的に」25%ほど余計に仕事をしたのである

グローブは、低迷期にこそ物事を建て直すべきだと考え、それが実行されないから不満を抱いていたが、1981年にそれは実現され、業務運営や管理の仕組みを刷新した。

秩序

例えば、1971年に始まった「遅刻者リスト」 それは、CEOといえども例外ではなかった。

「社内には億万長者もいるかもしれないが、彼らは朝5時に起きて、夜勤明けの従業員たちをねぎらうのです」

建設的な対立

グローブはあらゆる事柄を(可能であれば定量的に)測定し、日ごとに改善していくべきだという信念を持っていた。

そして、全マネージャーを対象に、順位付けと評価の制度を導入した。 優先事項は、あらかじめ決めた目標と見比べながら各マネージャーの業績を評価することだった。

こういった社風を生み出した手前、グローブは誰よりも厳しい基準を守らなくてはならなかった。

  1. 事業上のテーマに関しては、徹底してその陰にある真実を突き止めようとする
  2. 話し合いでは必ず相手ではなく課題に焦点を絞る
    • しかし、真実を掘り起こそうとする中で、意図していたかどうかにかかわらず、自分たちを面と向かって責めたと受け止めている人も少なくない
    • グローブ自身も穏やかな心境の時に、「自分は相手を十分に理解しないまま深い傷を与えてしまった」と認めている
    • ある従業員が「お願いですから、たまにはお叱り以外の言葉をかけてください」というメモを持ってきたが、グローブはそれをデスクのそばの壁に貼り、そのメモは今もなお、彼のオフィスで見ることができる
  • グローブから学ぶべきことの一つとして、過ちを認め、謙虚にその過ちを改善しようとする姿勢があると思う

マネージメントとリーダーシップ

マネージメントの活動を「実務中心」、リーダーシップは、「変革」を役割とするという説があるが、こういった定義について、グローブは以下のように述べている

  1. リーダーシップはマネジメントよりも優れているという価値観を暗に示しているが、実際には両方が求められる
  2. 一人の人間が、必要に応じて実務的な仕事と、変革とを両方こなせるべきです。テニス選手はフォアとバックを使い分け、同じだけ得意でなくても、とにかく両方を使う
  3. 企業家は、マネジメントが求められているときはそれを実践し、リーダーシップが求められているときは、それを発揮するべきだ
  4. マネージメントとリーダーシップは表裏一体である


メモリ事業からの撤退

1980年、世界でのシェアが3%もなかったにもかかわらず、DRAM(メモリ)市場からの撤退を決断するまでには、ものすごい苦難が伴ったそうだ。

グローブは、産業史上でも希に見るほど理性的で理屈を重んじる経営者である。 そんな彼でも、経営の舵取りから感情を取り除くのは、危機を乗りきろうとしているときには特に、とても難しいものであると述べている。

インテルの経営陣は、個人的な視点をもとに、メモリ事業にとどまる理由をいくつも考えたが、それは、理由ではなく正当化をしていただけであった。

優先順位は、思い入れの強さによって決まった。メモリはインテルにとって命にも等しい存在だったのだ。

「インテル戦略転換」でもおなじみのエピソードであるが、

1985年、グローブはムーアに「もしも経営陣が一新されたら、新任の経営者はどのような行動をとるだろうか」と聞き、ムーア間髪を入れず「メモリ事業から撤退するだろう」と答えた。 「それなら、一度会社を去り、また戻ってきて、撤退を決断しませんか」といった。

この時グローブは、新任のCEOの視点に立つことにより、従来とは違った角度から意思決定をしたわけである。 自分の立場を離れて客観的に事象を捉え、希望を胸に合理的な行動をとろうとする立場から状況を見据えた。

  • 思い入れがあるものであればあるほど、合理的な結論を導きにくい
  • そういう時には、主体ではなく客体として事象に当たると、合理的な判断を行い易い
  • もっとも、物事を主体的に捉えている時ほど、客観視することが困難であると思われるのだが

撤退からの教訓

グローブの心には絶えず「一度起きたことは再び起こりかねない」という思いがある。 メモリ事業からの撤退を通じて、中間管理職の重要性を改めて認識した。

経営トップが過去の成功に基づく信念に縛られ、現実に対応できずにいる間、様々な人が、資源配分や分析を続けていた。幹部が中間管理職の中に身をおき、周りの意見や行動に注意を払う必要がある。

また、「新しい事柄を始めるのは、やめるよりも簡単である」ということも学んだ。故に、何にかを始めるときは慎重でなくてはならない

失敗からの改善

メモリでの失敗についてのグローブのコメント

市場シェアが大きな意味を持ち、シェアを握るためには製造能力を拡充しなくてはならないと見に染みました。 このような投資には大きなリスクが伴います。需要の拡大に先だって投資をしなければならないから。

コモディティを扱う事業は旨味が小さいことも痛感させられたので、今後は知的財産を他社にライセンス供与するつもりはありません。

こういったことを背景に、マイクロプロセッサ事業では、IBMが一ヶ月で購入する量がインテルが1年で製造する量を上回っているという状況にも関わらず、セカンドソーシングを行わないと決めた。

しかし、メモリ事業の失敗を受けて、製造分野の能力を磨いていたため、十分な製造能力を確保することができた。

バブルについて

1980年代にIBMがパソコンを発売することによってバブルが起きた。

バブルを乗り越えるのはひどく骨が折れる仕事だった。 何より、バブルの最中には、それがバブルだとはわからない。

群衆心理に飲み込まれ、すべての兆候が「猛スピードで事業を拡大しなければ」と語りかけてくるように思えてくる。誰もが、判で押したように、「今回だけは特別だ」と言い、世の中が変わったのだから、昔の尺度は通用しないのだと。

バブル期には、以下のジレンマが生じる。

  • このような決めつけをもとに積極的に事業を拡大するライバルにも対抗する必要がある
  • かといって積極的に取り組んだところで、新しい技術が見込み違いの場合もあるし、そうでなくても従業員を抱えすぎるといった事態にも陥る

パラノイヤ

経営者のもっとも重要な役割は、市場で勝利するために従業員たちが熱心に尽くすような環境をつくすことだ。このような情熱に火をつけ、その火を絶やさないようにするためには、恐怖心が大きな意味を持つ。競争の恐怖、破産の恐怖、判断を誤る恐怖、敗北の恐怖、、、これらが大きな原動力となる

グローブの考えでは、成功の醍醐味よりも失敗の恐怖の方が大きな効果を持つ。

それはグローブが産まれてから20年の間、失敗の代償が余りにも大きく、ほどんど死を意味していたからかも知れない。

私は、長い1日の最後にメールに一通り目を通すが、それは恐怖心からである。なにか問題が起きていないか確かめるのだ。夕方には必ず業界紙のページを繰り、気になる記事を切り抜き、翌朝には詳しく調べることにしているが、これも恐怖心からである

  • グローブは常に心配性なのであるが、この心配性からの行動力が賞賛に値する
  • 心配性であるが故に、その心配を払拭するためにあらゆる行動を行うのであろう

インテル社内のこと

報告

インテルは6つの事業グループから構成されていた。 各グループには古参が配置され、CEOであるグローブに直に報告義務を負っていた。

コンピュータ業界の垂直統合型から水平分業型への変容が、どのような戦略的意味合いを持つかを、真っ先に見抜いたCEOはおそらくグローブだろう。

  • 常に情報が円滑に自分の手元に集まってくるような仕組みを作る
  • その情報をもとに分析をして、戦略を組み立てていく

人材活用

グローブは、人材の採用や昇進を決めるのに当たって、大学や学校のお墨付きは必要ないと感じていた。

相手がハーバードやスタンフォードの卒業生かどうかではなく、どのような貢献ができるかを知りたいと考えたのである。

コピー・イグザクトリー

コンポーネンツ技術・製造グループのトップの、クレイグ・R・バレットは、「コピー・イグザクトリー」という手法を打ち出し、どの製造施設でも全く同じ条件を整えようとした。従業員に権限委譲をして自分達の時計をもとに製造ラインを止めさせる、というやり方はしないようにした。

  • 権限移譲による社員の自由度が重要な場合もあるが、このように同質のものを大量に作るような場合は、自由度をできるだけなくし、同じ条件、同じプロセスのもとに作業を実行できるようにするとよい

なおクレイグ・バレットは、グローブ引退後の次のCEOである

ワン・オン・ワン

1987年、グローブは自身3作目となる「ワン・オン・ワン」を執筆した。 この本のメッセージは、

  1. 仕事を楽しもう
  2. 仕事の本質を見つめ、成果をあげることに専念しよう
  3. 仕事を大切にする人の仕事は、必ず尊重しよう
  4. 誰に対しても率直さを心がけよう
  5. 壁にぶつかったら、立ち止まってじっくり考え、自分なりの答えを見つけよう

グローブは、他人の立場に身を置くことを勧め、「難題にも魔法のような解決策がある」という考えを戒めている。

「誠実さを貫くことが最善だ」と考えながら、誠実に振る舞うのは、多くの場合、最善の方法であるが、誠実であるのがいかに難しいかを強く意識している

真実は、伝える側にとっても、伝えられる側にとっても辛い中身であるかもしれない。それでもやはり、経営者やマネージャーには、部下に真実を伝える責務があり、それは往々にして辛い中身である。

心を鬼にして真実を伝え、筋を通すのだ。

従業員は皆、マネージメントされる権利を持っているのである


「なぜ、「できる人」は「できる人」を育てられないのか?」のまとめ

先輩に勧められて、読んでた本をまとめてみる。
個人的にすごく刺さったのは、「できる人」というものを生んでいる原理と、その「できる人」が人を育てるという観点に於いては「できない人」になっていることです。

「できる人」が陥る三つの罠

抜きん出た能力で頑張りすぎる罠

  • 頑張るから能力が上がるのか、能力があるから頑張るのか
    • 「できる人」の多くは、なんとなく脳の中に、"できるイメージ"を形成し。自分を動機づけしている
    • 無意識のうちに動機づけされている自分の内面の現象を、それが起きない他人と比較して違いを理解する必要がある
    • 達成の機会を多く得られる「できる人」は、それによって承認を得るチャンスも多く、結果として成長のスパイラルを描きやすい環境を手にする
  • 高い能力を持つ人の孤軍奮闘が組織を蝕む
    • 「できる人」は自分が頑張ることによって、周囲に刺激を与えるどころか、無力感を植えつけてしまう
    • 「できる人」の出来具合を見せつけられて、自分は無理だという「できない症候群」が広がってしまう
    • 頑張る人への依存体質が風土になっていく
    • 自分が率先して答えを出していくことで、周囲は答えをもらうことに慣れていく
    • 自分で答を見つけ出そうとせず、いつも答えを待つようになる
    • これを受け身と非難することは簡単だが、非難している人が実はその状況を作り出しているケースが多い
  • 「できる人」がもらたす知識とノウハウのブラックボックス
    • 「できる人」は一人で頑張る過程で、その考え方や手順を「できない人」に伝えようとしていない

成功体験にもとづく信念の罠

  • 心の中の動機を伝授することはできない
    • 「できない人」の中にある内発的な動機付けの要素と、「できる人」にもらった"べき論"が衝突する
    • 多くの「できる人」は、経験にもとづく自信を備えて、"べき論"を「できない人」に押し付けてしまう
  • ハードルが高いほど人は燃えるという思い込み
    • 今持っている能力から見て高すぎるハードルは、意欲を萎えさせる
  • スピードが遅いやつは怠慢という思い込み
    • 「できる人」は仕事の遅い人を。サボっている、意欲がないと、否定的に見てしまいがち
    • すでに関係がギクシャクしていて感情のフィルタがかかっている
    • 関係がうまくいっていない状況で相手は、自分を守ろうとし、言い訳や抵抗、消極的な姿勢を招きやすい
    • 子育てと部下の育成は似ている
    • 小さな子供が必死では知っているスピードは、大人のジョギング以下のスピードである。でも、もっと速く走れという親はいない
    • 自分の常識を振りかざしても、それが相手の能力にマッチしなければ、上司の姿勢としては非常識である
    • 相手が特殊なのではなく、特殊なのは自分であることを、改めて自覚しなければならない

高い常識がもたらす非常識の罠

  • こんな簡単なこと、できて当たり前という誤った前提
    • 相手の目線に合わせて行動することは非常に難しい
    • 「やってみせ、言って聞かせて、させてみて、褒めてやらねば人は動かじ」で期待通りに動く人は限られている
    • やってみせることをどのように見せていけばよいのか?などありとあらゆることの常識が、「できる人」と「できない人」では異なる
    • このことに気が付かないと、相手の目線に合わせてやったのにダメなのか。。。という失望感を抱くことになる
  • こうして学んだという、自分の記憶がアダになる
    • 自分が学び、習得してきた過程が、自分の中に記憶されている
    • その記憶をもとづいて、「こうやって教えれば大丈夫」という感覚が生まれる
    • ところが固有のプロセスを当てはめることができない相手がたくさんいる
  • 教える力があるからこそ、育たない可能性がある
    • 自分がいちばん仕事をしているという実感は要注意
    • 自分が忙しくて、部下が暇そうに見えるとしたら、部下の力を引き出していない証拠
    • 「できる人」は、自分がちゃんと実績を出していることで自尊心を満たし、部下の力を引き出していないことへの危機感が足りない
    • 自分の中に勝利の方程式があって、ある程度の問題は自分で答えを出すことができると思っていたら要注意
    • しかし、それは自分がやった場合であり、もとより能力の高い自分の流儀で、他人がうまくやれると考えるほうがおかしい

「できる人」は、こうして組織をダメにする

仕事の目標だけで人を動機づけしようとする

  • "明確な目標"は成長の万能薬ではない
    • 目標があるから進める人もいれば、目標のおかげで進めない人もいる
    • 組織における目標は、その組織を構成するメンバー一人ひとりの目標におりてくるが、その受け止め方が違う
  • 目標に対する気持ちと実態が乖離した「できない人」
    • 明確な目標を前にして、やる気もある人が、目標に対して前進しないことがある
    • 予期せぬ事態によってスケジュール通りに物事が運ばなかった時
    • 「できる人」はアドリブで日々の時間管理をしながら、大筋を外さないようにゴールに向かうというのが当たり前になっている
    • ところが、目標を達成した経験が少ない人は、小さな変化に振り回せれてしまう
  • 目標への真剣さが足を引っ張る要因になる
    • 目標を作って失敗しやすいのは、むしろ相手が真剣である場合
    • なぜなら、相手に真剣さが感じられなければ、事が動き出す前に障害に気がつくことが多い
    • 真剣ならできると考えるのは間違い
    • 目標そのものが悪いのではなく、目標との付き合い方の違いに目を向けなければならない
    • 常に目標がエネルギー源になる「できる人」ほど気をつける必要がある
  • "結果がすべて"のプロ意識に隠された盲点
    • 目標をエネルギーにできるのは、求められたいる結果を出すことへの手応えを掴んでいる人
    • これまでの経験から、そこに至るシナリオをある程度は描けるし、チャレンジすることで得られるものも知っている
    • "結果がすべて"と受け止め、前向きに行動できる人は、すべてである結果に進んでいくためのプロセスが見えている人
    • すこしくらいゴール設定に無理があっても、見えている道を歩いて行く意志をもてる
    • 目標に対する納得性と意欲は、プロセスの理解から生まれる
    • プロセスが見えている「できる人」が、プロセスの見えていない人を、ゴールの明確化で動機づけしようとする
    • このやり方は、今まで以上に結果を意識される
    • だから、「できる人」は望ましい結果に強くコミットする一方、「できない人」は不本意な結果に対する恐れを強める
    • 「できない人」をゴールに到達させてあげるには、"プロセスの見える化"が絶対に必要

「低次元なこと」の大切さに目を向けない

  • こういうふうに説明してあげれば大丈夫だろうという自己判断のもとに、「できる人」は豊富な知識体系に基いて説明をしていく
    • わからないと言ってくれればいいが、「できない人」の多くは、レベルを合わせてもらっているという負い目を感じているので、懇切丁寧に話してもらうほど、「それでも、わからない」とは言い難く、そのまま話は進んでいってしまう
  • すべてマニュアル通りにやらないのは常識、の非常識
    • もっと自分で工夫して、もっと柔軟性を持てと発破をかけるが、そもそも、それができないから「できない人」であるということを忘れてはならない
    • 横断歩道を渡るときに、子供に対して、本当に重要なのは、ルールではなく、怪我なく渡ることだとは普通は言わないのと同じ
    • 手順は手順通りに教える
  • 常識の枠組みが形成されている人、いない人
    • いちいちルールを暗記しなくても、自分の立場と役割にもとづいて常識が形成される
    • これは、「できる人」の行動基盤の一つ
    • 常識の枠組みがあるからこそ、良い意味で突飛な行動もできる
    • 「できる人」は「そんなことは当たり前だろう」という意識をもとに、指摘をする
    • しかし、常識の枠組みができていない人にとって、それは、「当たり前」ではない
    • もちろん、その場では反省の意志を示し、自分が悪いことも理解する
    • しかしそれは、上司が怒っているからといった認識。相手に強く注意されているという行為によって、まずかったと理解しているに過ぎない

自分の頭の回転に合わせて部下を回そうとする

  • じっくり丁寧に教えれば伝わるものだと思っている
    • 対話に於いて、自分の方が話している場合は要注意
    • 丁寧に、より多くの情報を提供すれば、今までよりも伝わるというのは間違い
    • 「できない人」には、情報量が多すぎて、何をどうキャッチすればよいのかわからなくなってしまう

「できる人」に知ってほしい「できない人」との違い

「できる人」と「できない人」の自己認識の違い

  • 「できた!」による自己信頼と「できない…」による自己不信
    • できる体験を繰り返して育った人は、その過程で幾つもの達成感を味わっている
    • 一方、できない体験を繰り返した人は、うまくやれなかったという未完了感を残すことになる
  • 「できる人」と「できない人」の間には、自己信頼の度合いに関する大きな溝がある
    • 生理的欲求については、特別な差異はない
    • 安全欲求の段階ですでに差がある
    • 雇用の安定やそれに伴う所得や生活レベルの安定など
    • 「できる人」はその安全を確保されているという実感を基盤に先を見通して、自助努力ができる
    • 社会的欲求や自尊欲求においては更に差が出る
    • 集団からの承認により、「できる人」は自己信頼を強めていく
  • 失敗をプラスにできる人と、マイナスを増幅させる人の違い
    • マイナス環境を活かそうとする「できる人」には、「できない人」の発想は消極的なものにしか見えない
    • 「できる人」は、マイナスを乗り越えたあとにプラスがあることをこれまでの体験を通じて知っている
    • 「できる人」は常に未来に向けて「いかに…するか」を意識する一方、「できない人」は少し思考が停止すると「…だから無理」という諦める理由を導き出す
    • 「できる人」にとって、諦めることよりも踏ん張るほうが心地よいので、そういったことを意識するが、「できない人」は逆に、諦めることのほうが心地よい
    • 「できる人」は「できる」という評価を得る過程で、「いかに…するか」を考えながら、物事を達成していく
      • この繰り返しにより「好ましさ」が生み出され、未来に向けた「いかに…するか」の思考回路が出来上がっていく
    • そもそも人間の脳は、快楽を求めるように作られていて、「できない人」にとっての快楽は、ハードル超えをやめることとなり、その理由を探すようになる

「できる人」と「できない人」の人生観の違い

  • コントロールしていく人と、コントロールされる人の違い
    • リフレーミング
    • 直面している課題を別の枠組みに入れ替えて再考する
    • 自分でコントロールできることに意識を向ける
    • 環境に対して能動的
    • 「できない人」の中に言い訳や逃避的な姿勢を感じてしまう
  • 「卓越」というゴール、「まあまあ」というゴール
    • 目標に対する意識の違いが褒め下手を生む
    • 次々に高い目標を掲げる
    • 意欲に溢れ、自分の可能性も信じているので、何かを達成したからと言って満足することはない
    • 一つのことに対する達成感とは別の意味で、もっと高みを目指す貪欲さ
  • 何を以てできたとするかの意識の差
    • 具体的な目標は、一つのゴールであると同時に、次に繋ぐプロセスでもあるとゴールを捉えている
    • 一方、「できない人」は、目標を達成すると一息ついてしまう
    • その目標の先にあるものを見ていないので、ある意味自然な欲求
    • こういった行動プロセスの差を、「できる人」の多くは客観的に受け止めることができない
  • 完璧を目指す"WHY"と、その場しのぎの"WHAT"
    • 「できる人」の発想は、問題を解決することではなく、問題の起きない仕組みや体制を作ることにある
    • 行動は常に本質に意識を向けいている
    • これに対して、目の前で起きている問題をどうするかで精一杯なので、"WHAT"に意識を向ける
    • "WHAT"は視野の狭さや後ろ向きな発想によって、歪んだ形で現れるが、その"WHAT"にも理由があるという立場を理解しなければならない

まとめ

まず、できる人のできる所以、できない人のできない所以、その差がよく理解できたことが最も大きな収穫であったと思います。 なぜ、できないのかが理解出来ない、という点で悩むことはなさそうです。

次に、できる人とできない人がとる行動には差があるが、実は同じ欲求により動かされているが、目指したいと思う場所に差があるために生じるという点が参考になりました。 本質的に問題を解決しようとすると、実際にとった行動に焦点を当てるのではなく、その行動に至ったモチベーション側に焦点を当てて話をした方がよいのかなと思います。 ただ、現実問題としては、行動自体を制限することによって、組織の成果をコントロールしているというケースが多いと感じいます。

相手のことをよく理解するために、ものすごく参考になる本でした。 具体的な行動レベルで今日から何かを変えられる訳ではないが、一つ一つの接し方に於いて、少しずつ改善をかけていくにはよいのかなと思っています。 ただ、この本に書かれている具体的な策やテクニックについては、自分が今後直面するであろう事象に対して、どこまで有効かは分からないなというのが所感です。 個人的には、上記の理解の部分を促せる点に於いて、すごく良い本でした。

最後までお読みいただきありがとうございました。

巨象も踊るのまとめ

ルイス・ガースナーが低迷するIBMを再建した時の話。
巨大なIBMをどのように改革していったのか、その考え方やプロセスが非常に勉強になりました。

序章

  • 問題を解決するときには組織内の地位にかかわらず全員が協力できる体制を築く
  • 企業の業績で資金が極めて重要
    • フリー・キャッシュフローこそが企業の健全性と業績を知る上で、最も重要な指標
フリーキャッシュフローとは、企業本来の営業活動により獲得したキャッシュフローから、現事業維持のために投資にまわしたキャッシュフローを差し引いたもの
フリーキャッシュフローは、企業が事業活動から獲得したキャッシュのうち自由に使うことができるキャッシュ
  • 経営者の利害と株主の利害とを一致させること
    • 経営者が自分の資金を投じて自社の株式を保有する方法で

第Ⅰ部掌握

第2章:発表

経営哲学と経営方法

  • 手続きによってではなく、原則によって管理する
  • われわれがやるべきことのすべてを決めるのは市場である
  • 問題を解決し、同僚を助けるために働く人材。脱社内政治。
  • 社長は戦略の策定に全力を尽くす。経営幹部はそれを実行する。
  • 悪いニュースは隠さないように。問題が大きくなってから知らされるのは嫌いだ
  • 社長に問題の処理を委ねない。問題を横の連絡に解決してほしい。問題を上に上にあげない
  • 速く動く。間違えるとしても、動きが遅すぎるためのものより、速すぎたためのものの方がいい。
  • 組織階層は意味を持たない。会議には地位や肩書きにかかわらず、問題解決に役立つ人を。
  • 技術を学ぶ必要はあるが、完全に理解する必要はない。部門責任者は、技術の言葉をビジネスの言葉に翻訳する役割を担わなければならない

第3章:消火栓から水を飲む

技術

  • 研究者と顧客の関係をもっと密接にして、研究者が、顧客が抱える切実な問題の解決を目指すようにする方法を考える必要がある

第4章:現場へ

  • わたしにとって現場に出て行くことは重要だった

戦略会議

  • 顧客のセグメンテーション
  • 他社の競合製品との比較
  • 種々の話題を総合して、会社全体としての見方をまとめる
顧客に焦点を当てる
他社との比較
課題を集約し、自社の立ち位置を決める
3C

第5章:ベアハグ作戦

  • 幹部は、顧客の声を聞き、顧客第一に考えていることを示し、適切に行動に移す

会社の分割について(IBMの場合)

  • 会社の規模の大きさや事業の幅の広さが競争上の確かな強みになっていた

分散化

  • 説明責任を伴った一本化された予算
  • 当時、CIO(最高情報責任者)が128人もいて、それぞれに独自のアーキテクチャーのシステムを管理し、アプリケーションの独自開発の予算を獲得していた
  • そのため、すべての仕様や規格などがバラバラで、連携されていなかった
  • いくつかの事業部門の協力が必要な財務上の問題があるときも、それについて話し合うための基盤がなかった。266の経理システムがあった
  • これらのリエンジニアリングの実施にあたっては、順次手を付けるのではなく、全社一斉に実施することにした
    • 社内情報システムの費用を20億ドル削減し、データセンターを155から16に減らし、31のネットワークを一本化した
社内情報については、一元的に管理され、部門を跨いで閲覧・比較等ができその上で議論ができるようにしなければならない
統合し、シームレスな連携が必須

第6章:止血するそしてビジョンは封印する

IBMのビジネスモデル

  • 総合的な統合パッケージを顧客に提供
  • 基本的な機器とソフトはすべてついてきて、システムのインストールやメンテナンスに関わるすべてのサービスは価格に含まれていた
  • こういった垂直統合型のビジネスモデルは、1980年半ばに、水平に切った製品を提供して成功する企業の台頭により古くなったが、顧客自身が、情報技術のインテグレーションを行わなければならなくなった。
  • そこにIBMの価値があると考えた
    • あらゆる部分を統合し顧客に実効性のあるソリューションを提供する
    • 確かにサプライ・チェーンがあり、チェーンの書く段階の企業は、最終製品のうちの一部を提供しているにすぎない。しかし、各部品を消費者に届ける前に、それらが価値を生むようにまとめる企業が最後になければならない
    • つまり断片をまとめて価値に変える責任を担う企業が必要
プロジェクトにおいても同じ事が言えそう。
各タスクを分散してそれぞれの担当者に行なってもらうが、最終的に誰かがそれらを統合して価値に変える必要がある
プロジェクトマネージャーがその機能の担うべき

資金の確保

  • キャッシュ・フローが枯渇して債権者が支援をやめるという前に生産性の悪い資産を売却して資金の確保をする

ビジョンの封印

  • 難しいこと、痛みの伴うことをやらねばならないのであれば、それがどんなことであれ、迅速に実行されるべきであり、、具体的に何をするのか、そしてそれはなぜ必要ななのかを全員に周知徹底するべき
  • 一つの問題を長々考えたり、問題を隠したり、部分的な解決先を小出しにしたりしながら、景気が良くなって問題が自然に解消されるのを待っていると、問題は必ず深刻化する。問題を素早く解決して、新たな目標に向けて前進するのがよい
  • 本当の問題は、市場に出ていき、市場で日々行動を起こすこと
  • 痛み嫌なら、その痛みを競争相手に転嫁するしかない。市場シェアを奪ったのは競争相手であり、資産を奪ったのは競争相手である
  • 再建のすべては実行にかかっていた
    • 犯人探しをやめて社内の構造や制度をいじるのをやめなければならない
    • 奇跡的な一発逆転を狙った長期プロジェクトなど必要ない
    • 必要なものは、今が危急存亡という自覚

主要な戦略課題

  • 会社を一体として保持し、分割しない
  • 中核的な事業を続ける
  • 基礎的な研究開発の予算を確保する
  • あらゆる行動を顧客の観点から見直し、内向きでプロセス重視の企業ではなく、市場主導の企業へ

第7章:経営チーム

  • 本社執行委員会では、問題解決の委任は受け付けない
  • 事業部門からのプレゼンテーションを聞いたり、判断を下したりすることもない
  • 議題は、複数の部門を跨ぐ方針の問題に限った

社員との対話

  • 取締役会や経営システムを見直すと共に、社員との間に明確で持続的な対話の仕組みを作ることが重要だった
  • 変革を成功させるためには、危機に直面している事実を公に認めることが不可欠
    • 危機に面していることを認識していなければ、変革に必要な犠牲を払おうとはしない
  • 危機の大きさや深刻さ、影響を伝えること、いかにして、危機を乗り切るか、新たな戦略、新たな企業モデル、新たな企業文化について伝えることがCEOの仕事
    • そのためには、CEOが対話を進め、情報を提供し、情報の提供を求め、絶えず社員の前に出て、わかりやすく簡潔でしかも納得のできる言葉で話し、組織全体が考え、行動を起こすようにする努力を続けなければ、企業は変わらない

第8章:世界的企業を作る

  • 世界的な事業展開に対応する強力な地域部門と、基礎となる技術を扱う強力な製品部門があったが、この構造に欠けているのは顧客の視点

第10章:報酬哲学を見直す

業績に対する報酬

  • 均質性 ⇒ 差別化
  • 固定報酬 ⇒ 変動報酬
  • 内部ベンチマーク ⇒ 外部ベンチマーク
  • 社員の権利 ⇒ 業績本意
  • 業績に応じた報酬の考え方であり、忠誠心や在籍期間に応じた報酬ではない
  • すべて差別化に関わっている
    • 市場の業績、個人の業績や市場価値など

持ち株制度

  • 長期的な株主のように考え行動してもらいたいと考えた
    • 市場の圧力を感じ、競争上の優位を築けるように資産を活用し、戦略を形成してもらいたかった
  • 求めていたものは、自分の会社を外から眺められるようになる強力な動機付け
    • 株式市場や競争、顧客の要望の変化といった外部の力によってわれわれの課題を決めなければならず、自分たちの希望や気まぐれで決めてはならないという事実を受け入れてもらう必要があった
  • ストック・オプションの変革
    • 経営幹部の年間報酬のうち現金部分を少なくし、株価上昇による部分を多くして、株式に基づく部分を報酬の最大項目にした
      • 長期的な株主が富を蓄積できなければ、自分たちも富を蓄積できない
    • 経営幹部自らの資金で株式を購入しなければ、ストック・オプションは付与されないようにした
      • 「ゲームに自分の金を賭けろ」。タダ乗りは許さない
  • 経営幹部は全員、株主と同じ立場に立たなければならない
    • 自分自身の資金をリスクにさらすのが重要

必要悪

  • 危機の際には、有望な人材をつなぎとめておくことが一層大切
    • そのために、どうしても残って欲しい人たちに、価値がなくなった既存のオプションを行使価格の低い新たなオプションに切り替える機会を与えた
    • 規則の途中の変更は、戦いの精神に反するが、緊急事態だった
    • しかし、上級幹部は対象からは外した。問題を創りだした責任があり、以前のオプションを以前の行使価格で持ち続けて、問題を解決しなければならない

その他の変更

  • 経営幹部のボーナスは、それぞれが所属する事業部門の業績にだけ基づいて支給されていたことで、自部門の業績さえ良ければ、会社全体の業績が悪くても十分なボーナスが支払われた
    • これにより、自分さえ良ければという文化が助長されていた
  • ⇒ボーナスの一定割合を全体の業績に基づいて支給することにし、その比率を下に行くほど低くした
  • 年間ボーナスは全体の業績に直接連動しており、同僚と力を合わせて業績をあげれば、自分たちのためになることを周知徹底させるものだった
経営に深く関わる人であればあるほど、会社全体の業績に対して、リスクを負い、責任を取らなければならない

第Ⅱ部:戦略

第12章:IBM小史

企業分解の形成

  • 企業文化を形成した主要な要因
    • 競争上の脅威がほとんどなく、高い利益率と圧倒的な市場シェアが保証されている時、一般の企業にとって極めて重要な経済や市場の力が問題でなくなる
    • 企業やその社員は外の世界の現実を見失っていく
    • 市場での出来事は、その企業の成功とは何の関係もない
  • 圧倒的な地位によって、内向きの世界、外部の影響を受けない世界が形成された
逆をいえば、一般的な企業にとって重要なのは、経済であり、市場である
外部から影響を受け、外向きの世界を維持して行かなければならない

第14章:サービス

  • 顧客にとって最適なソリューションであれば、サービス部隊は、競争相手の製品を推薦できなければならない
    • これらの製品を維持・補修する必要もある
  • 労働集約的なサービス事業の、売り物は能力であり、知識である
顧客が求めるものは、自社が作っている製品などではなく、統合的なサービスである

第15章:世界最大のソフトウェア事業を再構築

  • IBMのソフトウェア事業は世界最大の売上を誇っていたが、ソフトウェア事業者としての自覚がなく、独立した事業でもなかった
  • 規模は大きいが細分化されていて管理ができていなかった
  • ソフトウェア自体が、自社のメインフレーム向けで、市場で主流の小型・分散型システム向けではなかった
  • 市場には分散化されたシステムが多数ある状態に対して、クロスプラットフォームで作動するようにする必要があり、既存の仕様をすべて変更した
Appleのジョブズの戦略とは少し違う気がする(この点は、最後の部でも少し触れらている。顧客至上主義ではないので当然)
ハードウェアとソフトウェアの一体化を目指し、すべて自社の製品に一貫性をもたせたが、IBMは違った
統一化を目指したが、それは、市場にあふれる分散化したサービスの統合であり、自社製品への統合ではなかった
この点は、ナンバーワン企業の法則でいう、カスタマーインティマシー企業の特徴である、空洞化したビジネスという点に合致する
ただ、自社の体制や管理に関しては、統合し一本化を図った

第17章:スタックを分解して、事象の的を絞る

  • 重要なことは、焦点を絞ること
    • いくつかの段階を踏んで、スタックの一部から撤退し、事業の的を絞り込んだ
    • これを書いている現在も他の事業からの撤退を検討中
  • 市場を選別し、持続可能な独自の競争力をもとに戦う事が重要であり、これは常に取り組むべき課題である
  • 自社の独自のスタックの窓から世界を見るのではなく、顧客の事業プロセスと、自社と他の先進企業の世界的な技術を使って、それらのプロセスをいかに改善するのかというスタックで戦っている
  • あらゆる重要な決定を左右するのは市場

誤解と神話と教訓

  • 最高の技術が常に勝つという誤解
    • 技術的には素晴らしい製品が、技術的にはそこそこでも顧客の望むものを理解している企業がサポートする製品に負ける

アプリケーション・ソフトの「顧客管理」という神話

  • 情報技術企業では「顧客管理」という言葉が使われてきたが、企業の仕事は顧客に奉仕することであって、顧客を管理することではない

第Ⅲ部:企業文化

第20章:企業文化

  • 組織の価値は、それを構成する人々が全体として、どこまでの価値を生み出せるのかで決まる
  • ビジョン・戦略・マーケティング・財務管理などの側面が正しければ、しばらくの成功を収めることはできる
  • だが、どんな分野の組織であろうと、これらの正しさがDNAの一部になっていなければ、長期的な成功を続けることは難しい
  • 成功している組織はほぼすべて、その組織の偉大さをもたらす要因を強化する文化を確立している
  • この文化は形成された時の環境を反映している。故に、環境が変わった時に文化を変えることは極めて難しい
  • そして、文化が組織の適応能力を制約する極めて大きな障害になってしまう
  • 企業の当初の文化は通常、創業者の個人的な価値観、信念、好みによって作られる
  • そして、自社の大成功をもたらした価値観を意識的に組織に制度化する
  • 組織は成功をおさめるほど、偉大さをもたらしてきたものをルールの形で定着させようとする。これは良い動きとなり得る。
  • しかし、世界は変化する。いずれ、ルールや指針や慣習が、組織の本来の任務との関連を失っていくのは避けられない
  • 成功をもたらした文化をルールにする動きは、価値観と行動様式をめぐって起こる「死後硬直」とも言える
    • つまり、創業時の文化の元となる理念が忘れ去られ、ルールだけが独り歩きする
創業者がつくった文化の本質を理解し、伝えていくことが大切
ルールではなく価値観や信念という部分にフォーカスして行く必要がある
本来的には、ルール化しなくても価値観や信念の部分を理解していれば、ルールとは違うより上位のレイヤーで行動が決定されるはずである

企業文化の問題に真正面から取り組む

  • 経営幹部ができるのは、企業文化が変わる条件を作ることだけ。動機付けや目標設定ならできる。そして、信頼する。
  • 結局のところ、経営陣は文化を変えられるわけではなく、社員に自ら文化を変えるように招待するだけ
  • 問題は、社員にその正体を受け入れてもらうこと
    • 社員に私の話を聞き、目標を理解するように求め、ともに目標に向かって進もうと呼びかける
    • 一方で、言われたことをやる追随者の立場から離れるように求める

第Ⅳ部:教訓

第23章:絞り込み

  • 事実を見ていくと、殆どの場合、企業は基幹事業でいくつかの競争上の優位を確立している
    • 既存企業の方向転換と再活性化はきわめて難しいが、事業環境が全く違う市場の進出して成功を収めることと比較すれば、はるかに容易である
  • 本業に専念しろ

冷徹な戦略

  • ビジョンをまとめると、自信と安心感が生まれるが、きわめて危険である
    • ビジョンは社内に熱意と興奮を作り出す役割をはたす
    • しかし、志を現実に変えるための道筋を示す点では役に立たない
  • 焦点を絞り込んで成功を収める企業は、自社の顧客のニーズ、競争環境、経済的な現実を深く理解している

第24章:実行

  • 結局のところ、度の今日押すあいても基本的に同じ武器で戦っていることが多い
  • したがって、実行こそが、成功に導く戦略の中で決定的な部分である
    • やり遂げること。正しくやり遂げること。競争相手よりうまくやり遂げること。
    • 将来の新しいビジョンを夢想するより、はるかに重要である
  • 世界の偉大な企業はいずれも、日々の実行で競争相手に差をつけている

評価基準が行動基準

  • 実行とは、戦略を行動計画に翻訳し、その結果を評価すること
    • 大雨を正しく予想しただけで功績としてはならない。方舟を作って初めて功績となる
  • 優れた実行を引き出すものとしては、価値観と熱意(コミットメント)が重要

まとめ

以下、重要だなと感じたことをまとめてみた

  • 顧客に焦点をあて、顧客主導型企業へ
  • 全社の業績に対して責任をもつ
  • 複数管理しているものを一本化。統合していくこと
  • ルールではなく原則による管理。原則の背景を理解する
  • 事業の絞り込みが重要。
  • 評価基準を実行に。実行が大切

良い本でした。
最後までお読みいただきありがとうございました。

ブログ始めました

きっかけ

社会に揉まれながら、いろいろなことを学んでは忘れ、忘れては学びを繰り返す日々に別れを告げようと、とりあえず、自分のメモ程度に始めてみようと思い立ちました。

前から、はてダはやってたんですが、プログラミングとか開発の内容が中心になってたので、ビジネスマンとしての学びをまとめる場所が無かったので、ちょうどよい機会に、技術的なこと以外はこっちに集約させようと言うわけです。

ちょいちょい更新する予定です。
よろしくどうぞ!

インテル経営の秘密のまとめ

「インテル経営の秘密」を読んだのでまとめ
途中、かなり難しくて理解出来ていない部分もありましたが、実際に業務に活かせるようなノウハウもたくさんありました。
アンディ・グローブが実務的にどのようなことを考えてインテルを経営しているかからよく学べました。

マネージャーのアウトプット

  • マネージャーのアウトプットとは、その直後の監督下にあったり、または影響下にある組織体のアウトプットである
  • マネージャーのアウトプットは自分の率いる組織のアウトプットそのものであり、それ以上でもそれ以下でもない

つまり、経営管理上の生産性の高さはテコ作用の高いタスクを選びとって遂行することに大きくかかわってくる


生産性の向上

  • チームは、そのメンバーである各個人の中から最高の業務遂行活動が導きだされたときに、最もよく機能して、その業績を高める
  • 計画は、予測しにくい事柄に対しても対応できるだけのエネルギッシュで能率のよいチームを形成しておかなければならない
    • ちょうど消防署の計画のように
  • 即応力のある会社にするためには、経営管理者の階層数をなるべく少なくしておくべき

自分自身のキャリアの管理

  • 自分の環境を知る
    • 自分は単に雇われた一従業員ではなく、一人の事業経営者として働いている
    • いわば似たようなビジネスを営んでいる何百万人の人々と競争状態にある
    • 世界中にいたる所に何百万人もの競合するビジネスをやっている人間がおり、しかもその数は時々刻々急ピッチで増えており、さらに自分が行っているのと同じような仕事がこなせるだけでなくて、もっと多くの、また熱心に遂行しようとしている人間が増えてきている
    • 仕事をしたいのならば、あるいは働き続けたいのならば、「個人としての競争優位性」を保つために、絶えず熱心に自分を磨かなければならない
  • 考えなければならない問い
    • あなたは本当の価値を付与しているのか?それとも単に情報をあちらことらへ流しているだけなのか?付加価値をどうやって高めようとしているのか
    • 自分の周囲で何が起こっているかに関して、いつもアンテナを張り、回路を接続して、情報収集を怠らないでいるか
    • 自分自らが、新しいアイデアや、新しい手法や、新しい技術をいつもためしてみているか

生産原理

顧客の要求に応じて、あらかじめ決められた「一定の」時間に、客に、納得してもらえる品質水準の製品を、できるだけ「低廉な」コストで、作り上げて提供すること

  • 取り掛かる作業の全体的な形を決める中心的なステップをはっきり突き止めること
    • 制約的ステップ(リミッティングステップ)
    • このステップを中心に生産の流れを組み立てて逆に考えていく
  • 大切なのは、生産プロセスのいろいろな面の間の関係を何としても理解しようと努力すること

付加価値をつけるということ

どの生産の流れにも基本的な特徴は、「ものはプロセスを通って動くにつれて次第に価値が高くなる」というもの

  • 注意するべきことは、極当たり前のルールであるが、どのような問題にしても、生産プロセスの中で出来る限り「価値が最低」の段階で問題を発見して解決するべき

生産管理

真に有効なインディケータは作業単位の「アウトプット」を測定するものであって、それに含まれる「アクティビティ」だけを見るものではない


品質の管理

製造業者が守るべき大原則は、顧客が満足するような品質レベルの製品を、できるだけ低いコストで顧客に引き渡すこと

  • 製品の質が確実に受け入れられるようにするためには、あらゆる生産の流れにプロセスの検査ポイントがなければならない
  • 最低のコストで受容しうる品質を得るには、欠陥材料をその蓄積価値が出来る限り低い段階で拒否することが絶対に重要

マネジメントはチームゲーム

  • マネージャーのアウトプットとは、監督下にあるグループ。あるいは影響下にあるグループが遂行した成果である
  • マネージャーというものは、アウトプットに影響を与えるために、一連のいろいろな活動に従事するものである
    • だが、アウトプットとそれら活動(アクティビティ)は決して同一ものではない
  • マネージャーの意思決定は、ビジネスが直面している事実や問題点を当人がどの程度よく理解しているかによって左右される
    • 故に情報収集が重要
      • 情報を効率よく入手するには、マネージャーの方から現場訪問すること

権限委譲

権限委譲の成功のカギは、目標や望ましいアプローチを伝えること

  • 企業文化の価値を守る人々は似たような状況下で一貫した行動を取るようになる

マネージャーが仕事だと思われることをやりながら動き回っているとき、実は、役割モデルとしての模範になっている

  • 価値観や行動規範は口頭やメモでは簡単には伝わらないが、実践や「目に見える」行動によって極めて効果的に伝達される
  • 力を発揮しうるのは、マネージャーが自分の組織内の人々のための役割モデルでなければならないと認識し、意識してそれに重点をおいている時だけ

最後までトコトン、フォローしない権限委譲は「職務放棄」である

  • 権限委譲した後でも、仕事の完了に対してはやはり責任がある
  • 委譲した仕事のモニタリングは、結果を確実にもたらすための唯一の実際的な方法である

プロセスの中で付加価値が最も低い段階でモニターしなければならない

  • モニタリングの頻度は、あなたが考える部下の「通常の一般的」仕事能力を基準にするのではなく、特定の仕事での部下の経験と以前の実績を基準にするべき

マネージャーの活動速度を速める

  • 「柔軟性」がない、つまり、動かせないものを先に決め、もっとやりくりできる活動をその周辺に置くように工夫する
  • 類似したタスクはバッチ処理
  • できる仕事を予測して、その準備態勢を整えておくことが、経営管理上の仕事で経験する、細切れ仕事ばかりでとりとめがないトイウ感じと現実のギャップを極小化するための常識である
  • 時間が決定的な意味を持つ出来事と、必要だが時間的にはそれほどではない出来事との間の穴を進んで埋める
  • 処理能力以上の仕事に対しては、初めからはっきりと「ノウ」をいう
    • 遅くならないうちに早めに「ノウ」と言うことが大切
    • 高い価値段階に達してから処理能力不足のために放棄するのは、金と時間の浪費
  • マネージャーは、自分のやることを標準化しようとする際にも、自分のすることと、ならびに用いるアプローチについて批判的に考え続けなければならない

ワン・オン・ワン

ワン・オン・ワンというのは、監督者と部下の間のミーティングのことで、仕事上の関係を維持する重要な方法
主たる目的は、総合に教えたり、情報を交換すること


ワン・オン・ワン・ミーティングの重要項目

  • 「部下」のミーティングであること
    • その議題や調子も部下が決めるべき筋合いのものと考える
  • 最低一時間は続ける
    • 時間がそれ以下の場合に、部下が持ち出してくる問題は、すばやく取り扱える簡単なものに自ずと限定されてしまう
  • アウトラインは部下が決める
    • 取り上げてもらおうと思う全ての問題点や要点を事前によく考える事になるため
    • ただし、重点はトラブルの存在を知らせてくれるインディケータに置くべきである
    • 特に極めて重要なのは「潜在的な」問題である
  • 上司はコーチするためにそこにいる
    • 何が起こっているのか、部下は何に困っているのか。そういう事について不可が表立って説明するのを助ける
    • ある主題について、部下が言いたいことを全部話したと思ったら、「双方が」問題の底にまで達したと満足間を思えるまで、質問を繰り返して、部下を励まし思考の流れを続けさせるようにするべき
  • 今やっているミーティングが終わる前に次のミーティングを決める様に計画する

使命中心のミーティング

特別な目的のために随時開かれ、特定の成果をあげるために、一定の意思決定に到達するように企図されているミーティング

司会者が行うべきこと

  • 自らがミーティングの目標(何が行われる必要があるのか、どういう意思決定をしなければならないのか)をはっきりと理解する
  • 果たしてミーティングが必要なのかを考える
  • ミーティングの目的をはっきりと述べ、希望通りの成果をあげるために各人にどういう役割を期待しているのかを知らせる
  • 議事録はできるだけ明瞭かつ具体的に記録し、何をしなければならないのか、誰がするのか、いつやるのかを読み手に分からせる

計画化

計画策定方式

マネージャーの一般的なプランニングプロセスは類推思考から成り立っている

  • ステップ1:予想したニーズあるいは需要を決める
    • つまり、自分に対し、あるいは自分のビジネス、あるいは自分の組織に対して要求される環境要件は何か
  • ステップ2:現状を把握する
    • 現在生産しているものは何か
    • 今、パイプラインの中に入っているプロジェクトが完了したら何を生産しようとするのか
    • 現在やっていることと異なったkとおをまるでやらないなら、自分のビジネスはどこへ行き着くのか
  • ステップ3:ステップ1とステップ2を比較して調和させる

ステップ1

  • 顧客側の期待と、あなたのサービスのやり方と実績につにての認識の度合を見極める
    • 顧客は今何を要求しているのか
    • 自分は顧客を満足させているのか
    • 今日から一年経ったら、何を期待するであろうか
  • 環境が現在要求するものと、今日から一年後に要求すると思われるものとの差異を浮き彫りにさせること

ステップ2

  • 現状を把握すること
  • 現在の能力と仕掛りのプロジェクトをリストアップすること

ステップ3

  • 環境が要求するものと現在の活動によって生み出されるもののギャップを埋めるために、新しいタスクに着手するとか古いタスクを修正したりすること

プランニング・プロセスのアウトプット

「明日」の問題を解決するために「今日」何をするべきか
ただし、以下のことを忘れてはならない

  • 何かに対して「イエス」ということは、その他のことに対して「ノウ」と暗黙のうちにいっている
  • 一つの約束をするたびに、それ以外のことを約束する機会を喪失する

まとめ

自分の業務に直接落とし込めていて重要だと思うことを少し。

本当に必要かどうかわからないシステム要件などに「ノウ」という

  • 必要ではないものを開発することは、他の必要な要件を開発しないことを意味するので避ける
  • 要望の段階では蓄積価値は低い。この段階で正しい取捨選択を行うことが会社としてのアウトプットを最大化させることにつながる

要件から実装までの間のチェックを強化する

要件が実装されるまでのプロセスを分解してみる

  • 要件理解
  • 設計
  • コーディング
  • テスト
  • 実装
  • この中で、出来る限り蓄積価値が少ない段階にチェックを挟む
    • 要件理解と設計とコーディングが望ましいと感じている

  • 要件理解
    • 要件提案者とマネージャーと実装者の三者の間で共通理解を促す
    • 共通の理解が得られるまで、次のステップへ行かない
  • 設計
    • 要件に対する正しい設計が出来ているかをチェックする
    • この段階で付加価値が大きく増大するため、念入りにチェックを行う
  • コーディング
    • 設計に対する正しいコーディングが出来ているかをチェックする
    • このプロセスにおいては、日々コーディングが行われるため、チェックの周期が短ければ短いほど、蓄積価値が少ない状態で欠陥品をはじくことが出来る

教育を行う

  • 部下のモチベーションをあげることと能力を向上させてあげること
  • 訓練が不十分なせいで、悪意を持っていたわけではないにも関わらず、会社に対して、非効率をもたらし、余分な経費をかけさせて、顧客の不満足を招き、危険な状態ですらつくりだしてしまう
    • 実際に仕事をする上で、このような事象は山ほどあるし、実際に経験をした方も多いと思われる

つれづれな感じのまとめでしたが、以上です。
最後までお読みいただきありがとうございました。

「プロジェクト・マネージャーが知るべき97のこと」のまとめ

最近、プロジェクトマネージメントをすることが多くなってきたので、学習を開始。

「プロジェクト・マネージャーが知るべき97のこと」を読んで良い本だと思ったので、久々にまとめ

プロジェクト

  • プロジェクトの成功は組織にもたらすビジネス価値で評価される
    • プロジェクトをビジネスニーズに結びつけておかないと、いくら素晴らしいソフトウェアを作っても組織のROIからみれば失敗に終わる
  • 見積もること
    • 見積もりを改善する方法は、実際にどうであったかを必ず記録して、チームがどれくらいうまく見積もれたかフィードバックを得ること
    • 見積もりの本当の説明責任とは、見積もりを当てることではなく、見積もりが外れそうに思ったら直ぐに警鐘をならすこと
  • 具体的に目的のあるミーティングだけを予定に入れる
    • ミーティングはコードを書かない
    • 事前に明確なアジェンダを配布する
      • もしチーム全員を集めるなら、話題が全員に関係するものか確かめる
    • 発生したリスクや問題、障害を指摘するのは良いことではあるが、MTGをその解決策を打ち出す場にしてはならない
      • MTG後に問題を追求するように、少人数のグループをつくるか、適切なチームメンバーを指名する
    • フォーカスを見失ってはならない
  • プロジェクトを成功させる秘訣は、「何か見せるものができたらすぐにユーザーを巻き込むことです」
  • ニーズと期待が明確でないために、プロジェクトは難しいので、以下のことをプロマネは実施する必要がある
    • プロジェクトの主たる目的を明確にする
    • なぜこのプロジェクトをやるのか、全員が理解すること
    • People/Process/Platformへの影響を明確にすること
    • ニーズと期待が要求ドキュメントに含まれていること
      • また、何がスコープ内で何がスコープ外か判断して、チームに伝えること
  • プロマネはビジョンと期待される成果に合わせるため、3つの視点を使いこなす必要がある
    • ビジネスの視点:どうしてこのプロジェクトが解決策になるのか
      • どの様な問題や機会を解決しようとしているのか。組織にどの様な価値をもたらすのか
    • SMARTの視点:ソフトウェアは何をするべきなのか
      • 具体的に(Specific)、計測可能で(Measurable)、合意された(Agreed upon)、現実的な(Realistic)機能を時間制約(Time constraint)内で実現する
    • 主観的な視点:エンドユーザーはシステムに何を期待しているのか
      • 開始フェーズでエンドユーザーの期待と認識を獲得する
  • 実装が始まると、本来の理由を忘れて、具体的機能やプロジェクトの技術的側面に注目してしまいがち
    • チームは必ずしも解決するべき真のビジネス問題を念頭に置いているわけではないので、判断には誤解や落とし穴、エラーが発生するおそれがある
    • プロジェクトが組織にもたらすべき価値は、必ずしも最先端の技術や機能にあるとは限らない
    • プロジェクトの目的、前提、制約、リスクを明確にする必要がある -プロジェクトの技術的目標及び機能的目標は全員が理解し、明確でなくてはならない
    • そして、成果は戦略的ビジネス目標を一致している必要がある
  • エンドユーザーが何を期待しているのか特定しなくてはならない
    • 新しいアプリケーションが日々の業務をどの様に支援することを期待しているのか
    • エンドユーザーの利益と期待を理解して、それを実現できるように開発チームに正しく伝えなくてはならない
    • 現実的な最終ビジョンに基づいて、エンドユーザーにその長所を正確に伝え、彼らを支援することが必要
  • プロジェクトの目的や利点を細部にわたって理解していると、簡単にその場で的確な判断が下せる
    • ユーザーが何を期待しているのかシステムが何の為にあるのかを理解すると、効率よく変更管理提案を評価することができる
    • 技術的なプロジェクト要求とプロジェクトが目的とするビジネス価値の両方を理解するように努めなければならない
  • プロジェクトは3つの制約に支配されている。コスト、時間、スコープ
    • スコープは最も柔軟性のある制約
      • フィーチャーや機能には、「なくてはならない」ものと「あったらいいな」というものの2種類がある
    • 「あったらいいな」というフィーチャーは最も削減しやすいもの
      • 「あったらいいな」というフィーチャーと他のフィーチャーとの相互関係を最初から特定しておく
      • 「あったらいいな」というフィーチャーを削減するとき、それが「なくてはならない」ものと関係あると、開発アーキテクチャの変更を余儀なくされるおそれがある
  • プロジェクトにおける判断では、最も優れた点のある案ではなく、致命的な欠陥の存在しない案を選ぶべき
    • どんなに良いことが合ったとしても、致命的欠陥を持つ案はプロジェクトの完成に大きなリスク要因となるため
  • スコープやスケジュール、コストのベースラインがしっかりせっていされていて、プロジェクト進行中にベースラインからの乖離が発生すれば、それが、把握できてコントロールできるプロジェクトはマネジメントしやすい
    • 最終成果物で実現する機能を洗い出し、「何を作るか」を明確にする
    • 最終成果物に蓄える非機能要件のレベルを検討し、「どれくらいのパフォーマンス」にするか明確にする
    • 最終成果物をつくるための作業を定義し、「どう作るか」を明確にする
    • 「どう作るか」を基に、「いくらかかるか」を明確にする
  • プロジェクトの目的をそのスタート前によく確認して文章化しておく
  • プロジェクトでは、何がなされるべきかが、第一のしかも決定的な問題
    • プロジェクト活動では、いかに行うかは、何を行うかのあとに来る問題であり、まずは、何がなされるべきかを追求する
    • プロジェクトの目的とビジョンを明確にして、責任と役割をアサインする

要件定義

  • 失敗の一番の理由は、不十分な要件定義
    • 業務分析が不十分な場合
    • 真の要件を見つけ特定し定義するのが成功のためには必須
  • 一般的にソフトウェアは複雑な問題を解決してくれるもの
    • どの程度エンドユーザーに複雑さを強いるかが問題
    • プロジェクトマネージャーは存在する複雑さを吸収する必要がある
      • 決して複雑さを増幅させてはいけない
    • 矛盾のある様な要求を整理を手伝い、複雑さを吸収してエンドユーザーに別の選択肢を選ばせすために役立つ情報を提供する
  • 要件をシンプルにしておくこと
    • 頭に浮かんだ解決策と、ビジネス要求に基づく実際の顧客要求とを混同してしまいがち
    • シンプルなツリー構造をイメージして要件を書くべき
    • ルートにある要件がプロジェクト全体のシンプルな目的となる
      • マインドマップを利用すると便利
  • 要求と仕様の区別をあいまいにすると、間違った人に判断させることになる
    • 要求とは製品のフィーチャーがある既存の問題あるいは潜在的な問題をどの様に解決するかを記述したもの
    • フィーチャー(機能)とはそうした重要な問題を解決するために製品に追加されるもの
    • 問題がどの様に解決されるか、要求がどのように満たされるかを正確に記述したもの
  • シンプルなシステムから着手する
    • 必要としていたのは自転車だけだったのに、動かない宇宙船の一部を作ってしまうようなことはさける
    • 古い手続きに合わせたソフトウェアをスクラッチから作るのではなく、システムに合わせて内部手続を調整すること
  • ユーザーの気分を良くしたいことを根拠にそれを最高のソリューションだと判断しているのは致命的な欠陥である
    • ユーザーが正しいと感じるものではなく、最高のソリューションを提供する
      • ただし、ユーザーは自らのビジネス領域について深く理解している
    • 正しい質問を投げかけ、根本的な問題を明らかにすること
  • 複雑さはコンポーネントの相互接続数に比例する
  • コンポーネントもお互いに疎結合である必要がある
  • ソフトウェアは仕事のやり方を変え、それは組織にとっては良いことである
    • しかし、実際に仕事をしている人は必ずしも変化を受け入れる準備が出来ているわけではないことを理解する
    • 変化が関係者にどんな影響を及ぼすのかを理解し、変化を受け入れられるような変更管理計画を整備するために適切なケアをする
    • 変化がどんな影響をおよぼすのかを理解するためには、現在どの様に仕事をしているのか、新しいソフトウェアはそのプロセスをどの様に変えるのかを理解すること
    • 変化がユーザーにどんな影響を及ぼすのかを判断するために、まずは、プロジェクトにまつわる現在のあらゆる(そのままの)プロセスをドキュメント化する
    • ソフトウェアを展開し、プロセスがどのように変化するのかをドキュメント化する
  • 開発中に全てを知ろうと思わずに、後になれば全てがわかると考えることもできる
    • アジャイルといった開発方法論はそう仮定している
    • 事前の詳細設計によって「合意」されていたとしても、要求は開発中に変化する
      • 前もって全てを知ることは不可能
      • 複数の要求が矛盾することもよくある
  • 最初から偏見なしに行う
    • 顧客と話す前に、すでに武器を手にして戦い方を決めていると、自分のソリューションがベストであることを証明するのは難しい
    • 顧客は提供される新しいソフトウェアを使ってどんな問題を解決しようしているのかを見極める

マネージメント

  • プロジェクトに人を投下しすぎない
    • 人を増やせばチャネル数が指数的に増大し続ける(チャネル数=n(n-1))
  • うまくいっているチームは、定期的に自分帯のプラクティスに疑問を持ち、無駄を排除しようとする
    • 完璧であるということは、付け加えるべきものがなくなったときではなく、取り去るべきものがなくなったときである
    • 過ぎたるは及ばざるが如し
  • 理想と現実の違いや混乱を無くしていくことこそが、プロジェクトマネージメントの仕事
    • プロジェクトに関わる人よりもうまく計画し、明確に考え、優れた戦略的ビジョンをもつこと
    • プロジェクトの実行は、本質的にやっかいな仕事であり、避けられない問題を潰したり、回避したり、取るに足らない問題へと解きほぐすためにプロマネはいる
  • プロジェクトマネージャーひとりが決めたものではなく、チームの全員によって周知され、文章化され、管理された、明確なビジョン、明確な受け入れ基準、共有されたプロジェクトの優先順位があるとき、優れたチームは本当に驚くべきパフォーマンスを発揮する
  • 全てのステークホルダーが積極的かつ適度にプロジェクトに参加させる必要がある
    • 失敗を回避するためには、だれが、何を、いつ、なぜ作っているのかを把握する
    • 全員がソフトウェアを納品するという活動にかかわり、良い結果であろうと悪い結果であろうとどちらにも一部責任を負わなくてはならない
    • プロマネはその結果を測定し、成功と失敗どちらの実績も記録する必要がある
  • ミーティングが長引いてしまうと、開発者が当てにしていた貴重なプログラミングの時間を盗んでしまうことになる
  • 仕事を小さなイテレーションに分解すると進捗状況を追跡でき、よい結果を知らせる機会も生まれる
    • なぜ、いつ、どのように、何を、誰がといった質問を自分自身あるいはチームに問いかける
    • チーム全体が仕事を完了したなら、ステークホルダー(出来ればエンドユーザー)からフィードバックを得る
  • チームをマネージ、リードするためにはプロマネは自らを完全にコントロールする必要がある
    • 自分の個人的目的、ビジョン、ミッションも、個人的な仕事上の目標もきちんと理解しなくてはならない
      • 毎日、毎週、半年ごとに、自分が人生のどこにいるのかレビューする時間をつくる
  • 予測不可能な変更にチームが効果的に対応して、プロジェクトのフィーチャーを見直し、優先樹にづけをやり直せるような、タイムリーなコミュニケーションループが存在する
    • ミーティングでは、開発者に前回のミーティングから達成したこと、「今日」達成しようとしていること、それを達成するために想定される障害について説明をさせる
  • 全ての成果物にはその完成に責任をもつ人が一人いるべき
    • 各アイテムの完成に誰が責任をもっているのか、プロジェクトに取り組んでいる全員が明確に理解するべき
      • 成果物に関連した問題があると、その最終責任者はチームに早く問題を伝えるようになる(自分に責任があるため)
    • プロジェクトの進行中、チームメンバー全員が、その問題について誰に聞けば良いのか、非常に効率よくかつ正確に知ることができる
      • 自分がよく理解していないことに対する回答が必要な時は、自分の時間を費やすべきではない
  • チームメンバーがお互いを助け合い、他のチームメンバーが本当の潜在能力を発揮できるよう助け、全員が自らの限界を超えることが出来る環境を作る
    • プロマネは持続可能はチームをつくることを目標に掲げるべき
    • 最終的に長期的はチーム作りの計画を立てて取り組むことで、現在のプロジェクトはもちろん、将来のあらゆる活動に於いても、マイクロマネジメントを避けることができる
    • プロマネは戦略的な仕事を担い、プログラマは戦術的なことを担うべき
    • プロマネは物事がプロジェクトにとって正しい方向に進んでいるかを確かめる真のファシリテータや触媒となる
    • パットン将軍の「どんな戦術も眼前の的には無力だ」このことは、今日一日のコーディングやアーキテクチャの判断に関わるのではなく、チームが予期せぬ変なに対応出来るようになるためにもっと時間をかける必要があることを意味している
  • プロマネの仕事はチームのファシリテータ
    • 障害を見つけて取り除き、チームにリソースを提供すること
    • チームのベロシティを高めるために役立つことを日々実践する
    • プロジェクトのステータスをはっきりと眼に見える形で記録
    • 誰がそのタスクを完了しなくてはならないのか、全ての割り当てのマスターとなるリストを作成
    • 自分のリームが卓越したチームに進歩するのを助ける
  • 一番うまく見積もれるのはその仕事をする人
  • プロジェクトの成功はチームメンバーの姿勢と適正にかかっている
    • プロジェクトが成功するかは、プロマネの指導力次第
      • 成長性て何をやりたいと思っているのか、チームメンバーに真剣に尋ねる
      • 人に対してではなく、行動に対してフィードバックすることが大切
  • 新米のプロマネは、チームのキャパシティが小さくなったとしても、フィーチャーを追加させ続ける
    • ケイケイん豊富なプロマネは、新たなフィーチャーが出てきたラ正体のリリースを延期にするか、計画済みのフィーチャーと入れ替える
    • バッファを見込んで計画をする
  • ぷろまねの一番重要な役割の一つは、いろいろなチームメンバーが遠慮無く話し合えるようにファシリテートすること
    • メッセンジャーにになってしまうと、通訳が発生し、必ずなにかが失われる
    • クリアでオープンなコミュニケーションのためのチャンネルを定量し、そこまでなされてきた議論と判断を記録に残すことによって、チームメンバー全員が直接交流を深めることができる
  • プロジェクトの成功を正しく捉えるには、第一二プロジェクトの目的そのものを正しく理解する必要がある
    • プロジェクトの存在意義そものとプロジェクトの本質を知ることが重要
      • プロジェクトの本質とは「投資」
    • プロジェクトは「価値」を獲得するために存在している
      • 納期、品質、コスト、顧客満足度、技術などは、その「価値」を適用するための一つの成果に過ぎない
    • プロマネは与えられたプロジェクトからできるだけ多くの「価値」を引き出す方法を考えなければならない
      • そのために、企業に於いて求めるべき価値は何なのかを理解する必要がある
    • プロジェクトを通して求めるべき価値は、企業の戦略と無縁であって良いはずはなく、プロジェクトは企業の成長に貢献しなければならない
      • 戦略実現の一端を担う必要があり、プロマネは企業価値の創出に対して、プロジェクトがどの様に貢献できるかを考えなくてはならない
    • プロジェクトを企業、顧客、あらゆる側面から客観的に見渡し、成功の意味を考える
      • その成功を阻害する要因があれば、極力排除し、成功のための環境を整える
    • プロジェクトが開始する前の目的設定と環境作りこそがプロメネのやるべき最重要の仕事
  • プロジェクトはいろいろなことが学べる場でもあり、その場をうまく活用して人材を育成する
    • プロジェクトから人の成長という価値を意識して獲得する
    • プロジェクトからどれだけ多くの価値を獲得できるかが勝負なので、プロジェクトの目的を広く捉えるほうが獲得できるチャンスがある
    • プロジェクトが人材育成の「場」ととらえ活動することにより、人はプロジェクトを通して成長し、人的資産が拡大することで、更に企業に価値をもたらしてくれる

開発メンバー

  • 技術的負債を支払う一番良い方法は、各イテレーションの終わりにどんな「ローン」を組むかを評価すること
  • 優秀な才能ある開発者でなくても、二流の開発者からでもなにかしら有用な物が得られると考えていますがこれは間違い
    • ソフトウェア開発では、今日プログラムされたものが明日の基板となる
    • 二流の開発者に基板を作らせてしまうと、本当に優れた開発者は前に進む前に、後ろへ戻って血管を修正しなくてはならない
    • 実際のところ、優れた人を加えるよりも、ダメな人をチームから外したほうが有益
  • 集中する時間を作る
    • 割り込み後に思考の流れを取り戻すには20分程度かかる
      • つまり、5分の質問も25分のコストとなる
    • 典型的な知識労働者は1日の28%を割り込みとその復帰に費やしている
    • 開発者の生産性は同時にやるプロジェクトが増えるたびに50%以上低下する
      • 開発者が同時に複数のプロジェクトに貢献しなければならないときには、別のプロジェクトにスイッチする前に、そのプロジェクトに丸2日は専念出来るようにする
  • 余計なコードが追加されるのは、拡張性を考慮しすぎたため
    • 拡張性は重要ですが、正しくやらないと逆効果になるおそれがある
  • さわって、動かして、やりとり出来る現物のソフトウェアの方が、要件を完全に記述したワードのドキュメントよりも何百万倍も優れている
    • できるだけすばやくコードを書いてユーザーに届ける
    • 重要なことは、もしユーザーが気に入らなくても、早く失敗できること
    • 遅く失敗するよりも早く失敗したほうが、ソフトウェアを見直して、再調整し、書き直すための時間が与えられる
  • ソフトウェアはそのライフサイクルを通じて絶えず変化する
    • 設計判断は初期の要求に基づいてなされる場合が多いが、新しい要求が出てくると突如、それは制約となる
    • 要求は納品後あまり変化しないや、要求はコントロールできるという妄想は誤った考えである
    • 要求は絶えず移り変わる物
      • ソフトウェアは変更可能である
      • ほとんどのユーザーは競争環境にいる
  • 成果物の部分的なコードの塊に分解して、それぞれが特定の機能を提供するようにつくることが非常に重要
    • プロジェクトを少しずつ納品するように調整し、事前に計画されたプロセスに従って他のメンバーが開発に取り掛かれるよう提供する
  • 成果物をうまく扱う
    • 想定していた作業が出来上がったら、一部のユーザーにそれを提供して、要件に従っているかを確かめる
    • あらゆる小さな成果物を段階的に用意し、それらを順次まとめてテストする必要がある

「実践 デザインシンキング」のまとめ

ものづくりに於いて考えるべきことがよくまとまっていてわかりやすい本でした。 デザインシンキング ■共感 他の人が感ていることを感じる ・目的 インサイト(気づき)の発見 ・ポイント 抽象的ではなく具体的な行動(いつどうしたのか) 行動→態度→価値観...