プログラマー、SEであれば、「仕様変更」という言葉には嫌な思い出しかないはずだ。 自分がプログラマーなら、一回作ったものを「仕様変更になったので、作り直して」と言われるのは嫌なものだ。 しかも1回だけならまだしも、やばいプロジェクトに配属されると、何度も何度も変更が入る。賽の河原ってありますよね。石を積み上げても積み上げても、鬼が崩してしまい、最初からやり直しになる地獄。アレと全く同じことがプロジェクトでも起こりうるのだ。 その気持がわかるので、仕様変更を言い渡す側ももちろん気が滅入る。しょうがないんだ。別にオレのワガママでコロコロ仕様を変えている訳じゃないんだ。分かってくれ・・。 仕様変更は気分が悪いだけではなく、お金の問題が絡むのでさらに厄介だ。プログラマーからすると、直すのはいいけど、修正にかかった工数分だけ、お金がもらえるのか心配だ。仕様変更を言い渡す側からすると、もう予算枠に余裕

育成型プロジェクトといって、コンサルタントである僕らが何でもやってあげるのではなく、お客さんのメンバーが中心となって慣れない変革に悪戦苦闘しながらすすめるタイプのプロジェクトを作ることが多い。 そういう状況だと色々とモヤモヤがたまる。なので定期的に「モヤモヤ相談会」を開いて、変革プロジェクトにまつわるアレコレを議論したりする。 先日のお題は 作業を見積もれと言われて困る。見積っても当たらないし。 この仕事をやらないわけにはいかないので、どうせ最後は「間に合うか？」じゃなくて「間に合わせる！」という気合しかないでしょ。 というつぶやきに応えて、見積もりの話をした。 ★見積は当たらないし、ますます当たらなくなっている プロジェクトの工数を見積って難しい。100人月クラスのプロジェクトではもちろん、ちょっとした作業が5時間なのか8時間なのかも結構ずれる。 ウチの新入社員研修ではモノづくりの演習で

今日は、1年やってきたプロジェクトのサンせットミーティングをお客さん、ソリューションベンダーさん、ケンブリッジメンバーが参加して（まる1日かけて）やっている。 ・これ良かったから、次のプロジェクトでもやろう！ ・これはうまく行かなかった、どうすべきだったか？ ・あなたの一言に救われました！ みたいなことを議論したり意見交換する場だ。 今回はプロジェクトをやってきて、 ・驚いたこと ・楽しかったこと ・つらかったこと ・現時点でまだ不安なこと の4点をまず全員でリストアップしたのだが、面白かったのは 「トラブル対応や課題解決でわくわくした」という意見がたくさん挙がったことだ。 結構チャレンジングなプロジェクトだったので走りながら計画を作るような状況もあり、それなりに厄介な課題は発生した。でもいがみ合うこともなく、関係者全員で課題やトラブルに立ち向かえた。「これって普通のことじゃないよね」と、

12月に出した新刊「リーダーが育つ 変革プロジェクトの教科書」では、僕らがお客さんとやっている「育つプロジェクト」とはいったいどんなプロジェクトなのかを最初に示した。 1章では住友生命さんとやった青空プロジェクト（携帯端末づくりを通じて、営業職員さん達の仕事を抜本的に変えるプロジェクト）の事例を、なるべく生々しく書いた。書いた当人としては「大きな会社だし、ここまで書いても大丈夫かな？」というくらい筆を滑らせたのだが、寛大にも、ほとんどそのまま本にさせていただいた。なので読んだ人にはイメージはバッチリ伝わると思う。 もう一つ、育つプロジェクトのエッセンスとも言うべき10の原則をまとめ、2章に掲載した。多くのプロジェクトをやり、振り返りミーティングで「どうしてこのプロジェクトでは人が成長したのか？」を議論してきた集大成とも言える。 先日、本に登場していただいた住友生命の岡本さん（1章、10章）

2018年8月7日、我が師匠ジェラルド・M・ワインバーグが亡くなった。 あなたには師匠がいるだろうか。僕には2人いる。 僕がよりによってリーダーシップについての本を書いているその最中に、僕のキャリアをリードしてくれたワインバーグ師匠が亡くなった。一言も会話をかわさず、ひと目も会わないうちに。 ワインバーグ師匠について形ばかりの紹介をすると、 ・アポロ計画に関わった、最初期のプログラマー（アポロの前のマーキュリー計画らしい） ・コンピュータシステムと人間関係の密接な関係を最初に指摘 ・狭義のコンサルタントのはしり ・作家 ・文章の書き方の指南者 といった具合だろうか。 彼がいなければ、僕はコンサルタントではなかっただろう。 コンサルタントという名刺を持った何者かではあった。だが、彼の本を読む前の僕は、コンサルタントと「良いSE」の違いすら分からなかった。 彼の「文章読本」を読まなければ、僕は

