「見える化」というプロマネの仕事

「プロジェクトマネージャ(PM)の目的は何か」という問いには人によって表現は微妙に異なると思いますが、およそ「成功裏にプロジェクトを完了させること」ということになるでしょう。では「その目的の為にPMが行う作業(=手段)は何か」という問いにはどのように答えるでしょうか。もちろん、これも人によって、特に業種・業態やプロジェクトの特性によって表現は異なると思いますが、私が一言で答えを問われた場合には「見える化(=可視化)」と答えます。

もちろん、PMの仕事というのは究極的には「成功裏にプロジェクトを完了させるために、あらゆる手を尽くす」ということになるのですが、「あらゆる手」に共通するポイントというのが「見える化」なのではないかと考えています。とはいえ「見える化」して終わりという意味ではなく、「見える化」するところから始まるという意味です。念のため。

プロジェクト管理手法というのは数多あるのですが、どれもが管理すべき対象を見えるようにして状況を把握し、様々な手を打つための判断の手助けをしてくれるものだと私は理解しています。例えば、計画の見える化、タスクの見える化、スコープの見える化、スケジュールの見える化、コストの見える化、品質の見える化、リソースの見える化、リスクの見える化、コミュニケーションの見える化…などです。

なので、プロジェクトをマネジメントする立場に就いた場合には、いかなる形式であろうと、これらを「見える化」する、つまり具体的なドキュメントに落とし込むかツールに入力・表示するというところから始める必要があるということです。こういった作業は面倒くさいものですが、「見える化」する作業を省略していったい何をマネジメントするというのでしょうか。

よく、頭の中にはあるから(アウトプットしなくても)大丈夫だということを主張する人も見かけますが、実際にアウトプットしてみると意外と出来ないということが分かると思います。脳内に記憶できる情報量も限られているそうですので、全てを同時に、かつ瞬時に把握し合理的な判断を下すというのはどう考えても無理があります。まして、プロジェクトでは日々想定外の問題が発生し、常に合理的な判断を求められるのです。そのためにいちいち思い出しながら進めるというのは効率が悪すぎます。それにもしそのうちのいくつかを思い出さなかったとしたら、それはどういう結果を招くでしょうか。

ここまでプロジェクトマネジメントのイメージで書いてきたつもりですが、改めて考えてみると一般的な組織のマネジメントにも当てはまるのではないかと思っています。もちろん経営者は判断するのが仕事ですが、瞬時に的確な判断を行うために「見える化」が必要なんだと理解しています。


「さよなら、インタフェース」ゴールデン・クリシュナ 著

数年前、IT業界(…の一部)ではNoSQL(ノー・エスキューエル)というのが流行りました。いや、正直なところ、流行ったと言えるほど一世を風靡したかというとそれほどではない気もしますが、今回ご紹介する書籍はNoUI(ノー・ユーアイ)を提唱しているものです。「Noなんとか」っていうのが流行ってるんですかね?

2010年代に入って日本で携帯電話(ガラケー)一色だったモバイル業界の勢力図がスマートフォンによって一気に塗り替えられてからというもの、様々な面白いアプリや便利なアプリが登場し、それに触発されて(私も含め)猫も杓子もスマートフォンアプリの開発に乗り出すといった状況になりました。スマートフォンアプリの入門書が氾濫し、入門講座もあちらこちらで開催され、本業とは別にアプリ開発でお小遣いを稼いでいる人もいるのではないでしょうか。

最近ではIoT(モノのインターネット)というバズワードに支えられるように、スマートフォンをリモコン代わりにして家電を操作するアプリとか、家や自動車の鍵をスマートフォンで開けるアプリなんていうものも登場しました。確かにそれは今までになかったアイデアではあるものの、それって本当に必要なんだっけ?アプリありき、画面ありきになっていない?と本書では警鐘を鳴らしています。

