晴読雨読＠エンジニアライフ

実践テスト駆動開発 Steve Freeman、Nat Pryce（著） 和智右桂、高木正弘 (翻訳) 翔泳社 2012年9月 ISBN-10: 4798124583 ISBN-13: 978-4798124582 4,410 円（税込）

■「実践テスト駆動開発」ーー諸君、これがTDDの実践だ！

　TDDは広まりつつある。しかし……。

　アジャイル開発を行う上で、必須といってもいいプラクティスの1つに「テスト駆動開発・TDD」がある。このTDDのバイブルである「テスト駆動開発入門」をKent Beck氏が世に出してから、10年が経った。その間に、欧米では、すでにアジャイルがメインストリームとなった。日本でも、多くの諸先輩方が実践を続けていくなかで、ようやく広まってきたところだ。TDDを学ぶイベント「TDD Boot Camp」も、毎回キャンセル待ちの人が数多く出る人気イベントとなっている。

　日本でも、TDDに対する裾野はだいぶ広がっているのだろう。しかし、いざ実際の仕事でTDDをやろうとすると、いくつもの壁にぶち当たる。イベント駆動型クライアントアプリケーションの場合、データベースが絡む場合、マルチスレッドの場合、サードパーティのコンポーネントを使う場合。あまりに壁が大きいため、挫折してしまった人も少なからずいるだろう。かくいう私も、こうした壁を前にして、心が折れた経験を持っている。

　そうした、悩めるTDDerに向けて書かれた本が、本書「実践テスト駆動開発」である。本書は、世界中のアジャイリストが10年の歳月をかけて積み上げてきた、“TDDを行う上での壁”に立ち向かう術を教えてくれる、テスト駆動開発の奥義書である。

■そもそもTDDとは何か

　Wikipediaによると、

　プログラムに必要な各機能について、最初にテストを書き（これをテストファーストという）、そのテストが動作する必要最低限な実装をとりあえず行った後、コードを洗練させる、という短い工程を繰り返すスタイルである。

とある。

　では、TDDをすることで、どういった恩恵があるのだろうか。本書では

　システムを開発する際には、TDDを採用することで、実装（「正しく動くか？」）と設計（「適切な構造になっているか」）両方の質についてのフィードバックが得られる。テストを先に書いて開発することで、投入した労力による恩恵が二重に得られるのだ。

とある。つまるところ、TDDをすることは、設計と実装を小さなスケールで絶え間なく繰り返すことで、正しいソフトウェアを作っていくことに他ならない。

■立ちはだかる壁を内包したアプリケーションを、TDDで育てていく

　では、実際にTDDはどういった形で進めていくのだろうか。本書のサンプル「オークションスナイパー」というサンプルアプリケーションの開発内容を一部紹介していく。

　まず行うのが、アプリケーションの全体像を考えること。必要となるプロトコルや、状態遷移、扱う機能について洗い出す。いきなりテストコードを書くのではないのだ。何をしなければいけないのか。どういった技術基盤の下に行うのか。そうしたアプリケーションの設計を行う必要があるのだ。

　そうしてアプリケーションの設計をした後に行われるのが、「動くスケルトン」と呼ぶものを作ること。これはシステムで必要となるコンポーネントを網羅した形で一つの機能を、エンドツーエンドテストーーユーザーインターフェイスからサーバとの通信を経て、結果が出るまでーーとして成功するものとして構築したものである。

　「オークションスナイパー」システムでいうと、ユーザーインターフェイスやスナイパーコンポーネント、オークションサービスとの通信を網羅した形で一つの機能をTDDで実装するとしている。

　このとき、オークションサービスは実際のものを使わず、同じように動作させることのできる仮想サービスを用意して行う。

　いわば、アーキテクチャの検証である。考えたアーキテクチャが正しいかどうかを検証するのだ。こうしてアーキテクチャの検証を終えた「動くスケルトン」に一つずつ機能を追加していく。

　「オークションスナイパー」システムは、最初偽のオークションサービスとコネクションを行い、オークションの終了を見届けるだけの機能から作成を始めている。そこから一つづつ機能を追加していく形で、入札を行ったり、新しい商品を追加できるようにしていっているのだ。