土曜日にIIBA（ビジネスアナリストの団体）のイベントで講演し、日曜日はグラフィックファシリテーションフォーラムという場を一参加者として覗いてきた。 2つのイベントともにやたら熱心な人が多くて、すごく盛り上がっていた。IIBAのイベントは登壇側なのでまあいいとして、この記事ではグラフィックファシリテーションのイベントに出てつらつら考えたことを書く。 僕はファシリテーションを18年やってきて、その中で当然「議論の可視化することの意味、つまり書くことってすごく有用だよね」を信じている。だから近年グラフィックレコーディング（以下グラレコ）が盛り上がっているのを、すごく嬉しく思っている。広い意味で同志だから。 一方で、「書くことでファシリテーションする」と言ってしまえば同じでも、僕らケンブリッジがやっているのはその中でも非常に偏った活動だと思っている。この図で言うと右下の端っこ。 汚い字でスピード

思考停止という現象に興味があり、以前からそれについてのアンテナを立てている。 人間は本当に思考を面倒くさがる。だから思考停止が許される言い訳ができると、それに飛びつくように見えることすらある。もうそれ以上考える必要がなくなって、ホッとしているみたいに見える。 注意深く観察していると、「ああ、この人は思考停止しているな」というのはわりあい分かるものだ。 ただしそれはあくまで「他人から見ると分かる」という話であって、当人にとっては全く逆だ。なにしろ思考が停止しているので、「今、ひょっとして、思考停止している？」とは中々気づけない。もちろん僕自身もそうだ。 だからこそ、思考停止は怖い。知らず知らずのうちにきちんと考えることを放棄し、その場の空気なり、決定事項なりに流されてしまう。そうして、後々問題が起きてから「あの時もっと良く考えておけばよかった」と後悔する。または上司に「これくらいのこと、考え

休暇中にメールをチェックする人は怠け者である。 僕は怠け者ではないので、休み中はパソコンを開かない。が、うちの社員もお客さんも、休み中にメールをチェックする人は多い。僕はそういう人に「やめたら？」とよく言うけれど、意見を採用されたことはない。 オーストラリアで仕事をしている僕の従兄弟は、平気で1ヶ月くらい日本に帰ってくる。しかもちょくちょく来る。「仕事どうなっちゃってるの？」と聞いたら、「いや、日本にいてもリモートで大抵のことはできるから、最低限はやってるよ」と。こういうケースならば、休暇中にメールチェックするのもありだろう（というか、休暇扱いではないのかも・・）。 でも、日本人の休みなんてせいぜい9日間くらいのものだ（5日休んで平日埋めて、両方の土日をくっつけると9日になる）。僕も今年の夏休みは9連休だった。もっと短い人も多いだろう。 で、1週間くらい仕事のことをきれいサッパリ忘れられな

ファシリテーションを説明する際に「人々から意見を引き出す」みたいなことが言われる。 課内会議で課長ばっかりいい気分で喋っていて（あるいは怒鳴っていて）、後の人はうつむいて聞いている、という会議に比べて、ファシリテートされた会議は新人からベテランまでまんべんなく意見を言って・・みたいなイメージだ。 その通りなのだが、肝心の「引き出すためのテクニック」について、僕はこれまであまり説明してこなかった。人の意見を引き出すって難しいですよね。 ★意見の引き出し初級編 ・「○○さんはどう思いますか？」と指名して発言を促す ・「意見を全員付箋に書いて、張り出してください」というやり方で、発信が偏らないようにする あたりが基本中の基本だ。 これらは主に、発言者の偏りをなくすために使うテクニックだ。 でも、本当に難しく大事なのは、下記の「考えていることの微妙な違いを引き出す」ほうだ。 ★考えていることの違い

毎年この時期になると新入社員に、仕事にまつわるあれやこれやの話をする。僕はこういう時に、5年10年先を考えてテーマ選定する。つまり「ピンとこないだろうなぁ。でも何年かしてから思い出して、助けになったら儲けものだなぁ」というノリ。 いくつかのテーマは大事なので毎年同じ話を繰り返す。ただ、それだけだとこっちも飽きるので、1つや2つは新ネタを話すことになる。 今年、「これは5年後と言わず、仕事を始めるまえにきちんと伝えておいたほうが良いな」と思った話がある。この記事はその書き起こし。 ******** 仕事って難しいので、悶々と悩むことはある。ある程度は仕方ないというか、悩んで成長していくものだとは思うのだが、危険な悩み方もある。 それは、自分で自分のことを「全然ダメだ」と決めつけた上で、「会社に貢献できてないので、いるべきじゃない」となどと思い詰めてしまうパターン。 一緒に働いている人々は頼り