もちろん、そういったアプリが本当に浸透するためには、単に物理的に操作するだけでは得られないメリットが提供されなければなりません。例えばシェアリングサービスでは部屋や自動車の鍵をソフトウェアで管理することで、物理的なキーの受け渡しや、返却後の無効化など、これまで制約だった点が克服される事例も出てきています。単に、物理を電子に置き換えるだけでは何のメリットもありません。

もう10年近く前になりますが、支援に入ったある企業で業務の運用管理ツールをオンサイトで開発していたことがあります。但し、私が最初から開発したのではなく、過去に在籍していた技術者が残していったツールが乱立していたというのが実情で、私はそれらを整理・集約しつつ、必要な新しいツールを作成していました。当時の依頼者のオーダーのキーワードは「ボタン、ポン!」、つまりワンクリックですべてが完了するというものでした。せっかくツールを作っても複雑な手順が必要だったり、誤操作しやすいUIでは効果も半減。手順書すら必要ないシンプルなUIが技術を知らないオペレータにとっては一番使い易いということを見事に言い表したフレーズだと思います。

本書の本質(と私が考えるところ)は、突き詰めて考えると、「みんながやっているから何となく」という理由ではなくて、きちんと考え抜かれたUIであり、UXを提供するように心がけて欲しいということなのでしょう。システムであれば1から10まで指示しなくても、ワンストップで完結するのがベスト。アプリだってUIだって無くて済ませることが出来ればそれに越したことはないわけです。その為にはどうするか?…というところに知恵を出す。それが新しいイノベーションを生むのではないでしょうか。


書名:さよなら、インタフェース
副題:脱「画面」の思考法
著者:ゴールデン・クリシュナ
監訳:武舎広幸
翻訳:武舎るみ
発行:BNN新社/2015年9月16日
ISBN:978-4-86100-993-8

「世界で一番やさしい会議の教科書」榊巻亮 著

ここ数年で「~の教科書」というタイトルの書籍が増えてきた気がします。「教科書」という響きからは学校の授業で使う教材をイメージしてしまうので、個人的には入門書の意味合いで教科書と命名するのはいかがなものかと思っております。なぜなら、教科書は浅いけれども必要なことは万遍無く盛り込まれていますが、「教科書」というタイトルが付けられた書籍には必ずしもそうではないものもあるからです。とはいえ、本書は社会人になりたての方々に会議の心得を身に着けさせるための適切なガイドブックと言えるでしょう。

皆さんは会議は好きでしょうか。おそらく出席して良かったと思える会議とそうではない会議があることでしょう。無駄だなぁと思う会議はいろいろありますが、「報告事項を報告者が口頭で発表し、参加者一人一人が手帳にメモする」というのがその最たるものかもしれません。そんなものは資料化して配布すれば済みます。また、「議事録を次回の冒頭で読み上げる」というのもあります。これは開催頻度にも依りますが、例えば1か月前の議事録を次の会議で確認するというのではさすがにスピード感がありませんし、思い出すのも疲れます。議事録は開催直後に配布して認識を合わせておくべきだと思います。

私はどれだけの会議に出席したかは把握していませんが、社会人1年目の時に出席した会議が原体験となっているような気がします。当時はPCが一人一台という状況では(少なくともその職場では)なかったですし、会議もPC+プロジェクタではなくホワイトボード(感熱紙にプリントはできる)を使っていました。会議の「いろは」も分かっていませんでしたが、誰が進行するかによって会議の質も異なっているということは分からないなりにも感じていました。会議の進行については師匠から種々の心得を叩き込まれまして、いつの間にか難なく会議をこなせるようになってきました。進行だけでなく、本書の前半に書かれているような立場で会議の成果を何とか見える形にしようとしてきました。