　もちろん、テストコードを書き、それが全て成功するのを保つようにして追加していくのだ。このようにして、正しいソフトウェアを育てているのだ。

　実際のアプリケーションをTDDで開発していくのにここまでやる必要があるのかと、私は圧倒された。しかし、ここまでやるからこそ正しいソフトウェアを育てていけるのだろう。ウォーターフォール型開発で最後にテストを行なうことで、バグが吹き出して苦しい思いをする。それに比べれば、こちらの方が、開発は大変ではあるが、安心して開発ができるように思う。

■すべてのTDDの難問に対する解はここに

　この「オークションスナイパー」のサンプルには現れていない、TDDをする上で陥りやすい罠や立ちはだかる壁はまだ多くある。こうした難問に対しても、本書は解を示している。

　例えばデータベースを扱う際のTDDはどのようにして行えばいいのか。永続データの消去をテストの開始前に行うのだ。整合性制約があるので、テーブルから行を削除する順序を一つにまとめ、行うのがよいとしている。

　トランザクションを必要とする場合はどうすればいいか。トランザクション管理を行うオブジェクトを抽出し、そのなかでユニット・オブ・ワークパターンを用いればよいとしている。

　他にもマルチスレッドでのTDDや非同期処理でのTDDなど、「こういう場合のテストはどう書けばいいんだ……」という、TDDerの悩みに本書は応えてくれるだろう。

■TDDを学び、本書を携え実践しよう

　残念ながら、本書はこれからTDDを学ぼうとする人が読むには敷居が高いだろう。初めてTDDを学ぶならば、やはりKent Beck氏の「テスト駆動開発入門」を読み、実際にコードを打ち込んで、体験する必要があるだろう。もちろん、TDD Boot Campへ参加するのもいいだろう。

　そうやって、TDDを学んで実際に使い始めると「こういう場合どうすればいいんだ……」という場合が必ず訪れる。そのときこそ、本書はあなたの力になってくれるだろう。私もまた、本書を携えてTDDを実践していこうと思う。

業務システムのためのユーザーマニュアル作成ガイド 黒田聡、雨宮拓、徳田直樹、高橋陽一 （著） 翔泳社 2009年1月 ISBN-10: 4798117145 ISBN-13: 978-4798117140 2604円（税込）

■たかがマニュアル、されどマニュアル

　長い開発が終わってようやく一息つけると思ったのもつかの間、「マニュアル作っておいて」という一言により、慌てて画面をキャプチャし始める。マニュアル担当になったものの、開発側の仕様決定遅れに引きずられてリリース前に徹夜して書き上げる……。こんな経験は皆さん、一度ならず、二度三度はあるだろう。

　なんだかんだとなくてはならないもの、それが「マニュアル」である。マニュアルに携わるエンジニアを救ってくれる（かもしれない）のが本書、『業務システムのためのユーザーマニュアル作成ガイド』だ。

■オーソドックスな章立て

　章立てを見ていこう。

• 第1章　マニュアル作成の「間違った常識」
• 第2章　マニュアルの企画はこう進める
• 第3章　マニュアルの文章はこう書く
• 第4章　マニュアルや仕様書をわかりやすくするビジュアル表現
• 第5章　マニュアルの内容・表現の校正はこう進める
• 第6章　マニュアルの保守管理はこうする
• 第7章　部品化と構造化で効率アップ

　第1章で「間違った常識」と読者の注意を喚起し、2章以降でマニュアルの作り方を順に説明していくという、オーソドックスなスタイルだ。「マニュアルの書き方を知りたい」読者にとっては一見、冗長にも見える。

■思わず読み込んだ「マニュアル作成の間違った常識」

　まずは、1章から紹介しよう。

• 1‐1 常識の誤り マニュアル作成は目次構成の検討から始める
• 1‐2 常識の誤り マニュアルは読者別に分冊にする