プロジェクトリーダーとプロジェクトマネージャーの違い、あるいは会社にとって死活的に大事なのはどちらか？ 2015年12月に「会社のITはエンジニアに任せるな」という本を出した。 「経営にとって、ITとは？」がテーマの本なので、「ITを担わせる人材をどう育てるべきか？」という章をもうけたのだが、意外だったのは、「プロジェクトリーダーとプロジェクトマネージャーの違い」という短いコラムへの反応が多かったことだ。 実は用語の混乱を避けるために書いただけなのだが、結構本質的な問いかけも混ざっている。この記事で、少し掘り下げてみたい。 ※以下、プロジェクトマネージャー⇒PM、プロジェクトリーダー⇒PLと表記する ★何が混乱の元なのか？ 大きめのプロジェクトだと、たいてい体制図が作られ、色んなカタカナの役職の人が登場する。ただ、この手の役職名は会社ごとに定義がマチマチなので、毎回関係者間で「これって結局

綺麗ごとを追求すると会社は儲かる。あるいは「会社が儲かっているなら綺麗ごとを言える」じゃないということ しばらく前のことだが、うちの会社のWebサイトにプロジェクト事例が2つアップされた。 スミセイ情報システム株式会社での育成プロジェクト事例 「自走で完遂」～三井製糖における業務改革プロジェクトの軌跡～ 目を通していただくのは後からでもいいのだが、まあ、なんというか、2つとも、とてもウチらしいプロジェクトだと思う。つまり、 ・ケンブリッジのノウハウを、お客さんに全て教えまくる ・その結果、お客さんは僕らに依存せずとも変革プロジェクトをリードできる力が身についた ・なので、ケンブリッジへ仕事を発注するのは途中でやめ、自力でプロジェクトを遂行した というストーリー。 ぶっちゃけこの2つのプロジェクト自体では、それほど沢山のお金を頂いてはいない（他のプロジェクトで別途お世話になってたりしますが）

「働き方改革」などと銘打って、「残業を減らそう！」が一種の社会運動みたくなっている。 特に日本は、知的労働者（ホワイトカラー）の生産性が特に低いと言われている。確かに自分を振り返ると「後から考えればなんだんだろう・・」という仕事もある。工場のラインでストップウォッチ持ちながら、最適な体の動かし方を研究しているのに比べれば、なおさら。 残業の泉（知的労働者にとって残業の元となっている行動）と思えるような仕事の仕方を6つあげてみた。 こういうスタイルで仕事をしていると、仕事は後から後から湧いてくる。まさに泉のごとし。 【１】ダメな予感とともにやる仕事 「なんとなくこのままやってもイケテナイんじゃないか？」の予感とともに、2時間くらいかけて、とりあえず完成させる。こういうことってありませんか？ 「とりあえず出来たんで見てほしいんですけど・・」 「うーん。これ、自分でイケていると思う？」 「イケて

先日ある方とバックオフィス社員の育成について議論していて、こんなマトリクスを思いついた。 経理や人事や法務のようなバックオフィス業務は、ルーティーンワークが多い。大企業ともなると非常に複雑で習熟に長い時間が必要な、難易度が高い仕事だが、「毎月、毎年ほぼ同じことを繰り返し、少しづつ改善していく」というタイプの仕事ではある。 一方で会社が激動期に入ると、バックオフィスだったとしても企画力や変革プロジェクトをリードする力が求められる。その方が嘆いていたのは、ルーティーン業務とは違う能力が求められているのに、新しいことをいざやろうとすると、リーダーになれる人が少ないことだった。 企業を生まれ変わらせるために、あんな企画もこんなプロジェクトもやりたいのに、リーダー不足でスピーディな企業変革ができない・・・。 僕はバックオフィスを対象とした変革プロジェクトを多くリードしてきた。 その現場にいてしみじみ

僕が会議で、同僚に一番怒りを感じるのは、発言すべき時に発言しないことだ。 （いま、この記事もその怒りに任せて書いている） ファシリテーションが下手くそなのはしょうがない。能力の問題だから。 資料がイケてないのはしょうがない。能力の問題だから。 発言の内容がアホなのはしょうがない。僕もアホなことをいうから。 そういう場合、お客さんに申し訳ないと思うし、改善は必要だからアクションはするが、怒りはしない。怒っても能力はすぐに上がらない（むしろ誰かが怒ると、周りの人の能力は下がる）。 でも、発言すべき状況で、情報をもっているのに口を開かないのは、仕事への姿勢の問題だ。 そして、とても危険なことだ。 例えば、プロジェクトではこんなことがよく起こる。 ・事実Aと事実Bを考慮した上で、方針βにきめた ・後から、コアメンバー以外の人が「Aという事実があるのだから、βの方針はおかしい。αにすべきだ！」という