そんなこともあり、上で述べたような経験を通して私の会議術というのは磨きをかけて行ったものですが、一方では私が身に着けたことをどのように若い人たちに伝えたらよいかという課題があります。本書はその観点でも参考になる部分が多くありました。というのも本書では、「確認するファシリテーション」⇒「書くファシリテーション」⇒「隠れないファシリテーション」⇒「準備するファシリテーション」という風に徐々にステップアップできるように組み立てられているからです。この順序に従うことで、読者ひとりひとりがご自身の成熟度に合わせて取組むことができると思います。

ファシリテーションというといわゆるフレームワークやファシリテーショングラフィックのようなものを連想される方も多いと思いますが、そのような高度なものではありません。会議に参加する心構えを変えるだけなのですが、すぐに効果が出ることが期待できる内容だと感じました。会議を効率化したい、効果が出るようにしたいと思われている、あるいは、そのようなテーマで人に教えたいと思われている方には是非読んでいただきたいです。


 書名:世界で一番やさしい会議の教科書
 著者:榊巻亮
 発行:日経BP社/2015年12月15日
 ISBN:978-4-8222-7178-7

「図解 使える失敗学」畑村洋太郎 著

IT業界で仕事をしていると、様々なことが技術的な問題として片づけられやすいのですが、実際には人の問題であり、突き詰めると組織の問題だったということが往々にしてあるものです。担当者によってスキルはばらつきがあると思いますが、個々の担当者はレベルが高いのに失敗が起こるとしたらそれは組織の問題と捉えて良いだろうと考えています。

多くの場合に失敗は現場で顕在化するため、組織は現場の問題として片付けたがる傾向がありますが、もし問題の根っこがプロセスや組織にあるとしたら、現場の問題、個人の問題として扱っている限りは失敗は無くならないでしょう。それ以上現場の担当者を責めても励ましても効果は上がらないと考えるべきです。

「失敗学」といえば元々は製造業界や建築業界で発生した事故の分析というイメージがありますが、今ではそこに留まらず幅広く組織で発生するトラブルを分析されているようです。本書は、失敗学を紹介する本ではなく、そんな失敗学の研究の成果を個人レベルで実践できるようにアレンジされたものです。見開きで右ページの本文と左ページの図解がセットで1つのトピックとなっており、読み進めやすく構成されています。

大まかな章立ては次の通りです。

  1. 失敗との向き合い方(個人レベルでの)
  2. 失敗の発生原理と知識化
  3. 失敗からの学び方(失敗を成功に変えるには?)
  4. 失敗学を組織に応用する方法

こうして見ると、最初は確かに個人レベルの話なのですが、最後は組織レベルの話になっています。担当者一人一人が担当者としてスキルアップすることが、必ずしも組織としてレベルアップすることと等価ではなく、行きつくところは組織レベルでの取組みが必要だと理解しました。本書にもあるように「組織としての失敗対策はトップダウンしか為し得ない」ということです。

失敗についての情報はどうしてもネガティブなものとして捉えられ、蓄積や活用が進みにくいものです。特にトラブルの直接的な引き金になった担当者であれば尚更だと思います。そういうこともあり、組織のトップが率先して現場の失敗情報を吸い上げ、それをまた各現場に下ろして組織全体に行き渡らせるといった取組みが必要なのだと考えています。


書名:図解 使える失敗学
著者:畑村 洋太郎
発行:中経出版/2014年7月31日
ISBN:978-4-04-600238-9

情報処理技術者試験・受験者としての総括

この年末に向かって目まぐるしい毎日を過ごしている中、この秋に受けた情報処理技術者試験の結果が18日に発表されたそうで、遅ればせながら先ほど確認したところ合格していました。おかげさまでこれにて論文試験はアガリです。なので、ここで情報処理技術者試験への受験者としての取組みを総括したいと思います。