　「常識の誤り」とは、なかなか過激な見出しである。普段、当たり前にやっていることなのだが、本書によれば「誤り」らしい。こういうやや過激な見出しは往々にして中身が伴わないものが多いが、本書は読んで納得できた。例えば、1‐1の「マニュアル作成は目次構成の検討から始める」では、「典型的な目次先行検討法の例」として「XX設定・XX登録」など機能の羅列の悪い例が示されている。確かにやりがちである。この「誤り」に対する、本書の回答。

• 何を伝えたいのか明確にする
• 伝える内容を整理整頓する
• 見せ方、探させ方の設計が目次作成である

　なるほど納得。特に3番目は「目次作成とは何か？」という著者の定義が明確に主張されていて、分かりやすかった。

　続いて1‐2の読者別分冊、ここではよくある（でも良くはない）家電のマニュアルが例として挙げられている。

• 1冊目：「初めてお使いの方に」
• 2冊目：「取扱説明書応用編」
• 3冊目：「困ったときに」

　それぞれの問題点と改善例が示されている。読みながら一緒に考えてみるとよいだろう。

　本書は、他にもいろいろな「常識の誤り」を紹介している。

• 1‐3 常識の誤り 書き始める前に文章の組み立てを行う
• 1‐4 常識の誤り マニュアルでは操作と結果を分けて書く
• 1‐5 常識の誤り わかりやすいマニュアルを書ける人は、文章の上手な人
• 1‐6 常識の誤り 正しい日本語文法の知識は必須である
• 1‐7 常識の誤り マニュアルには索引は必須である

　ほとんどが「常識じゃなかったの!?」という内容だったので、思わず熟読してしまった。

　誤りの改善例として、「文章の組み立てのためには、マインドマップを使って書きたいことを視覚化する」というものがあったのだが、自分も同じ解決法を用いていたので、ほっとした。他にも「Wordの文章校正機能などを使って文法ミスを回避する」など、日ごろから行っておきたい例が紹介されている。

　1章はこの後の各章の導入部となっているので、飛ばさず読んでおきたい。

■マニュアルも企画が肝、実はシステム開発と同じなのかもしれない

　2章では「マニュアルの目次を仕上げるまで」――つまりマニュアルの企画段階について書いている。この章は内容が濃かった。

　業務フローを作成するところが出発点だ。しかも、導入前と導入後のフロー両方である。まるで業務分析をしているかのようだ。そこから「機能」「操作」へと落とし込んでいく。

　マニュアルらしいところは2-6の「期待に応えられないところを探し出す」だろう。「できると思っていることができないという情報もまた、必要な情報」というところは、利用側の立場になってみればよく分かる。実際にできると思って探し回るのは、経験上よくあることだ。

　2章は17節まであり、ボリュームが大きい。そのくらい、企画段階はマニュアルにおける“肝”なのだろう。

■マニュアル作成のプロによる作成に校正、保守の解説

　3章の「文章はこう書く」は、読者を絞り込むペルソナモデルからスタートし、漢字・ひらがなの使い分け、修飾語、接続詞、助詞、指示語、といった「書き方」についてのポイントを紹介している。文科系出身の人間は、息がつけるところだ。「に」と「へ」の区別などを再確認するのにちょうどよい。

　4章はビジュアル表現。ビジュアルと聞くとすぐにイラストを想像してしまうが、それだけではない。ビジュアルは特に、図解によるグルーピングなど、論理的な思考を試される。この4章でようやく、Wordの「段落書式の設定」といった、具体的なツールの使い方が出てくる。本書が、手法に重きを置いていないということがよく分かる。4章までを読めばひととおりのマニュアルが書けると思う。

　5章は校正について。PDF校正の利点についての説明は、マニュアル作成をやったことがある者としてよく分かる。

　6章では保守管理、7章では部品化・構造化について。通常のシステムマニュアルでここまで踏み込むのは容易ではない。ただしマニュアル管理の業務に携わったことがあれば、イメージがつきやすい内容だろう。

■まとめ。マニュアル作成側の地位向上はなるか？

　内容をまとめよう。1章の常識は、次章以降の導入部となっているため、読んでおく必要がある。2章以降は、作成の手順に沿った構成で分かりやすい。だからといって「さあ、作ってみよう」というチュートリアル形式の手段や方法ではなく、考え方が述べられているので応用が利く。