僕は三枝匡さんの「変革三部作」の大ファンだ。 企業経営や変革プロジェクトのロジックとパッションの両方がぎっしり詰まっているので、今でもたまに読み返す。 ちなみにこの三部作を担当している日経新聞のの編集者に、僕の1冊目2冊目の編集もお願いした。特に1冊目は実際の企業変革を当事者が物語形式で振り返る本なので、「三部作の中間管理職版」だと思って書いた。三枝さんと違って、僕らの本はすべて実名だけれども。 その三枝匡さんがCEOとしてミスミの改革を振り返った本が出たので、早速読んでいる。 まだ途中だが今の時点で一番ぐっときたのが、 ・ビジネスの混沌を読み解き、「この課題って、要するにこういうことでしょ」と言え ・これは、企画書の1枚目（変革の出発点）として、極めて重要 ・これを言う人こそがリーダー（未来を示し、導く人）である という箇所。 似た話は工業デザイナーの山中俊治さんも書いていた。 自分の言

前に記事にしたが、ウチの会社では今年から「論文エントリー」という方法をはじめた。 面接偏重で学生さんを長時間拘束する、世の採用活動へのアンチテーゼと言ってもいい。 「大学で真面目に学問をやっていた学生を評価したい」という思いもある。将来コンサルタントになる人の適性として、知的好奇心に溢れているとか、一つのテーマをとことん考えるとか、そういう人が向いているからだ。 詳しくは先の記事を読んでほしいが、採用プロセスを簡単に抜粋するとこんな感じ。 ・エントリーシートではなく、これまで書いた論文、研究概要などをまず提出してもらう ⇒自己PRの作文とかは不要ということ ・電話で面談。提出してもらった論文の内容や、その研究における自分の役割を説明してもらう ⇒学問に忙しい学生さんに配慮し、リモートで行う ・来社してもらって面接 ⇒最後に1回は顔を合わせた方がお互い安心するでしょうし、ウチの社員にも会って

※長いです。本当に「人を育てたい！」と思っている人向けに、ガッツリ書きました。 ★学びのスイッチ 最近の学生さんはピンと来ないかもしれないけれども、むかし、講義はサボるものだった。安くはない学費を親に負担してもらい、わざわざ電車で大学まで行って、講義に出ないで食堂で喋ったりしていた。 勉強は単位を取るために、仕方なくするもの。 最小の労力で最大の成果を得たほうが生産性が高い訳だから、なるべく勉強しないで単位を取ったほうが賢い。 そんな価値観だった。 ところが多くの人は、社会人になって数年たつと勉強の必要性を感じ、いそいそとセミナーやら講演会に出かけていく。勉強熱心な人になると、ポケットマネーで夜間大学院に行ったり、有料のセミナーに出かける。 大学時代、僕より講義をサボっていた（そして同じく留年した）友人が、仕事と掛け持ちで大学院に行き始め、のけぞったこともある。 忙しい社会人になってから、

★なんちゃってインターンはウンザリだ 今年もインターンシップとして、学生諸君に1週間ケンブリッジに来てもらった。 インターンを始めてから数年経つが、その間ずっと、僕らのテーマは「なんちゃってコンサルティング体験会からの脱出」だ。 「インターンと称して学生さんを集め、普段の仕事ではやりもしないワークショップ形式の企画立案の真似事をやってもらって、いっちょ上がり」みたいなインチキインターンが世の中にはたくさんある。 場を仕切っているのは社員さんではなく、「インターン運営代行会社」だったりして、もうそうなるとその会社の何を体験することになるのだろうか？？ 僕らは本業がコンサルティングなので、ワークショップや企画立案は普段の仕事そのものだし、もちろんファシリテーターは社員がつとめる。それにも関わらず、インターンをやり始めた当初は、この手のインチキインターンに近い場しか作れなかった。偽物の体験会とい

ITエンジニアの多くは熱心なネットユーザーだから、ネットには「IT産業論」みたいな文章が溢れている。 大手SI企業を頂点とした下請け多重構造(ゼネコン構造)がおかしいとか。 若いうちからプロジェクト管理ばかりやらされてスキルがつかないとか。 自分を雇っている会社の担当者が無能な癖に指示がウザいとか。 今時〇〇をやらない某社は終わってるとか。 実に色んな意見があるけど、僕は、その手のマクロなIT産業論みたいなのにあまり興味が持てない。 正確に言うと、身近な産業だし、産業論自体は好きなので結構見聞きするけど、読んだあと「ま、どうでもいいんじゃね？」と常に思う。 というのは、「(広い意味での)IT産業って、人材の流動性が、日本としては稀なくらい高い」という特徴があり、マクロな産業構造がどんなにクソでも、ミクロ、つまり個人とか個々の会社としては、どうとでもやりようがあるからだ。 1)ITの世界では