今回受けた区分はSA(システムアーキテクト)で、実は3回目の受験でした。1回目は平成17年秋のAP(アプリケーションエンジニア、SAの前身)で、準備不足もあり論文もうまく書けなかったという記憶しかありません。2回目は平成24年のSAで、ここでもシラバスで定義されている人材像をうまく掴めずに論文もフォーカスがぼやけてしまったかもしれないと感じています。そういう意味では今回はそこを外さずに書き切ったという手応えがあったので、たとえこれで合格しなくても論文試験は終わりにしようと考えていたところでした。

試験制度や試験への個人の取組みついて賛否があることは承知していますが、新しい分野を学ぶ上でとりあえずの目標設定として利用するのは良いと思います。皆さんの中には会社からの奨めであるいは半強制的に受験している人もいらっしゃるでしょうし、合格すれば会社の給料が上がるあるいは一時金が出るから受験しているという人もいらっしゃるでしょう。もちろん、履歴書を飾るためだったり自己研鑚や試験そのものが目的の方もいらっしゃると思います。

私自身も振り返ってみると初めて情報処理試験を受けたのが平成16年の春(国の試験だとどうしても和暦になってしまいますね)でした。会社員時代には全く資格に無関心であったのですが――というのも、医者や弁護士と違って資格で仕事をするわけではなく、あくまでも実力勝負の業界ですので――独立したばかりで経歴といってもタカが知れている者に対してはどんな資格を持っているかぐらいしか見てもらえるところが無いという現実もあり資格試験に取組むことにしたのでした。

私の場合は「こういう仕事をやりたいからこの資格を取る」という取組み方よりも「こういう仕事をやったからこの資格は取れる」という側面の方が強かったせいもあり、全区分を制覇しようという気持ちにはなれませんし、試験に取り組むことで自分の弱点も分かったので、3回受けてダメだったものは無闇に前進するのではなく一旦棚上げするようにしています。来年春の試験で最初の受験から十二支も一回りすることですし、そろそろ未知の分野に手を出して、アイデアの幅を広げていく事を考えていきたいと思います。


最近の排ガス不正、施工データ偽装事件に思う

ドイツの大手自動車メーカーであるフォルクスワーゲン社(VW社)の排ガス不正問題はまだ真相究明に至っておりませんが、最初にニュースを聞いた時には正直驚きました。それは「あのVW社が」というポイントであって規制逃れの手法そのものに驚いたわけではないのですが、そうこうしているうちに、今度は横浜市のマンションの傾きの発覚により施工データの偽装が明らかになりました。いずれもまだ問題の全容が見えていない段階ですので詳しい言及は避けますが、なんとなく似たような臭いを感じます。

特にVW社による不正の類は、IT業界では大なり小なり割とある話なのではないかなと思います。VW社の場合は市場に出してしまったのでかなり大きな問題になっていますが、リリースまでには直す前提で、例えば工程完了判定をパスするために不具合があっても検査に合格したことにするということは、実際にやるかどうかは別として簡単に出来そうなものです。ですので、テスト結果を鵜呑みにするのではなく、あるいはテスト結果だけを評価するのではなく、どのようにテストしたのかというテストのプロセスを評価するような仕組みが必要になってきます。

あるシステム開発でテストの自動化を導入した時のことです。開発チームではメンバー間で生産性や品質にばらつきがあるのは普通のことですが、全体として短納期で高品質を求められた結果、あるメンバーはそれがプレッシャーになったのか自動テストのコードはスカスカで、本体のプログラムは全くダメという状況に陥ったことがありました。この時、自動化したのは単体テストのみで、結合テストは通常通り手動で行うことにしていたのですが、単体テストの時はテスト結果が毎日OKとなっていたので問題ないように思われたのですが、結合テストになって初めてその品質の悪さが露呈したのです。この時はその人の書いたプログラムはほぼ作り直しで、納期には何とか間に合ったものの、当人以外のリカバリーを担当したメンバーは大変な思いをしました。