　マニュアル作成全般のフェイズだけでなく、メンテナンスのフェイズでも手元においておきたい本である。

　ただし、いくらマニュアルを工夫しても、出来の悪いシステムが良くなるわけではない。分かりにくいインターフェイスは分かりにくいままだ。

　だから、マニュアル作りが軽視されるのかもしれない。本来はシステム開発において開発側と両輪であるべきだし、マニュアル側から開発へ改善を求めるくらいが理想的なのだろう。

エンジニアのためのPowerPoint再入門講座 石川智久、植田昌司（著） 翔泳社 2009年9月 ISBN-10: 4798119458 ISBN-13: 978-4798119458 2310円（税込）

■Word、Excelと来たら、いよいよ鬼門の“あれ”が来る

　「エンジニアのための○○再入門講座」、Excel、Wordと来て、ついにエンジニアにとっての“鬼門”、「PowerPoint」である。

・参考：

• 『エンジニアのためのWord再入門講座』――メンテナンス性が高くてこそ、“良い開発ドキュメント”
• 『エンジニアのためのExcel再入門講座』――コードだけでなく、Excelだってビューティフルにしよう
• 『エンジニアのための図解思考 再入門講座』――「格好良い仕様書」には良い図解があるものだ

■パワポ使いに憧れて

　本書は、ウルシステムズ所属のエンジニア2人が執筆している。ウルシステムズには、地に足が付いたIT企業という印象があるので、実用的な内容が期待できそうだ。

　※10年ほど前、オブジェクト指向絡みで社長の漆原茂氏に会ったことがある。氏の人となりは「挑戦者たちの履歴書」が詳しい。

• 第1章　パワポの使えるエンジニアになろう
• 第2章　硬派なパワポ事始め
• 第3章　硬派なパワポのための機能解説
• 第4章　パワポを使った会議術
• 第5章　パワポで”ロジカル資料”
• 第6章　硬派なパワポ流　スライド事例集

　目次を見てみると、“硬派”と単語が目につく。とても気になる。何が硬派で何が軟派なのか？ この疑問に対する答えは、本書の中にあった。

　第1章では、「何がExcelで、何がWordで、何がPowerPointなのか」、筆者なりの解が提示されていて、これが面白い。

　「ExcelでもWordでもないものがPowerPoint」。

　人によって賛否両論あるだろうが、個人的には納得した。ぼくにとって、PowerPointは「きっちりと構造化した文書を書かず、ラフに書きたい時」のツールである。

■戦う前に武器を磨け

　本書は、2章（設定編）と3章（機能）で「パワポという武器」について解説し、4章～6章が実践編である。てっきり実践編の方が本書の“キモ”かと思いきや、2章と3章にたくさんの驚きと納得があった。ひととおり通読した後、読み返したいのはこの2つの章だろう。これらのためだけにでも、手元に置いておく価値はあると思う。逆に、4章～6章は、良い部分もありつつ、突っ込みたい部分もあった。

　さて、ではいったい2章と3章、何がそんなに気になるのか、少し紹介しよう。

　「オートコレクトはすべてOFF」「編集領域の確保」「高速保存」「サイズ指定はA4」「グリッド／ガイド設定鉄則」「余白を作らないインデント／行間設定」「自作吹き出し」「コネクタの活用・透明オブジェクト」「図の圧縮」……、これらの見出しを眺めるだけでも、著者のこだわりが感じられる。

　高速保存や図の圧縮など、ファイル容量を減らすテクニックは日頃から使っている（メール添付容量の制限対応）ため共感できるし、「グリッド／ガイド設定」の説明では「間隔0.2cm」と言い切ってしまう自信に圧倒されてしまった。自作吹き出しやコネクタの活用・透明オブジェクトなど、「ここまでするか……」と思わずうなりたくなるほどの徹底した見栄えへのこだわりもすごい。

　地味ではあるが、「サイズ指定はA4」という印刷中心の意識には納得した。これらの設定が施されたファイルが、翔泳社のWebサイトからダウンロードできる心遣いもすばらしい。

■さて実践。「パワポ会議」が意外と便利？

