ITエンジニアのための仕事を速くする9の基礎力と7のエクササイズ : 賢者の図書館 (Under Construction) : livedoor Blog（ブログ）

キーワード：
　芦屋広太、プロジェクト、論理思考、書く技術、仕事術

仕事を速くするための方法が示されている本。以下のような目次となっている。

第1章　プロローグ会話で理解する「仕事が速い人」の特徴

基礎編　第2章　仕事を速くする9の基礎力

実践編　第3章　仕事を速くする7のエクササイズ

第4章　「仕事を速くする」説得・交渉のテクニック

第5章 リーダーのための「仕事が速いチーム」の作り方
(目次から抜粋)

この本のコンセプトは、「仕事が速い人を作る」、「仕事が速いチームを作る」という2点のみであり、その具体的な方法が示されている。そして、以下のようなことが示されている。

　筆者は、「仕事を速くする」ために必要なのは、個人が9つの基礎スキルセットと7つの応用スキルセットを習得すること、それを実務で実践することだと結論付け、さらにチームで力を発揮するためには別途チーム向けの「ルール」が必要なのだと考えています。本書では、これら「スキルセット」、「ルール」に関するコンテツンを、今日から実務でのそのまま使えるように取り上げています。
(pp.iii)

著者も実際にシステム開発やシステム統合、遅延プロジェクトの改善などをやってきた経験があるようだ。そういった観点から、実践的な方法が示されている。

まず、仕事を速くするための9つの基礎力とは何かというと、以下のようになる。

論理的思考力
理解力
構造化力
目的達成行動力
説明力
説得力
断る力
意見通し力
文書力

正直、論理的思考力から説明力に関しては、この本でなければ得られないものがある、ということはなく、他の本のほうが分かりやすいと思った。特に、論理的思考力、構造化力に関しては、『ロジカル・シンキング』、『考える技術・書く技術―問題解決力を伸ばすピラミッド原則』のほうがはるかに濃い内容で分かりやすく、ためになったと思う。また目的達成行動力も、仕事ハック系の本を読んだほうが良いと思う。唯一他の本と違うのは、例題がシステム開発関連となっている点。そういう部分にとっつきやすい人にはいいかもしれない。

しかし、説明力、説得力、断る力、意見通し力は結構参考になるところが多かった。特になるほどと思ったのは、断る力。これは、お客さんや利害関係者に諦めてもらうための6つの方法が示されている。

相手の主張を否定せず、まず肯定し、一緒に問題を解決する雰囲気を醸す
相手のニーズ、立場、スタンスを正確に把握する
相手に諦めさせる情報を伝える
断るための情報は、自分が経験したものを使う
説得力を高めるための話法を工夫する
相手が納得するまで情報を与える

例えば、相手に諦めさせる情報を伝えるための例としては、お客さんから無理な要求をされたときは、『現状ではベストなものを提供できないので、かえってお客様に迷惑をおかけするので、そんな状態で提供するわけにはいかない』と。ポイントは自分の都合を前面に出すのではなく、相手にとってデメリットになることを前面に出す必要があるようだ。これは、かなり使えると思う。システム開発の経験上、どうしても短い納期でこうしてくれということが多々ある。そういうときは、これを使えばいいと思う。この断る力は、システム開発プロジェクト特有の内容だなと思った。

実践編として、仕事を速くする7つのエクササイズが示されている。それは以下になる。

意見を通す
根本検証
企画力
クリティカルチェック
文章を短くする
文章の記号表現
結論から話す、書く

それぞれのエクササイズで、まずダメな例が示されており、その次にどうすればよいかが示されており、その後ダメな例の模範解答が示されている。この7つのエクササイズで特に勉強になったのは、根本検証に関して。これは、何かを論じるときに、以下のことを考える必要があるようだ。

そもそもそれは必要か
なぜ必要なのか
ないと何が問題なのか

これらを考え、その「何か」が間違いなく存在すべきであり、論じられているべきであると判断できるとき、「必要性を根本的に検証できた」ことになるとあった。具体例として、ドキュメントの整備が挙げられていた。

どうしてドキュメントを整備しなければならないのか？
そもそも、ドキュメントは必要なのか？
なぜ、ドキュメントがあるのか？ないとシステムは開発できないのか？

このようなことはよく自分も上司に言われる。常に『それって何のためにやるんだっけ？』や『そもそもそれは必要なんだっけ？』とか。特に『そもそも』という単語が頻出する。もう自分も完全に刷り込まれた。なので、絶対普通の会話でも『そもそも』と言ってしまうと、以前同期たちと盛り上がったことがある（笑）。それだけ常に根本を検証しろということだろう。そうじゃないと無駄な工数を使ったり手戻りを発生させてしまうので。

示されていることを全て読む必要はないと思った。『はじめに』のところで、著者自身も最初から最後まで読む必要はなく、実務をする上で必要なところだけ読むだけでよいとあったし。なので、必要に応じて必要な箇所、自分ができていない部分を読めばいい本かなと思った。自分の場合は、ある程度復習という感じで読んだ。かといて、全て満足いくレベルでできているわけではないので、できていない部分に関しては、勉強になった。

ただ一つ気になるのは、いくら著者の実体験から書かれている本だといえども、何かしらこの本を書く上や、日々の仕事で参考にしてきた書籍があるはず。それが、参考文献やお薦め書籍としてまったく示されていない。そのため、示されていることの信頼性が低下すると思った。

この本に示されていることの本質は、他の本でも代替可能だが、示されている例題などは、システム開発業特有だと思うので、自分の仕事の場合はどうかといったことを意識して読みやすいと思う。また、ITエンジニアだけに限らず、普通にプロジェクトベースで仕事をするような人も参考になる部分が多いと思われる。

読むべき人：