テスト駆動開発という開発手法も存在しますが、いずれにせよ合否の基準が最初から決まっている場合、エンジニアはその基準に合わせて開発を行う傾向があります。これは何もシステム開発だけではありません。会社の人事評価も同様です。会社が良かれ悪しかれ定めた基準によって、社員はその行動パターンを決定します。例えば、基本給は横並びだけど持っている資格に応じた手当を継続的に出すよということにしたとしたら、多くの社員は本業はそこそこに就業時間中に資格取得のための勉強に励むでしょう。

話を戻してソフトウェアの場合、予めテストの合否基準が決められていることで、効率的に開発を進めることができる部分があるのかもしれませんが、それで全てがうまく行くわけではないという至極まっとうな教訓が得られました。チーム全体が意欲的な場合にはうまく行くが、そうでない場合は特に、人には失敗を隠そう、ごまかそうとする性質があります。VW社の不正も環境負荷の少ないエンジンが供給できず、それを隠すために不正なソフトウェアを組み込んで試験を通そうとしたようですし、施工データの偽装も担当者が失敗を隠すためにデータを偽装したとの報道がなされました。今後全てのことが明らかにされた時、また新たな教訓が得られることと思います。
—-

リクルートの口ぐせ・R85に学ぶ

日付が変わってしまいましたが、本日(24日)はIC協会の月例セミナーに3カ月ぶりに参加してきました。今回のテーマは「リクルートの口ぐせ 出版記念セミナー」ということで、書籍『「どこでも通用する人」に変わるリクルートの口ぐせ』を執筆されたR85と呼ばれるリクルート社1985年入社のOBらをパネリストに迎えてのパネルディスカッションが行われました。

私がIC協会に入会したのは2006年末でしたが、正直なところそれまでは「リクルート」という社名及びその商品しかよく知りませんでした。しかし、入会後、今回のようなセミナーを通じて知り合った方々はリクルート出身者が多く、お一人お一人お話を伺っていくうち徐々にリクルート社に興味を持つようになりました。今回はそんな方々が在籍していた頃の内側の様子が聴けるのではないかと大変期待しておりました。

書籍の方には全部で32項目の「口ぐせ」が掲載されているのですが、企画や編集段階で残念ながら掲載を見送ったものもあったそうで、そういったいわゆる「場外」の口ぐせをいくつか披露していただいたのですが、むしろそちらの方が聴き応えがあったかもしれません。

全体を通して私が特に気になったのは次の2つです。

「何をやるか」は重要じゃない

「仕事は選べないけど、仕事に対する態度は自分で決められる」し、「会社に育ててもらうのではなく、自分の心で育っていくものだ」ということなのですが、これは納得です。色々と人のせいにするのは簡単ですけれど、自分の成長は自分で責任を負うしかないのですね。

「で?」(お前はどうするの?)

単純な状況報告をするとこのように切り返され、自分の考えを伝えるまでは何らのアドバイスももらえなかったというエピソードなのですが、逆の(上司の)立場で言えば、そうやって考えさせなければいつまでたっても考えられるようにはならないということですね。時間もかかるし忍耐も必要ですが、だからといって答えを教えてしまったのでは、相手が成長する機会を奪ってしまうことになります。

このように間近で具体的なヒントをたくさん聴くことができ、大変有意義な交わりのひと時でした。

つるむ安心、つるまない安全

先日、Facebookでシェアされていた記事をたまたま読んで、「これは」と思ったので私の思いを書いてみたいと思います。

(元の記事はこちら)
なにかを本当にはじめるなら一人ではじめよう

私は生まれ育ちが藤沢だったので、
江の島も片瀬海岸も
庭とまでは言わないにしろ
馴染みの深い土地であり、
この記事の舞台である
鎌倉海岸と似たような光景…
つまりいつもサーファーのいる海
というものを見ていました。
ただ、私自身はサーフィンを全くやらないので、
パッと見ただけでは
初心者か上級者かは判別は出来ないのですが、
上級者から見ると初心者サーファーは
海水浴客と同じとみなされるんですね。
かつてプロの料理人に
自炊は「ままごと」だ
と言われたことを思い出しました。