　4章以降は実践編だ。著者は「パワポ会議」なるものを勧めている。スライドショーと外部ディスプレィを組み合せて、会議を行うわけだ。

　「何じゃこりゃ？」と思ったのだが、実際やってみると（会議はやらずに自分だけで操作した）、スライドショー状態のまま表示ページを編集できるし、後ろで表示以外のページを編集もできるし、大変便利である。代替手段は、確かにこれ以外なさそうである。しかし、会議を進行させながらPowerPointを編集していくのは、もはや技を超えて“芸”の域である（ちょっと失敗しただけで、紙に戻せと言われそう）。

　5章では「Webモール刷新企画書」なるケーススタディを紹介しているが、20ページほどで説明するのは若干無理があったかもしれない。6章では、「なぜPowerPointなのか？」を再考した上で、PowerPointで作る画面レイアウト、フローチャート、スケジュールを説明しているが、こちらも中途半端な感じがする。個人的には、フローチャートの説明としては、「新発想の業務フローチャート作成術」の方に軍配を上げたい。こちらの記事はExcelを使っている。PowerPointのフローチャートでは、1つプロセスが増えるたびに間を詰めないとならないので、好きじゃないのだ（確かに、スライドショーでさくさくと切り替えながら新旧フローを対比できるのは便利かもしれないが）。とはいえ、ノートビューと標準ビューを使い分け、同じ資料でユーザー向けと開発者向けの説明を入れるという発想には脱帽した。やたらとテクニカルである。

■まとめ：2章と3章のために手元に置いておきたい1冊

　全体を通して、何かしっくり来ない部分があった。2章と3章での準備が、4章以降の実践編で生かしきれていないように思う。2章3章での設定や機能を使えば「いまではこうだったものがこなる！」というビフォーアフターを期待していたのだが、あまりそういった発見はなかった。

　突っ込めるところはいろいろ突っ込めるが、2章と3章だけで本書は十分な価値があると思う。手元に置いておけば、重宝しそうだ。

■おまけ：これが謝辞か

　突っ込みついでに、「謝辞」にも触れておこう。洋書でよく「愛する妻とわが息子に……」という謝辞を見掛ける。これを和書でやるとどうなるかが分かった。なんというか、むずがゆい。じゃあ自分が書いたらどうなるのかと考えてみたけれど、やはりむずがゆいものになりそうだった。愛情と苦労がよく伝わってくる謝辞だったので、のぞいてみるとよいかもしれない。

Being Geek　ギークであり続けるためのキャリア戦略 Michael Lopp （著） 夏目大 (翻訳) オライリージャパン 2011年6月 ISBN-10: 4873114993 ISBN-13: 978-4873114996 2415円（税込）

■ギークであり続けるためのキャリア論

　私は、今年転職して4月から新しい会社で働いています。刺激的な毎日を過ごすことができ、転職は正解だと思っています。しかし、現状に満足しているせいか、将来の自分の姿を思い描けなくなっていることに気付きました。

　そんな折に本書を知り、今後のキャリアプランを考えるきっかけにしようと思いました。

■4テーマ、40章という幅広い内容

　本書は、エンジニアのキャリア戦略にまつわるさまざまな内容を扱っています。テーマは大きく分けて4つ、「キャリアの形成」「マネジメント」「日々の仕事に必要なスキル」「変化」という構成です。

　各テーマはさらに細かい章に分かれていて、全40章とかなりのボリュームです。エンジニアがマネージャに転身する場合の注意点や心掛けたいこと、転職、コミュニケーションのコツなど、まさに｢キャリア形成｣に関わることは幅広く網羅しています。

　とはいえ、各章はそれほど長くないため、気軽に読めます。気になる章、自分にとって必要だと思う章から読み進められるのも、本書の良いところだと思います。

　これだけの量を扱っているので、エンジニアなら何かしら気になる章があると思います。私の場合、40章のうちで気になった章、役に立つと思った章が10章もありました。

• キャリアのための行動（第1章）

• 大切なことは3つ（第2章）

• 転職にあたって考えるべきこと（第3章）

• 企業文化（第8章）

• 不可能を可能に（第13章）

• トリクルリスト（第24章）

• 無意味なこと（第28章）

