サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
Pixel 9
blogs.itmedia.co.jp/magic
先日、slackで面白いやり取りがあったので、切り取って新卒社員向け即興トレーニングを作った。 「良いコミニュケーションとは何か?」がテーマだ。 現代企業でコミュニケーション能力が重視されている。採用活動の話題になると必ず「コミュ力」がキーワードになる。 世間でどう捉えているかは分からないが、僕が考えるコミュニケーション能力とは、仲間内でキャッキャウフフする能力ではない。立場やバックグラウンドの違う人々と意思疎通し、共同作業の土台を作る能力のことだ。 例えば先日ボランティア活動をしていた時に、30歳くらいの人が80歳のベテランボランティアさんに質問していた。それ自体は良いことだろうが、「あんた、早口過ぎてよく分からんな」と言われていた。 実際に彼の口調は50代の僕でギリギリ聞き取れるくらいの高速かつ滑舌の悪さだったので、あれで通じると判断している時点でコミュニケーション能力に難がある。 癖
先日、ゴールやコンセプトなど抽象的なことを考える際には、トップダウンアプローチではなく、くさび打ち込み方式でしか考えられないのでは?という話を書いた。 くさび打ち込み方式で本質を探る方法、あるいは目的から議論しない訳 めちゃくちゃ重要だがややこしすぎる話なので、理解してもらえるか心配だった。だが、意外と反響があった。 ・無理矢理トップダウンで考えていたので、反省してます ・自分も実はこういうやり方でやっています ・とはいえ、めちゃくちゃ難しい・・ などなど。 「ピラミッドの上(ゴールや戦略)から下(方針や戦術)へ考えるよね」という、世の中の常識に真っ向から反する意見であり、かつ直感にも反するので、この反応は結構嬉しかった。 気を良くして、同じように15年くらい前から社内でのみ提唱している、ややこしい話をもう一つ紹介したい。それは課題と施策を考える順番についての話だ。 世の中では「課題⇒施策
インターネットでは定期的に 「この会社(組織)はおかしい。自分が偉くなったら変えてやる!」 ↓ 「お前が権力を持つのは30年後だろ。そこまで待つよりはさっさと転職しろ」 みたいなやり取りがある。 僕はライフワーク的に「組織の中から組織を変える方法」について考えてきたので、これについて思うことを書いてみよう。 ※僕はコンサルタントなので「組織の外から組織を変える」を仕事としてきたが、実際には「組織の中から組織を変える人を支援する」という形を取るので、中から変えることについても関心が高い。そしてキャリアを通じてずっと、自分の会社を変えることをやり続けてきたので、当事者でもある。 「変えるには権力が必要。いまでも年功序列的な慣行が残る日本企業では、権力を得るために年月が必要」というのは、ある程度合理的に聞こえる。 でも結論としては、「偉くなったら変えよう」という姿勢は僕も駄目だと思う。 だがその
プロジェクトの成功や失敗とは何だろうか? これは僕にとって実に今更な問いだ。 会社のアイデンティティが「プロジェクトの成功請負人」というだけでなく、これまで本や講演などで幾度となく「世の中のプロジェクト成功率は驚くほど低い」「それでもプロジェクトを成功させるためには?」みたいなことを話してきたからだ。 プロジェクト成功率って低いものだよ、という話をしばしばするのは、非プロジェクト(定常業務とかルーティンワークと言ったりもする)とプロジェクトとでは、仕事の常識が全く違うからだ。これを認識しないと、そもそもスタートラインに立てない。 ごく簡単に言えば、「初めてやる難しい仕事」がプロジェクトなので、同じことを何度も繰り返す仕事(例えば毎月の給与計算や四半期ごとの決算や棚卸しなど)と同じようなスタンスで臨むととんでもないことになる。 プロジェクトの成功率が低いという話でよく引用する日経コンピュータ
この夏に出版した「社員ファースト経営」は社員を中心とする新しい経営スタイルを紹介した本なのだが、それは同時にファシリテーション経営の本と言っても良い。 というか「社員ファースト経営」と「ファシリテーション経営」はコインの裏表とか、車輪の両輪というべきセット概念なのだ。 だから本のタイトルも「ファシリテーション経営」にしよう、という意見もあった。そちらのほうが売れたかもしれない。 「社員ファースト経営」についてはこれまでもブログに書いてきたし、字面から推測しやすいのだが、「ファシリテーション経営」は分かりにくい。検索結果をさっと見たところ、あまり真剣に論じている人もいなさそう。 ということで、どういうものなのか、このブログで紹介しよう。 ★元々は会議の延長 狭義のファシリテーションは「会議をうまく進行し、皆をコンセンサスに導く技術」というような意味だろう。もちろん僕らはこの意味でもファシリテ
日本電産で大量退職 元幹部社員が告白「永守重信会長への過剰な忖度が蔓延している」 https://www.moneypost.jp/999170 という記事が大変話題になっていた。 もちろん僕は中の人ではないので、内容の妥当性については分からない。でも、いかにもありそうな話ではある。 日本電産にかぎらず、昭和の文化を引きずっている企業であれば、この記事で描写されている現象は、多かれ少なかれ起きている。 日本電産には永守さんという偉大なカリスマがいるために、その傾向が極端なのだ。もはやコミカルなレベルで極端。 さらに偉大なカリスマはまだ権力を握っているので、この傾向がいまでも温存されている。多くの会社は平成の30年間で少しずつ脱却したのに。 そういう意味で、「中のことは分からないけれども、いかにもありそうな話だなぁ」と思いながらこの記事を読んだ。 この記事から読み取れる「伝統的日本的経営のマ
ツイッターを眺めていたら、見覚えのある表紙が。 この本の著者、エンジニアに対して相当ツラい経験があったんだなと推測される pic.twitter.com/Dw0BfmQYL8 -- コミさん (@komi_edtr_1230) June 27, 2022 どなたか分かりませんが、どっちかの本を見かけて、著者の別の本も検索して・・と、ありがたいことです。 もちろんこのタイトルから、エンジニアに対する敵対的な(侮蔑的な?)匂いを感じ取ったんだと思います。まあ、そりゃそうですよね。そういうタイトルです。 このツイートへのリプライ欄も見てみると、 ・左側の本は読んだことありますが良い本でした。たぶん個人的な恨みではなく編集者側のマーケティングではないかと思っております ・タイトルは半分釣りですが、内容はまともで良書ですよ ・この本、本当に面白いからもっと多くの人に読んでほしいなぁ(私が読んだのは会
ずいぶん昔のことだが、Facebookでこんな投稿を見かけた。ドライブの効いたいい文章だったので、思わず保存してあった。 最近許可をもらったので、ほぼそのまま転載させてもらう。 昨日はバタバタと1日が過ぎた。 変なお客さんに絡まれて、全く仕様のわからないシステムの構築を4ヶ月でやるように言われ見積もりをすぐに出せと言われる。 急に呼び出された打ち合わせには前の上司だった人と伺った。それが月曜日。そして、オマエにこの仕事断る選択肢は無いからなと一緒に行った隣の部長に凄み、私には、オンナにこのプロジェクトは無理だからもっと仕事できる男性連れてこいとのこと。 阿呆らしーと思いつつポイントまとめた前任者が作ったとてもよい資料があったので工数は積み上げして見積もったら割と妥当な感じの見積もりが出来上がってしまった。いかん、このままだとこの仕事私が見ることになる。 うわーどうしようと思ったのが0時を過
文章術や本の書き方みたいな本を読むと、 まず骨子(あらすじ)を書き、それをブレイクダウンして文章に落としていきましょう。 などと書いてある。ありゃ嘘ですな。 ・骨子⇒章立て⇒節にブレイクダウン⇒文章化 という流れは、一見合理的で、正しそうに見える。 この考え方は、システムをウォーターフォールで構築する時の ・要求定義⇒要件定義⇒基本設計⇒詳細設計⇒プログラミング という流れとそっくりなので、このブログではウォーターフォール文章術と呼ぼう。 ★ウォーターフォール文章術の実態 実際にウォーターフォール文章術で書かれた本はたくさんある。だが、面白い本にはならない。 これまで「本は理論構成や骨子が大事なので、まずは章立てをしっかり固めるべきだろ」「君の書き方は枝葉末節にこだわりすぎるし、効率も悪い」「しっかりブレイクダウンしていかないと、支離滅裂な本になってしまうぞ」などと僕に説教をしてくれた人は
プロジェクトでSIer(システムインテグレーター)とご一緒することは多い。たいていは、システムを作ってくれるSIerをお客さんと一緒に選び、上流で構想したシステムを作ってもらう関係性だ。 かれこれ25年SIerさんとお付き合いしているが、いくつか解けない謎がある。その一つは、 「なぜ営業と開発が分業しているのか?」 である。 ツイッターなどでは昔から ・営業が「何でもできます!」とお客さんに風呂敷を広げる ・それに不平を言いながら、徹夜して対応するエンジニア という愚痴が見聞きできる。 不思議なことにエンジニア側からのコメントばかりで、営業側の見解が見られない(これは、エンジニアの方がツイッターで仕事の愚痴を言う習慣があるからかも・・)。 とは言え、SIerで仕事した人はみなこれに似た経験があるだろう。 ちなみに、僕が就職活動した時はもっとひどかった。 あるSIerの先輩にOB訪問した際、
1年くらい前から、オンボーディングに力を入れている。 オンボーディングというのは、新入社員を迎え入れ、活き活きと、バリバリと働いてもらうための活動のことだ。 創立以来、多くの毎年中途/新卒が入社してきたが、僕らケンブリッジは、このオンボーディングが下手っぴだと思っている。育成としてノウハウを叩き込むのはうまいのだが、その人の元々の良さを活かすのが下手なのだ。 それを反省して、ボランティアでオンボーディングの担当チームを組成した。彼らを中心に、受け入れ体制を整えている。 で、彼らと「新入社員がすぐに会社に馴染むには?」と議論していく中で、僕らが今後大切にすべきことがいくつか見えてきたので、紹介しよう。 (オンボーディングの対象は新卒社員も含まれるが、ケンブリッジで特に課題感があるのは中途入社なので、以下、中途前提に書いていく) ★オンボーディングで大事なこと1:Welcome感 まず当たり前
★日本でのアジャイル 日本にアジャイルが紹介されて20年近くたった。webサービスやアプリ開発では標準的な開発手法になっていると思う。一方で、エンタープライズ領域(大企業で基幹システムなどを作るプロジェクト)でアジャイルを適用しようとして大失敗した、という話はたくさん聞く。そもそも「アジャイルなにそれ?」という大企業も多い。 これはアジャイル発祥の地である、アメリカの状況とはかなりギャップがある。 ケンブリッジのアメリカ支社に、長くアメリカ企業でシステム部門のマネージャーをしていた社員がいる。彼に「ねえ、日本ではアジャイルがうまく導入できていないんだけど、アメリカではどうなの?」と聞くと、「え?普通にもうアジャイルがスタンダードですよ」という答えが返ってきた。ですよねぇ。 日本でアジャイル開発がうまくいかないのは、商慣習がアジャイル向きではないからだ。(どの商慣習が合わないのかは、以下で説
人の優秀さとか、一緒に仕事しやすいか?をはかる目安として「知りません」「分かりません」がすっと出てくるか?というのがある。 ★「分からん」がすぐに言える人のいいところ なんのてらいもなく「分からん」「知らん」が言えるということは、「世の中に自分の知らないことがあるのは当たり前」「難しい問題解決にチャレンジしているのだから、分からない状況は恥ずかしいことではない」という姿勢ができているということ。 これは知的営みをする上でのスタートラインだと思う。 そして仕事の場でも「知らん」を言える人は「オレは知識ではない別な何かで勝負している」という自信が恐らくあるのだろう。知識の価値が低下しているこの時代、悪いニュースではない。 「分からん」を言える人も、かなり自分の知性に自信があるひとだろう。分からないのは自分の知性が不調だから、というよりも別な理由(相手の説明が分かり辛すぎるとか、情報が足りていな
ウチの会社のビルでエレベーターの工事が始まった。 しばらく前から予告の張り紙が貼ってあったのだが、これにコミュニケーションの専門家として物申したい。 この張り紙は情報量を97%くらい削減すべきだ。 工事する人がユーザーに伝えたいことは恐らく以下のメッセージ。 1)もうすぐ工事やるから、しばらく堪忍な。 2)エレベーター1機ずつ工事するから、全く使えない事態にはならんから安心してな。 それ以外に掲載されていることは、全てノイズであり、情報の価値としてはマイナスだ。エレベーターは2機あるので、1機が止まったとしても、「ちょっと不便になるけど堪忍してね」というだけの話で、詳細な日時などに関心がある人はいないだろう。 工事の詳細について知りたい特殊な人もゼロではない。例えば近々引っ越しや大型機材の搬入を予定しているとか。だがそういう人はどうせ、別途管理人さんとコミュニケーションする。張り紙としては
知的労働に勤しんでいる皆さん、1日何時間働いていますか? 僕は8時間くらいだと思う。長くはない。30代前半までは13時間くらい働くのが普通だった。 意図的に短くしている。なぜかというと、「本当に頭を使う仕事は6時間以上できないのでは?」と思い始めたからだ。 きっかけその1) 本を書くときは、温泉宿に籠もって書くことが多い。 というといっぱしの文豪気取りに聞こえるかもしれないが、逆だ。本当にプロの作家ならば日常として淡々と執筆する。僕にとって執筆は本業ではないからこそ、モードを変えて人参をぶら下げらないと、自分にキックが入れられないのだ。 で、そういう時は執筆⇒温泉⇒執筆⇒温泉⇒昼飯⇒執筆⇒温泉、みたいな感じになる。せっかく泊りがけで来ているのだからさぞかし長時間書きまくるのかと、自分でも期待して臨む。 でも、どんな時も6時間しか書けない。むしろ調子がよく、集中できた時こそ6時間が限界になる
昨日もある社員と1on1ミーティング(白川と1対1で小一時間、キャリアや今の仕事についてしゃべる場)をした。 「あんまやりたくない仕事ってどんなの?」と僕が水を向けたら、「基本的にどんな仕事でも学ぶことはあるし、楽しんでやれちゃうタイプです。でも、局所的にしか役に立たない知識やスキルしか身につかない仕事は、イヤですねぇ」と言っていた。 とても共感する。 このブログではその手の「局所的にしか役に立たないスキル」をガラパゴススキルと名付け、少し考察していこう。 ガラパゴススキルで分かりやすいのは、金融業界におけるIT特有の知識や習慣などが該当するだろう。セキュリティがガチガチ過ぎて、今どきのSaaSを使った開発から全く無縁、というのもそれに近い。金融ITガラパゴスとでも言おうか。 もちろん金融業界で働くエンジニアの全てがそうな訳ではない(例えば本にもなったケンブリッジと住友生命さんがやった青空
システム構築プロジェクトの成功率は低い。 失敗する原因の多くが、 ・関係者が「あれもやりたい、これもやりたい」と主張し、収拾がつかなくなる ・必要性が薄い機能まで作ってしまい、コストオーバー ・いったん作る機能を決めたにもかかわらず、後のフェーズで変更が頻発する といった、要求定義にまつわるものだ。要求定義がシステム構築プロジェクトで最難関、最重要だと言われるのはこのためだ。 この問題に対処するため、僕らの会社ではFM(ファンクショナリティ・マトリクス)と呼ぶツールを使っている。 ご覧のように機能がずらずらと並んでいるので、紹介すると「こういう機能一覧なら、プロジェクトでよく作りますよ」という反応が返ってくる。 確かに本質的には機能一覧でしかないのだが、実はこの何気ない表が、システム構築で最大の難所と言われる要求定義(要件定義)を劇的にスムーズにする力を持っている。ひいてはプロジェクト全体
3年くらいかけて、ようやく「システムを作らせる技術」を出版することができた。 今週7/22が発売日だ。せっかくのオリンピック休暇なので、涼しいカフェでも行って読書に勤しんでみませんか! 僕は毎回違うテーマ、違う切り口で本を書いているのだが、仕事をしながら書いているので、それほどハイペースではない。だから毎回、執筆プロジェクトに着手する時には「本当にこれを書きたいのか?」「自分たちしか書けない本なのか?」「世の中にどういう貢献ができるのか?」をかなり考えて、テーマを選ぶ。 以下にこの本の「はじめに」を転載する。これを読めば、上記の問いへの解になっているだろう。 ※本書を読んで気に入り、「他の人にも勧めたいな」と思った人がいらしたら、まずは白川からの大感謝光線を一身に浴び、後にこの記事のURLをシェアしてみてください。 ****************** ★「システムを作る技術」ではなく「作
新刊「システムを作らせる技術」の発売前ではあるが、ウチの会社では早速この本の輪読会が始まった。ゲラのPDFファイルを使って。 「これからプロジェクトを始める仲間と、白川さんの本の輪読会をやっています。本を読みながら"では今回のプロジェクトではどうしたい?"と議論するのがいいんですよ」という話を何度か聞いたこともある。著者冥利に尽きる。 本の最後にも「この本を使って輪読会をやるとよいよ」と書いた。 ウチの会社での輪読会のやり方をこのブログで紹介したい。 ★呼び方はゼミ もともとこの形式は、僕が大学で参加していたゼミの形式をまるっと真似したものなので、輪読会ではなく"ゼミ"と呼んでいる。例えば「業務改革の教科書」は社内で南極本と呼ばれているので、その輪読会は"南極ゼミ"だ。 他の大学についてはよく知らないが、僕の母校ではゼミをことさら重んじていた。もちろん必修。ゼミで卒論を書かなければ卒業でき
Twitterで「品質保証の歴史学」と題するスライドが回ってきて、同意しかなかった。 https://speakerdeck.com/nihonbuson/history-of-quality-assurance 特にこの一節。 プロセスを決めて守れば品質は「保証」できる、という欧米型品質保証的なクソのような幻想 このスライドで言う欧米型品質保証とは、ISOやCMMに代表される ・プロセスを紙に書き出す ・それを守らせる ・それを守っていることを証明するための紙も作る ・毎回、紙にハンコをつかせる ・それを監視する認定員みたいな人がいる ・そういう人にお金払う みたいなやり方を指している。とにかく書類が大好きですよね。書類フェチ。 僕自身は、ISOやCMMみたいなものには一貫して距離を置いてきた。 自分の会社で取得の旗振りをしたこともないし、顧客に勧めたこともない。 僕がこれらを一瞥した後
伝統的なSIerから、アプリを作ってる個人事業主まで、ITにまつわる仕事をしている全ての人は、もっと怒ったほうがいい。脅しにかかるヤクザ客に対してNOとはっきり意見表明すべきだ。 僕は普段から世の中に対して比較的ぷりぷり怒る方だと思うが、今回はそういう、ビールを飲みながらTVに怒ってるおっちゃんみたいな感じではなく、本格的に怒っている。 もちろん、デジタル改革担当大臣の件だ。 報道によると、 ・オリンピックで入国する外国人向けアプリの顔認証機能をNECが受注した ・ところが3月になってから、海外観客の受け入れを断念する方針に ・それを理由に、NECに支払う金額が73億円から38億円に大きく減額された ・その交渉のさなか、担当大臣がヤクザまがいの脅しを部下に指示した ということらしい。 その時の彼の肉声がリークされて、今回騒ぎになっている。 「このオリンピックであまりぐちぐちいったら、完全に
あまりに話題になっていたので「両利きの経営」という本を読んでいる。 雑にまとめると 「企業がイノベーションを起こしながら時代を超えて存続するためには、既存ビジネスを深化させることと、新規ビジネスを探索すること、この2つを両立させる必要がある。だが自然にはできないことなので、経営の強いリーダーシップが必要」 という内容だ。 だがこの本を読んでいる間ずっと、僕の頭を占めていたのは「イノベーションのジレンマ」は素晴らしい本だったなぁ・・。どの辺が素晴らしいかというと・・みたいなことだ。そればかり考えてあまり読書に集中できない。デートの最中に元カノの顔がチラつく的な? もしかしたら比べる相手が悪いのかもしれない。「イノベーションのジレンマ」は僕が自分で選定した「人生の50冊」に入っている、ものすごく好きな本だから。素晴らしさについて語り始めるととたんにキモくなると思うので、それは割愛する。 ちなみ
プログラマー、SEであれば、「仕様変更」という言葉には嫌な思い出しかないはずだ。 自分がプログラマーなら、一回作ったものを「仕様変更になったので、作り直して」と言われるのは嫌なものだ。 しかも1回だけならまだしも、やばいプロジェクトに配属されると、何度も何度も変更が入る。賽の河原ってありますよね。石を積み上げても積み上げても、鬼が崩してしまい、最初からやり直しになる地獄。アレと全く同じことがプロジェクトでも起こりうるのだ。 その気持がわかるので、仕様変更を言い渡す側ももちろん気が滅入る。しょうがないんだ。別にオレのワガママでコロコロ仕様を変えている訳じゃないんだ。分かってくれ・・。 仕様変更は気分が悪いだけではなく、お金の問題が絡むのでさらに厄介だ。プログラマーからすると、直すのはいいけど、修正にかかった工数分だけ、お金がもらえるのか心配だ。仕様変更を言い渡す側からすると、もう予算枠に余裕
ビジョナリーカンパニーシリーズが大好きで、読み返す度にブログになにか書きたくなる。 例えば・・・ 「規律を守るのが日本組織の強み」は嘘。あるいは本当に強い組織の規律とは? 果たせなかった五輪出場、あるいはHPのボーリング表示器に思いを馳せる 「やらないことを決める」をどこまでシビアに追求するか?あるいはウチのWebサイトのショボさをいつまで放置するか? 組織に5カ年計画やミッション・ビジョンは必要か?あるいは経営方針書について など。 全部で4冊(+α)でているが、経営者に一番人気があるのはビジョナリーカンパニー2(平凡な会社が飛躍する方法)だ。僕もこれが一番好き。というか、この本はウチの会社(ケンブリッジ)についての本だと思っている。 一方でビジョナリーカンパニー4について熱く語っている人には会ったことがない。2はもちろん、1と3を熱く語る人は知っているのに、4だけファンがいない。 なん
一緒に変革プロジェクトに取り組んでいるお客さんが、打ち合わせの後で「白川さんは敵なのか味方なのか・・・」と呟いていた、という話を人づてに今日聞いた。なかなか面白い。(本当は面白がっている場合じゃないのかもしれない。クビになる3秒前なのかもしれない) 今日はそれについてちょっと書いてみよう。 僕らが掲げているいくつかの価値観のなかにRIGHTがある。(写真はオフィスの壁に書かれたRIGHTの説明文) RIGHT 「お客様にとって、これがベストだ」と胸を張れることだけをする。 自社の都合ではなく、お客様にとっての正しさを愚直に考え、提言し、共に実行することが、私たちに誇りとエネルギーをもたらす。 正しさを追求できる環境の維持は経営のミッションであり、自分たちの利益、名声はその先にある。 僕らは20年来この価値観を大切にしている。今年「お客様にとって正しいことをする」という文言が入ったミッション
育成型プロジェクトといって、コンサルタントである僕らが何でもやってあげるのではなく、お客さんのメンバーが中心となって慣れない変革に悪戦苦闘しながらすすめるタイプのプロジェクトを作ることが多い。 そういう状況だと色々とモヤモヤがたまる。なので定期的に「モヤモヤ相談会」を開いて、変革プロジェクトにまつわるアレコレを議論したりする。 先日のお題は 作業を見積もれと言われて困る。見積っても当たらないし。 この仕事をやらないわけにはいかないので、どうせ最後は「間に合うか?」じゃなくて「間に合わせる!」という気合しかないでしょ。 というつぶやきに応えて、見積もりの話をした。 ★見積は当たらないし、ますます当たらなくなっている プロジェクトの工数を見積って難しい。100人月クラスのプロジェクトではもちろん、ちょっとした作業が5時間なのか8時間なのかも結構ずれる。 ウチの新入社員研修ではモノづくりの演習で
こないだ久しぶりに大学時代の友人RやYと飲んだ。 大学の前半の2.5年、僕はほとんどの時間を学園祭の運営委員の活動に使っていた。RとYはその時の仲間だ。学園祭がこんど50周年ということで、大先輩のOGが元委員に思い出話をインタビューして回っているという。じゃあ僕らで良ければ、と開かれた飲み会兼インタビュー会だった。 その時に「今仕事でやっていることって、学園祭でやってたことの延長なんだよね」「たった数年の学園祭委員の経験が、その後の人生に大きな影響を与えているよね」という話になった。 Rは学生時代フェスチーフという役職で、ステージ企画の元締めをやっていた。今は広告代理店に努めている。 Yは同じくシンポチーフという役職で、講演会やシンポジウム企画の元締めをやっていた。今は官僚だ。 学園祭に詳しくない人でも、なんとなくそれぞれの方向性が一貫していることは分かってもらえるかと思う。 学生の頃から
4冊目の本「リーダーが育つ 変革プロジェクトの教科書」の出版にまつわるタスクの息抜きに、個人的な話を。 たぶん僕は軽度の相貌失認なんだと思う。 相貌失認は、人間の顔を識別する脳の分野に欠陥があり、顔をきちんと識別できない一種の病気だ。でもいきなりなるわけではなくて昔からで脳の方も慣れていて、髪型や背格好や動作のくせを観察して、他人を識別するスキルで無意識に補完している(僕らは顔だけで他人を認識しているわけではないのだ!)。従って自分が相貌失認だと気づいていない人の方が多い。 僕がこの病気を知ったのは脳学者の池谷裕二さんの本で、ご自身も相貌失認だと書いていたのを読んだ時。 彼の本に限らず、脳科学の本は好きで何冊も読んでいる。脳の一部に欠陥がある人は環境を様々な形で認識する。例えば映画「メメント」の主人公は昔のことは覚えているのに、新しいことは5分しか覚えていられない。だから本当に大事なことは
日本企業にナレッジマネジメントブームが到来した時、その理論的土台になったのは野中郁次郎教授によるSECIモデルだった。1999年くらいのことだったろうか。 SECIモデルについては様々な所で説明されているのでここでは繰り返さないが、強引にまとめると「知識/知恵には暗黙知と形式知があり、その2つが絶え間なく変換されることで、組織で新たな知識が創造される」という考え方だ。 野中教授の著書「知識創造企業」では、家庭用パン焼き器を開発する際に、パン職人の匠の技(暗黙知)をパナソニック社員が模倣し、開発に活かせるように機械の仕様に落としていく様子(形式知化)などが描かれた。80~90年代前半は日本式経営がもてはやされた時代で、この本はその総まとめの様な位置づけにあたる。 僕は社会人なりたての頃にこの本を読み、組織で知識が作られていく様子の謎解きにワクワクしたし、日本企業のイノベーション力に感激した。
次のページ
このページを最初にブックマークしてみませんか?
『プロジェクトマジック:オルタナティブ・ブログ』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く