さて、一番気になったのは

サーフィンの場合、初心者なら上級者に連れて行ってもらうか、1人で行くかなんです。絶対ヤバいのは初心者数人で行くこと。

そして同様のことが「起業にも当てはまる」と
実例も交えて展開し締め括っている点です。

私は一人で起業してしまったので実感はないのですが、
状況はよく理解できます。
誰が言い始めたか知りませんが
「赤信号 みんなで渡れば 怖くない」
という川柳(?)があります。
これは言い得て妙です。
単独では自分の責任で行動するため
絶対にしないようなことを、
複数でつるんでしまうと
裏付けの無い変な安心感が醸成され、
元々そのつもりはなかったとしても
つい油断して判断を誤ってしまう、
そんな習性が人にはあるように思います。
後になって冷静にふりかえると
「何であんなことをしてしまったのだろう」
となりますが、
そうならないようにするためには
一人で取組んだ方が良いということのようです。

似たような話で、
会議にぞろぞろと大勢のメンバーを
連れてくる会社のことを思い出しました。
キックオフ的なイベントの場合はともかくとして、
スタートした案件の打合せでは
各社の担当者が集まれば済む話なのですが、
ほとんどの会社は一人ないし二人出席している中で、
ある会社だけぞろぞろとやって来るのです。
もっとも大きな組織になればなるほど
役割が縦割りになっているから
という言い分もあるでしょうが、
ぞろぞろやって来る本当の理由は
よく分からなくて一人だと不安だから
ではないでしょうか。
だからとにかく関係しそうな部門の人を掻き集めてくるのです。

この記事には
「どうして初心者でつるんで海に行ってはいけないのか。
…(中略)…初心者複数で行くなら、
ひとりのほうがよほど安全。」
とその理由が書かれていますが、
それを「どうしてよく分かってない人が
つるんで会議に参加してはいけないのか」
真似して書いてみましょう。

  • ひとりなら主体的に会議に参加する
  • ひとりなら事前に準備をしてくる
  • ひとりなら議論の流れに気を配る
  • ひとりなら後で社内に展開しようとメモする
  • ひとりなら判断できないことは保留する

これが複数になると…

  • 多くのメンバーがただいるだけの「お客さん」になってしまう
  • 何の準備もせず手ぶらで参加してしまう
  • 議論について来ない人が一人くらいいても平気
  • 他のメンバーがいるからと思ってメモしない
  • 判断が必要な場合、その場で内輪の議論が始まる

…と思いつくままに列挙してみましたが、
他にもぞろぞろ会議に参加することの弊害はありそうですね。
会議の場合、サーフィンのように
命に関わるようなことは無いかもしれませんが、
参加する人数分の成果が出ないようなことを
続けていけば業績に影響するかもしれませんね。


駄洒落と真面目に向き合ったセミナー

本日はIC協会の月例セミナーがあり、2カ月ぶりに参加してきました。本日は「爆笑する組織~人間関係を強くする『だじゃれ』仕事術~」というタイトルでのワークショップでした。駄洒落好きのワタクシとしては何やら楽しそうなテーマではありませんか。講師は一般社団法人日本だじゃれ活用協会(!)代表理事の鈴木さん。「だじゃれは世界を救う」というスローガンを掲げて駄洒落活用法のワークショップを精力的に開催していらっしゃる方です。何でも当初は企業向けの研修を中心だったのが、気が付けば専門学校生やら学童保育のスタッフやら幅広い層を相手に教えていて、ご本人も思いがけない展開だったとか。

駄洒落というとどうしてもイメージしてしまうのが「おやじギャグ」。どうしてもそういううっとうしい世界を連想してしまいがちなのですが、おやじギャグと駄洒落の違いは明白で、おやじギャグというのは自己中心(つまり思いついてしまったので文脈を問わずとにかく言わずにはいられない)であり、駄洒落というのは他者貢献(人を楽しませようとか、場を和ませようとか、とにかく相手のことを考える)であるということでした。