• 転職先の選択（第35章）

• マネージャとコミュニケーション（第37章）

• 不安な将来（第40章）

　特に、今の仕事において役立ったのは「マネージャとコミュニケーション」（第37章）でした。エンジニアとしての仕事を買われてマネージャに昇進した人がいるとします。しかし、エンジニアの仕事とマネージャの仕事は質がまったく異なるため、エンジニアとして優れていたとしても、マネージャの仕事がうまくできるとは限りません。37章では、マネージャに昇進するエンジニアが持つべき心構えをまとめています。

• 部内、部外の人たちとのコミュニケーションの「ハブ」になる必要がある

• ある人から聴いた話を別の人にする場合、そのまま伝えるのではなく、伝える人に合わせて「抽象化」と「フィルタリング」が必要になる

• 同様に、部署ごとに違う「方言」を自由に操れる必要がある

• 自分が見た「混沌としたドラマ（錯綜する情報）」を要約して部下に伝える

• 変化球（予測不能な事態）にも冷静に対応する

• NOというときははっきりNOという。YESの場合も同様

• 自分がしてきた仕事、自分が学んだ事を部下が行えるようにする（スケーリング）

　現在、私自身がプロジェクトマネージャに近い仕事を求められているため、37章のエッセンスは今後の仕事を進めていく上でとても参考になりました。

■キャリアに対する漠然とした不安がある人のために

　また、最終章「不安な将来」も印象に残りました。今の仕事には満足していますが、それでも「将来のキャリアについて考えないと……」と不安に思うことが何度かあったためです。

　おそらく多くの人が感じたことがあるであろう、「転職したい」と漠然と思う理由について、著者は「データが多すぎるから」と分析しています。

　共に働く人々の人となり、チームや会社の文化、人が集まるところでの駆け引き――こうした膨大なデータに囲まれながら人は仕事をしていると、人は「転職したいなあ」と考えるのだそうです。一方、人の脳は自分の価値観に合わせて重要だと思うものを選び出し、解釈を加えます。そのため、自分にとって心地よい意見ばかりを抽出して「この会社は自分にとって居心地がいいんだ」と思ってしまう場合もあります。

　ですが、人が成長するためには「混乱」「葛藤」が必要だと、著者は説きます。時には失敗することや、自分に異議を唱える人が近くいること、毎週なにかを学ぶことが大事なのだそうです。

　私はこの章を読んで、自分1人だけが悩んでいるのではない、「不安を感じるのは誰でもあることなんだ」と安心することができました。

■実践的なアドバイスを求める人のために

　他にも、興味深いアドバイスがいくつもありました。企業文化を知ること、企業文化の変化に合わせた行動を取ることの重要性（第8章）や、「トリクルリスト」という、ToDoリストとは違った長期的なタスクリストの作り方（第24章）などがある一方で、「時には何もせず、何も生み出さず、何も生産的なことは考えないという時間が必要」（第28章）というメッセージがあったりと、大変興味深いです。

　また、実際に「転職をしよう」と決意した人は、第3章や第35章を読むとよいでしょう。

　転職をする前に、「なぜ転職をしたいのか」をもう一度考えなおすこと、実際に転職をする際に重視すべき基準が述べられています。

　本書は、「技術者たるもの、こうあるべきだ」という自己啓発的な要素は薄いかもしれませんが、日頃の心構えやキャリアに対する考え方というよりも、より実践的な面で非常に勉強なる本です。

■どんなキャリアプランにも必要な「コミュニケーション」

　本書を読んでいて、「コミュニケーションがいかに大切なものか」をつくづく実感しました。マネージャになる、エンジニアとしてスペシャリストを目指す、どんなキャリアを築くにしても、キャリアアップを図るには、仕事の成果を充分に評価してもらうことが必要です。そのためには上司とのコミュニケーションがポイントになってきます（本書ではさまざまな性格の上司とどう仕事していくべきかについても書かれていて、参考になります）。

　自分のキャリアを自分が思うように築き、かつ相応に評価してもらうためにも、コミュニケーション力を身に付ける必要性を改めて感じました。

（『It’s Party Time!』 コラムニスト　あずk）

SEのための29歳からのキャリア向上計画 山崎 有生（著） 技術評論社 2010年7月 ISBN-10: 4774143227 ISBN-13: 978-4774143224 2,079円（税込み）

2009年　第1位（81.6％）
2008年　第1位（76.6％）
2007年　第1位（79.5％）
2006年　第1位（81.7％）

　 上記は、社団法人 日本経済団体連合会が調査している「新入社員に求めるスキル」の結果である。トップに輝いているのは「コミュニケーションスキル」だ。なんと、7年連続で「コミュニケーションスキル」が首位を取り続けている。

■「技術力はそれなりに自信があるけど……」キャリアに悩むエンジニアのための本

　「コミュニケーションスキルは重要だ」とよく聞くが、なぜコミュニケーションスキルが重要なのか？ そもそもコミュニケーションスキルとは何なのか？

　本書は、「大事なのは分かるけどよく分からない」コミュニケーションスキルを体系的に解説し、かつ「コミュニケーションスキル」の獲得方法を紹介している。

　「コミュニケーションスキルはエンジニアのキャリアアップのために必要だ」――著者はこう主張する。

　エンジニアとしてのキャリアアップを考えるとき、まず思いつくのが「技術力」だ。20代はとにかくプログラミングをして技術力を磨き、一人前に仕事がこなせるようにすればいい。問題は、その次のステップである。30代間近になって部下がつき、大きな仕事を任されるようになったら、どうやってキャリアアップを目指せばいいのか？ その際に必要なのが「コミュニケーションスキル」なのである。

　「技術力があって優秀なのに、コミュニケーションスキルがボトルネックとなって伸び悩む人が多い」と著者は指摘する。本書は「技術力にはそれなりに自信があるけれど、この先どうやってキャリアアップを目指したらいいのだろう」と悩むエンジニアがのために書かれている。

■「ヒューマンスキル」獲得のために必要な鉄則108カ条

　本書は、エンジニアがキャリアアップのために伸ばすべきスキルとして、以下の3つのスキルを紹介している。

• コミュニケーションスキル
• ネゴシエーションスキル
• リーダーシップ

　この3つのうち、基礎となるのが「コミュニケーションスキル」だ。「ネゴシエーションスキル」や「リーダーシップ」は、コミュニケーションスキルが形を変えたものである。ということは、まずエンジニアはコミュニケーションスキルを磨く必要があるということだ。

　では、コミュニケーションスキルとは何か。コミュニケーションスキルについて、本書は下記のように定義している。

• コミュニケーションスキル＝意思疎通＋関係構築
• コミュニケーションの効果＝内容の質×伝達方法×回数

　これだけではよく分からないが、著者はこの内容を噛み砕き、具体例をふまえつつ「鉄則」として一言でまとめている。一例を挙げよう。

• 鉄則7：結論から伝えよう！
• 鉄則8：最後にまとめを入れよう！
• 鉄則9：切り口を大切にしよう！
• 鉄則10：理由は3つありますとまずいおう！
• 鉄則11：具体例を示せ！

　上記は、顧客とのやりとりなどで特に重要な「論理的に話す方法」における鉄則である。これらの「鉄則」が、「ネゴシエーションスキル」と「リーダーシップ」と合わせると、全部で108つ紹介されている。

ネゴシエーションスキル

• 鉄則48：ネゴシエーションでも相手の立場に立とう！
• 鉄則49：感情的になりそうになったら6秒待て！
• 鉄則50：相手の得と共に相手の損も説け！

リーダーシップ

• 鉄則85：否定質問よりも肯定質問を！
• 鉄則86：過去質問よりも未来質問を！
• 鉄則87：沈黙を効果的に使おう！

■強みを伸ばすか、弱みを克服するか？ キャリアアップの考え方

　キャリアアップのためには、弱みを克服すべきだろうか、それとも強みを強化すべきだろうか？

　著者は「強みを強化すべき」と主張する。理由は3つある。まず、強みを伸ばすことは苦にならないため。次に、強み・弱みは若いころにあらかた決まってしまっているため。そして、弱みも強みであるためだ。