今回のワークショップは、駄洒落を仕事(例えばプレゼンテーションやチームビルディングなど)に取り入れるとどのような効果があるかというテーマでのグループディスカッションから始まりました。プレゼンテーションについては、「注意を引き付ける」「キャッチなことを言うトレーニングになる」「双方向のコミュニケーションを生み出す」など、またチームビルディングについては「伝えにくいことを伝える時に使えそう」「メンバー同士の距離が近くなる」「滑ってもいい=失敗してもいいという雰囲気が生まれる」などの意見が出ました。

説明の中で一番わかりやすかったのは「なでしこジャパン」の佐々木則夫監督が使った駄洒落の事例です。鈴木さんは「爆笑する組織」を著す際に直接佐々木監督に取材したこともあるそうですが、やはり駄洒落というのは無闇矢鱈に使うべきではなく、使う場面は選んでいるのだそうです。メンバーが緊張して固くなっている時はほぐすために使うが、逆に緊張感を維持する必要がある時は言わないといったさじ加減は肝に銘じたいですね。

セミナーの中では実践編として駄洒落をいかに素早く作り出すかといったトレーニングもあり、普段使わない頭を使った気がします。また、今日のセミナーでは範囲外だったのですが、参加者の方々は「スベった時の対処法」に関心が高かったようでした。確かにトラぶった時のための手先に打っておくというのはICらしい発想ではあります。著書では触れているそうですので、ワタクシも読んで勉強したいと思います。もし今後ワタクシが駄洒落を言っても温かく見守ってくださいね。

—-
一般社団法人 日本だじゃれ活用協会
http://www.dajare-zukai.jp/

「ハーバードはなぜ仕事術を教えないのか」佐藤智恵 著

本書はラジオで紹介されて興味を持ち、その日のうちに購入してしまいました。何が私の興味を引いたのか、それはタイトルに掲げられている問いそのものよりも、本書が書かれた趣旨だと思います。もしラジオで中身について触れられなかったら手に取ることはなかったでしょう。以前であれば「ハーバードなんて関係ない」とスルーしていたかもしれません。

タイトルにある「仕事術」ですが、これは組織の中で「部下として」成果を出すためのスキルだと言います。一方、ハーバードビジネススクールで教えていることは「上司として」成果と出すためのスキルなのだそうです。上司としてというとなんだか小難しそうに聞こえますが、何のことはない「リーダーシップ」について教えているということです。当たり前のことですが、いずれも「読めば身に付く」という類のものではなく、実践して時には失敗しながら会得していくものだろうと考えます。

本書は全部で120項目について書かれていますが、見開き2ページで1項目についての解説が完結しているのでスラスラ読めます。この120項目がリーダーシップについて網羅されたリストだとは言っていませんが、「なるほどそうだよね」とか「え、そうなんだ」とか、自分に欠けているものに気付かせてくれ、今後の学びのヒントを得られます。

例えば社内政治。私の想像では(自分がそうだからそう思うのかもしれませんが)きっと多くの人が遠ざけているものでしょう。しかし本書では、社内政治には良いものと悪いものがあり、社内政治そのものは悪くなく、進んで参加するように奨めています。ついでに言うと、この項目は「社内政治」についてだけではなく、偏見を捨てるべきであることを添えていますが、その点こそ記事の本質ではないかと思うのです。

本書もまた、字面だけ表面的に読めばそれでおしまいなのですが、本質に迫る読み方をすることで「悟り」すなわち成長につながっていくのではないかと思いました。

—-
書名:ハーバードはなぜ仕事術を教えないのか
著者:佐藤智恵
発行:日経BP社/2015年4月21日
ISBN:978-4-8222-5071-3