　「弱みを克服する」という発想は、学生時代のテスト対策の発想であると著者は指摘する。得意科目にどれだけ時間を費やしても、テストでは満点以上の点数が取れないため、必然的に弱点を克服するという発想になる。だが、キャリアアップはそうではない。スキルの向上に「満点」のような天井はない。であれば、強みは伸ばせるだけ伸ばすべきなのだ。

　タイトルには「29歳のSE」とあるが、ターゲットはそれだけにとどまらない。20代でも30代でも読めるし、PMでも人事育成担当者でも活用できるように書かれている。

SEの勉強法 克元亮（著） 日本実業出版社 2010年5月 ISBN-10:4534047126 ISBN-13978-4534047120 1575円（税込み）

■9つのスキルと、5つの勉強フレームワーク

　「SEは、最も勉強が必要な職業の1つです」

　そんな言葉で本書は始まります。『SEの勉強法』という、そのものずばりのタイトルを掲げる本書は、SEに必要であると思われるスキルを9つに分類し、それを身につけるための勉強法を5つのフレームワークで解説しています。

　著者の考える「9つのスキル」とは、以下の通りです。

• コミュニケーションスキル
• コンサルティング手法
• モデリング手法
• ソフトウェアエンジニアリング
• 経営管理
• 業務知識
• プロジェクトマネジメント
• 情報技術
• アーキテクチャデザイン

　本書では「コンサルタント」「プロジェクトマネージャ」「ITアーキテクト」という3職種について、それぞれどのスキルが特に必要となるかを整理しています。

　また、後半では、これらのスキルを身につけるための5つの勉強法を「5Pのフレームワーク」として提示しています。

• Purpose（目的）：達成できる目的を定める
• Planning（計画）：勉強の締め切りを意識する
• Practice（実践）：勉強を楽しみ習慣化する
• Partner（仲間）：孤独な勉強に打ち勝つ
• Present／Profit（報酬）：勉強の成果は見える形にする

　この中でも、特に「Practice（実践）」に多くの紙面が割かれているのが特徴的です。「勉強の習慣化」の重要性がよく分かります。

■どうなりたいか→何を勉強すべきか→どう勉強するか

　「コンサルタント」「プロジェクトマネージャ」「ITアーキテクト」の3職種を目指す人にとって、本書は多岐にわたるスキルセットを体系的に整理し、分かりやすく解説しているという点で、有効なノウハウ本として機能するでしょう。やや偏りはあるものの、SEに必要とされるスキルを網羅的にカバーしているため、自分が持っているスキルや、足りていないスキルの確認に役立ちます。

　しかし、最も注目すべきは、本書の“構造”にあります。「キャリア」→「スキル」→「勉強法」の順に書かれている、という事実に着目しましょう。

3職種のいずれかを目指す（キャリア）
　↓
そのために必要なスキルを知る
　↓
それを学ぶための勉強法を5つのフレームワークで整理する

　まずキャリアビジョンがあり、そのために必要なスキルがあり、そのために有効な勉強法がある。本書は、そういう順番で書かれています。

　自分の進みたい方向が決まらないまま多種多様なスキルを身につけようとしたり、どんなスキルが必要かを考えずに勉強法にばかりこだわるということが、ときに起こり得ます。もちろん、それが悪いわけではありません。ひたすら勉強する中で、進むべき方向が見えることもあります。ですが、ある段階で進むべき方向を決めることもまた、重要なことです。

　本書では先に挙げた3職種がキャリアゴールとして設定されていますが、現代のエンジニアにとって、この3職種が唯一のキャリアゴールではありません。どのような方向に進むかの選択肢は多岐にわたります。しかも、時代の流れによって、どんどん変わっていきます。ですから、設定したキャリアゴールを何年も変わらずに追い続けるのは、難しいことです。それでも、進むべき道を自分なりに選び出し、そのために必要なスキルや勉強法を模索するのは、決して無駄ではないでしょう。

　もし「なんのために勉強しているんだっけ？」と迷ったときは、自分がどうなりたいかを思い出すといいかもしれません。本書の章立てをもとに、「自分だったら、こういうふうになりたいから、こういうスキルが必要で……」と考えてみましょう。