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

エンジニアのためのWord再入門講座 美しくメンテナンス性の高い開発ドキュメントの作り方 佐藤竜一（著） 翔泳社 2008年5月 ISBN-10: 4798117137 ISBN-13: 978-4798117133 2310円（税込）

　Wordはワードプロセッサです。

　Excelは表計算ソフトです。

　残念ながら、Excel方眼紙にドキュメント作成ツールとしての地位を奪われた感があるWordですが、きちんと機能を理解して使えば、必ずエンジニアの役に立つはずです。「Wordは変な動作をするし、おせっかいな機能が多くて使いにくい！」とは、言わせません。

■「より良いドキュメントを、効率よく作る」ための本

　「より良いドキュメントを、より効率良く、低コストで作成する」――これが本書の目指すゴールです。この目的を達成するために必要なWordの初期設定、および理解しておくべき機能などが解説されており、この点が一般的な入門書と違うところです。

　ざっと本書の各章を列挙してみましょう。

• 1章　ドキュメント作成の意味とは
• 2章　これだけはやっておきたいWordの初期設定
• 3章　スタイルを理解することから始めよう
• 4章　DRYで行こう！
• 5章　テンプレートを設計する
• 6章　図と表の取り扱い
• 7章　チームで作業を効率化する

　この目次を見るだけでも、ちょっと興味を引かれませんか？ 私は、目次にざっと目を通しただけで、なんだかうれしくなってしまいました。

■ドキュメントを作る時の「コスト意識」は重要

　まず、1章。この章で私が「なるほど」と思ったことの1つが、「ドキュメント作成に関するコスト意識」です。

　そもそも良いドキュメントとは何でしょうか。本書では、

• 読みやすく
• 体裁が整っていて
• メンテナンス性が高い

ものであるとうたっています。この3原則の中では、「メンテナンス性」が最もダイレクトにコストに関連するのではないでしょうか。

　Excel方眼紙でドキュメントを作成すると、目次やドキュメントの折り返しなどはすべて手作業で行います。少しでもずれると、内容を削るか、全体をいじるか……この作業はかなりの労力＝見えないコストがかかります。

　1章で著者は、「Excel方眼紙はダメなのか。Wordを使用する方が良いのか」「良いドキュメントとは何か」「ドキュメントの質を見極めるポイントとは何か」について述べています。私は、ここだけでもコピーして社内で配りたくなりました（きっと、同じような人が続出すると思います）。

■Wordの“お節介機能”を取捨選択する

　2章では、著者が推奨する「Wordの初期設定」を紹介しています。いわゆる「各種お節介機能」の取捨選択です。「お節介！」と断じてしまう前に、有用な機能と、あまりそうでない機能は理解しておくべきです。

　2章のメインテーマは機能の解説とその有用性ですが、実は前から「Wordのこの機能って何なの？」と思っていて放置していた機能がたくさんあったので、とても勉強になりました。Wordは意外と奥深いソフトです。ものすごくしっかり考えられ、練られたソフトなんだなとつくづく感じます。

■メンテナンス性の高いドキュメントを作るための機能

　3章以降は、2つのテーマがあるように感じました。3章、4章、6章は、基本的なWordでのドキュメント作成に必要な機能の解説。5章と7章は、チーム内での共有や複数の人間がメンテナンスする際に役立つと思われる機能の解説だと解釈しました。5章は、両方の意味があると思います。

　この部分については、説明するより読んだ方が早いので、「まずは目を通して！」と言いたいところです。とはいえ、それでは書評にならないので少しだけ……。

　普段Wordを使っている時、「お節介な機能」「変な動作をする」と感じる状況があるかと思います。それらは、おそらく3章、6章あたりを読めばおおむね解決するでしょう。むしろ、これらの章に書かれていることを押さえないことには、どうにもなりません。個人的には、表や図の配置、回り込みの部分をあまり理解せず適当に使っていたので、非常に役に立ちました。ここらへんの部分は、「読みやすく、メンテナンス性の高いドキュメント」を作成するために理解すべき内容です。

　3章を理解すれば、字下げやインデントをスペースで調整したり、個条書きを中点でごまかしたりしなくてもよくなるはずです。また、ちまちまとフォントの色や大きさを手作業で設定した揚げ句に、体裁がバラバラな「残念ドキュメント」を作成する……なんてこともなくなるでしょう。

■ちょっとマニアックな機能解説もある

　4章で紹介されている機能は、普段はあまり使う機会がないけれど、実は使いこなせばすごく役に立つものです。例えば、フィールドの埋め込み、図表番号などの相互参照などです。私も、実際には使ったことがほとんどありません。本書の中では、わりとシステマティックな部分が、この4章かと思います。フィールドの埋め込み、図表番号などの相互参照といった機能は、ドキュメントの作成、編集時における「繰り返し作業」を減らし、作業の効率化に役立ちます。

　もう一歩進んで、本当に良いドキュメントを、チームの誰もがWordで作成できることを目指すなら、5章と7章が参考になるでしょう。5章ではテンプレート、7章は変更履歴やドキュメントのバージョン管理機能についての解説です。せっかくだから、このレベルまでWordを使いこなしてみたいと、切に思いました。

■まとめ

　本書では、至るところで著者の心の叫びが見られますが、最も私が共感した部分を引用します。

　筆者自身、これまで「そんな機能を覚えるために掛かる時間を考えてみろ」「印刷すれば同じだ」とよく言われてきました。しかし、我々は素人ではなく、コンピュータのプロなのです。プロの看板を掲げるなら、コンピュータを使って行う作業は、少なくとも素人以上に行えなければなりません。

　この部分に深くうなずいた人は、たくさんいらっしゃると思います。少しでも皆さんがWordの魅力に気付き、Wordを有効活用することによって作業効率の向上、業務改善ができれば、Excel＆Word萌えの組長としてはうれしい限りです。

エンジニアのためのExcel再入門講座 吉川昌澄（著） 翔泳社 2010年1月 ISBN-10: 4798119474 ISBN-13: 978-4798119472 2310円（税込）

■Exceにまつわるエンジニアの叫び

　「Excelの方眼紙はやめてくれー！」

　「遂にMac版のExcelで方眼紙テンプレートが標準搭載されたらしいぞ！ ガクブル」

　今日もTwitterのタイムライン上で、技術者の心の叫びがこだまする……。

　かつて、上司によく小言を言われました。

　「ソフトウェアの特性を生かした使い方をしろ。一般ユーザー向けソフトだからこそ、技術者としてきちんと勉強しろ」

　「Excelは、表計算ソフトであって、表作成ソフトではない」

　前述のように、Excel方眼紙に苦しめられているTwitterユーザーのつぶやき（もはや叫び）を時々見掛けます。私自身、現場で「なんでこんなことに!?」と思わず頭を抱えたくなるような使い方を目にします。優秀なExcelが泣いています。

　もっと、使いこなして業務に生かしてあげてください。これはヘルプデスクとしての切な願い（もはや叫び）です。

■エンジニアだからこそ、Excel

　さて、本書は「Excelの機能を知り尽くしている（はずの）優秀なエンジニアであるにもかかわらず、Excelを使って作成したドキュメントはなぜこうも見にくく、再活用が困難であるのか」という誰にとっても覚えのある疑問から出発します。本書のテーマはずばり「読みやすいドキュメントをいかにしてExcelで作成するか」。

　Excelはあくまで手段であり、目的ではありません。目的（＝ドキュメントを作りたい）を果たすため、手段・道具（＝Excel）を使いこなす。その際に役立つ知識、すなわち

• 表のレイアウト
• データモデル
• 可読性の向上
• メンテナンス性をいかにして考慮するか

などのノウハウを解説しています。非常にシステマティックです。

　また、表ドキュメンテーションのノウハウという観点だけでなく、データ分析やグラフによる「見える化」、業務の流れに沿った帳票の作り方にも言及しており、現場のメンバーから管理職まで、幅広い人材が読むべき内容が網羅されていると感じます。

　巻末には、ドキュメント作成に有効なExcelの操作メモ、さらに章の間には筆者のコラムもあるという親切設計。あまり使う機会がない小技やTips、筆者の体験談などが書かれており、「Excel萌え」の私としては、非常に楽しく興味深く読めました。ここに記載されているExcelの操作知識は、エンジニアであれば押さえておきたいところです。

■まとめ：Excel萌えヘルプデスクの必読書

　「入門」とタイトルについていますが、あくまで「エンジニアのための」本です。

　Excelの操作知識が十分にあるエンジニアが、より良い「素敵ドキュメント」を作成するための知識や考え方、Excelの小技が網羅されています。決して「Excelの使い方」ではないので、Excelの知識が浅い人は、まずしっかり基本をマスターしてから一読することをお勧めします。

　細かいノウハウを紹介することはあえて避けましたが、エンジニアならば読んでいて楽しくなってくるはず。日々、現場で「どうしてこういうことをするのですか？」と、作り手に詰め寄りたくなるExcel帳票を見ている私としては、「必読書」として自社で推薦したいです。

　そして、ますますExcelの奥深さにハマりそう……。勉強、勉強！

●おまけ：編集部おすすめのExcelコラム

・次世代ソフトを提案する。　―Microsoft編―

　同じくヘルプデスクのコラムニストがつづる、次世代ソフト妄想。「ExcelとWordの究極合体「Exord」(エグゾード）」は必見。

・Excelの必殺技（101回死んだエンジニア）

　Excelは使う人によって、驚くほどの差が出る。見た人が「格好良い！」と鼻血をふくほど華麗にExcelを使いこなせるエンジニアになりたいものだ。

エンジニアのための図解思考 再入門講座 開米瑞浩（著） 翔泳社 2010年10月 ISBN-10: 4798122750 ISBN-13: 978-4798122755 2310円（税込）

■図をつくったけどなんかいまいち、というコトってあるよね？

　仕様書などのドキュメントを書いていると、「ここは図示したい」「図を描いてみたけどどうもいまいち」ということ、営業が作る提案書がやたら格好良くて「自分もあんな風につくれたら」と思うことがあるはず。少なくもぼくはある。

　そんな気持ちで手に取ったのが、本書『エンジニアのための図解思考　再入門講座』。説明に「本書は、エンジニアの情報理解・伝達のスキルを飛躍的に向上する『図解思考』のノウハウを手ほどきする指南書です」とある。後述するが、即効性を期待してはならない。本書はじっくり、腹を据えて読む本だ。

　著者の開米氏が発行するメールマガジン「開米瑞浩の『知識を図解し教える技術』」を購読しているエンジニアは多いかと思う。ぼくもこのメルマガで氏を知った1人だ。メルマガには本書のような練習問題があるが、メルマガの性質上、どうしても流し読みになってしまう。だから、書籍であることはありがたい。

■ボリューム感満載の章立て

　さて、章立ては下記のとおりである。

• 第1章　図解はなぜ必要か？
• 第2章　図解力を伸ばすコツ
• 第3章　「ラベル」で問題を一気に単純化する
• 第4章　「表」があなたの思考地図になる
• 第5章　「仮説思考」で発想を引き出す
• 第6章　プロセスに関する共通認識を作る
  ：
  ：
• 第15章　モチベーションを上げるヒント

　なんと15章もある。見出しが丁寧に書かれているので気になるところから読み進めよう……といきたいところだが、前章とのつながりがある章が多いので、頭から読んだ方が無難だろう。

　さても、なぜこんなに章が多いのだろう？ 章はある程度「第○部」としてまとめられなかったのかと疑問に思った。しかし、あとがきを読んでこの謎は解けた。本書は雑誌『ITアーキテクト』の連載に、前半を大幅に加筆・編集したものだった。それ故、このような構成なのだろう。

※とはいえ、13章で「とりあえず3つに分ける」と言っているのだから、もう少し何とかならなかったのだろうかとも思う。

■豊富な練習問題を実際に解いてみる

　本書の特徴は、豊富な量の練習問題だ。しかもエンジニアなら「ああ分かる分かる」といった状況の問題が多いから良い。

　第3章までは、ウォーミングアップと言ったところ。著者の「分かってもらえなかった」挫折の経験談などが興味深い。

　第4～6章では「セキュリティの脅威の考察」といった、エンジニア向きの題材を取り扱う。この部分の展開は圧巻である。文章を表（大抵の人はマトリックス系のいわゆる「表」で終えてしまうのだが）にしつつ、それを発展させた最終型が、とにかく素晴らしい。図にしか見えないが、著者に言わせると「これも表」とのこと。

　「タテ方向、ヨコ方向のいずれでも、同じ一直線のライン上に同じ種類の情報が並ぶように情報を配置したもの」が表。

　この説明を読んで、納得した。納得したが、ここまでたどり着くのは至難の業だった。見慣れない表なので、ぱっと見では読み手は「なんだこれは」と思ってしまうだろう。しかし、読み手に対面で説明する場合は、力を発揮しそうだ。

■携帯の説明書ってこんな分かりにくいものだったのか

　第7章以降も、ひたすら練習問題が続く。「家庭用漂白剤の注意書き」「携帯端末の操作説明書」という、ITとは関係ない、しかし身近な題材ので考えやすかった。

　読んでいてつくづく実感したのが「普段からこんな分かりにくい文章を解釈させられていたのか！」ということ。これらの分かりにくい文章が、あれよあれよという間に分かりやすい形になっていくのは面白かった。

■忙しいエンジニアのための読み方アドバイス

　冒頭に書いたように本書は、腰を据えて練習問題を実際に解きながら、じっくり読みたい。しかし、そのためにはかなりの時間が必要だ。いわゆる普通の「ノウハウ本」ではないので、興味のあるところをつまみ食いという読み方は適さない。

　だから、まとまった時間が取れないエンジニアにとっては、ややハードルがやや高いかもしれない。本書は、休みが取れた時に一気に読んでしまう読み方が良さそうだ（実際、ぼくもゴールデンウィークに一気読みした）。一度読んでしまえば、全体を俯瞰（ふかん）できるようになるので、気になる見出しをピックアップして読めるようになる。

　ただし、読み終えればそれで図解思考がつくかというと、もちろんそんなことはない。結局、3章「ラベリング」、12章「1日3分見出し付け」を普段からきちんと行えるか否かというところが肝になる。そして時々、15章に書いてあるモチベーションについての記述を読み返してやる気を保つ。そんな使い方をお勧めする。

ITの専門知識を素人に教える技 開米 瑞浩、森川 滋之（著） 翔泳社 2008年7月 ISBN-10: 4798117072 ISBN-13: 978-4798117072 2394円（税込）

■ヘルプデスク、人に説明する技術の重要性を考える

　「ブルースクリーンって何ですか？」

　ユーザーにこう聞かれたら、どう答えますか？ ヘルプデスクとして、私はよく「擬人化」して説明しています。

　「人間に例えると、歩いてたら急に心筋梗塞（こうそく）などでバタッと倒れて意識不明になってるような状態です。その後、その人が蘇生するか亡くなってしまうかは、発見の早さや処置の的確さ、症状の重さなどで左右されますが、PCの場合は蘇生率は比較的高いですから安心してください」

　……と、ニコニコ答えつつ、サクッっと対応。この回答が技術者としてどうなのかはともかく、ヘルプデスク業務において「ユーザーに分かりやすく説明すること」はとても重要です。と、同時に「納得してもらうこと」も非常に重要だと日々感じています。

　ですから、本書を見つけた時、「これは私に必要な本だな」と、まず感じました（一般ユーザーや初学者を「素人」と表現するのはあまり好きではありませんが……）。

　本書はいわゆる「表現のコツ」ではなく、「人に何かを教える技術＝ティーチング」（ITに限らない）の本質とその実践について紹介しています。あくまで、教えるための「技術」について述べた本です。

■そもそも「教える」ってどういうこと？

　ティーチングとは、何か。まずは、このことを理解する必要があります。

　ティーチング、コーチング、プレゼンテーションは往々にして混同されがちですが、本書は以下のように区別して定義しています。

• ティーチングは「あなたがやってください」
• プレゼンテーションは「私がやります」

• ティーチングは「相手がまだ知らないこと」を教えること
• コーチングは「相手がすでに知っていること」を使って「自分で気付く」ことを支援する

　それぞれの持つ本質が違うため、実施する側が準備することやゴールは、当然のことながらすべて違います。

■「教える技術の17原則」

　本書は人に教える際に重要となってくる「構造化→シナリオ→アクション」の3段階について、全部で17のノウハウを解説しています。それぞれの項目を見てみましょう。

・構造化

　人に教えるためには、まず「教える対象」についてよく理解しておく必要があります。知識を「構造化」することで、講師の頭を整理しておくわけです。

・シナリオ化

　次に、重要なのは「シナリオ」化です。シナリオ化とは、構造化した知識をいかに記憶に残るように解説するか組み立てること。ここまでが教えるための準備段階です。

・アクション

　最後はいよいよ、実際に教える段階です。池上彰さんの解説を思い出してみてください。とても分かりやすいですよね。受講者に質問をしたり、身振り手振り、声の出し方、動きなどにいろいろな工夫が施されています。「構造化」して練り上げた「シナリオ」を、いかに記憶に残るよう解説するか――それが成功するか否かは、講師の「アクション」にかかっているといっても過言ではありません。　

■資格取得や技術書を読む際にも、意識しておきたい

　これまで、ヘルプデスク業務においてユーザーからさまざまな質問を受け、解説してきましたが、確かに思い当たる点はたくさんありました。

　自分なりに構造化やシナリオ化できている知識については、自然と良いアクションになるのか、ユーザーさんから「そういうことか！」「分かった！」と、理解と喜びの反応を得られます。逆に、教科書的で分かりにくい説明しかできない知識については、「うーん、よく分からないけど解決したし、もういいや」という顔をされてしまって、自分の未熟さを痛感することもありました。

　教える立場にいる人間は、単に資格を取るとか技術書を読むだけでなく、構造化とシナリオを意識しながら「資格やスキルを取得した“先”」を見据えて勉強することが重要なんだと感じました。“先”とは、例えばユーザーや後輩などに得た知識を説明する時、アドバイスを求められた時などが挙げられると思います。もう、先輩に「資格なんて取っても、実務では大して役に立たない」なんて言わせないのだ！！

■現場に近い感覚で、教える技術のシミュレーション

　本書は、ティーチング技法を解説した後、実際に起こりうる場面を想定した練習問題を用意しています。練習問題では、ティーチング技法をどのように生かせばいいのか、現場に近い感覚でシミュレーションできます。

　個人的に役立ったのは、OSIレイヤ3やL3スイッチの説明です。ちょうどネットワーク関連の資格の勉強をしていたのですが、実例がとても分かりやすくて知識の整理に役立ちました。

　また、私は運用系のため、残念ながら開発経験はありませんが、ポインタの説明は非常に興味深く読めましたし、PMBOKなどプロジェクトマネージャ向けの説明も興味を引かれました。これらの知識は、現時点での業務に直結するものではありませんが、開発者としては素人の私にとって、技術書を読むより理解しやすくて興味をかき立てられました。

　本書の具体的な説明で100％理解できなかったとしても、それは別に構わないと思います。そもそも、教育とは「自分でやる（ように仕向ける）もの」です。「面白いから、もうちょっと勉強してみよう！」という気になった私は、筆者の思うつぼにまんまとはまっていますね（笑）。

■まとめ

・本書に書かれていること

• 教えるとはどういうことか
• 教えるために必要な、「企画→資料収集→教材作成→教育の実施→フォローアップ」の解説とノウハウ

・どんな人に読んでもらいたいか

　私のようなヘルプデスク、企業や現場で教育・研修には担当者にはぜひお勧めしたい1冊です。ですが、エンジニアが「自分は教育担当じゃないから関係ない」と、購読リストから外すのは非常にもったいないと思います。例えば、構造化とシナリオに関するノウハウは、「現場の業務改善」を検討する際にも応用できそうな知識です。

　もしかしたら、これは筆者の狙いかもしれません。なぜなら、「ティーチング」の重要な役割の1つに、「学習者が自ら能動的に学習し、理解を深める」ことがあるからです。

　本書は単なるノウハウ本ではありません。学習者＝読者が、日々の業務で自分なりのティーチング技法を身に付けていくだけでなく、ノウハウを応用すればどんな業務にでも生かせるのだ、という大事なことを「教えて」くれている本なんだな、と思います。

パブリックスピーカーの告白――効果的な講演、プレゼンテーション、講義への心構えと話し方 Scott Berkun（著） 酒匂寛（翻訳） オライリージャパン 2010年10月 ISBN-10: 487311473X ISBN-13: 978-4873114736 2310円（税込）

　顧客への機能説明や勉強会でのライトニングトーク……エンジニアには何かとプレゼンの機会がある。
　
　どんなに経験豊富なスピーカーでも、プレゼン前には緊張する。本書によると、かのエルビス・プレスリーやU2のボノなど、「人前に出る達人」のような人であっても、コンサートの前に緊張しないことはなかったという。

　では、そんな緊張に打ち勝ち、素晴らしいプレゼンを成し遂げるために、わたしたちは何をすべきか。本書は、効果的なプレゼンをするためのさまざまなアドバイスを提供してくれる。

■プレゼンへの恐怖は生きるための恐怖

　「プレゼンのせいで命を落とした」という話はあまり聞いたことがない。なのに、なぜわたしたちは人前で話すことにあれほどの恐怖を感じるのか。わたしたちの脳には、プレゼンという状況に恐怖を抱かせる能力が備わっているのだという。

• 1人で立っている。
• 広いところにいて隠れる場所がない。
• 武器を持っていない。
• あなたをじっとみつめる生き物の大群の前にいる。　

　すべての生き物の長い歴史において、これらの条件がすべて満たされる状況はどのような場合でも非常にヤバイ状況でした。それはまもなく攻撃され生きたまま食べられる可能性が高いことを意味していたのです（p.15)。

　本書によれば、プレゼンに対する恐怖は「本能」に由来する。生命を脅かすものから自分の身を守るため、わたしたち生物は恐怖を感じるようにできている。肉食動物に捕食される危険性がほとんどなくなった現代においても、その本能は消えていない。
　
　つまり、プレゼンに対する恐れや緊張は、決して遮断できないのである。しかし、恐怖を遮断することはできないまでも、意識してある程度制御することはできる。

■プレゼンを支配するための秘けつは「練習」

　この先、何が起きるか分からない。そんな不確定なものに対してもわたしたちは恐怖する。裏を返せば、次に何が起きるかを知っていれば、わたしたちは恐怖の大部分を抑制できる、ということだ。

　プレゼンの場において、スピーカーは「次に何が起きるか」を知っている。スライドのタイミングや話のオチ、これらはすべてスピーカーが決めたことだからだ。プレゼンの全体像を把握し、安心を得る。そのための唯一の方法は「練習」である。
　
　本書は、特定の章に限らずあらゆる段落で、「練習の重要性」を繰り返し説明する。　

　現実の聴衆に向かって話すときには、まったくの初めてではなくなっています。実際、3、4回練習した頃には重要な論点をどのように構成していくかを覚えてしまっているので、スライドなしでもまあまあのプレゼンテーションができるようになります。練習することで得られる自信のおかげで即興で何かを挿入したり、野次や厄介な質問、退屈した聴衆、機材の故障など、講演の途中で発生する可能性のある予期しない出来事に対処することができます（p.21）。

　私の聴衆に対する最大の有利な点は（中略）次に何が起きるかを私は知っているということです。（中略）これを良く行うためには、たくさん練習する必要があります（pp.94-95）。

　繰り返し行う練習こそが、わたしたちのプレゼンを良きものにする一番の近道なのである。

■実践的な指南

　本書では、プレゼンを成功させるための心構えや練習の重要性以外にも、興味深い実践的なテクニックがいくつか紹介されている。

1. 2000席の会場に45人しか聴衆がいない場合に、講演を成功させる方法
2. 聴衆を退屈させない方法
3. テレビという特殊な世界でのプレゼンの方法
4. 自分のプレゼンに対するフィードバックを得る方法

　「テレビに出る場合の対処方法」などは、自分はテレビになど出ないから必要ない、と思われるかもしれない。しかし、最近ではYouTubeやUstreamなど、ディスプレイ越しに自分のプレゼンが他人に見られる機会も多くなっている。そういう可能性のある人は、読んでおいて損はないだろう。

■明日プレゼンをしないといけない人も

　「自分は明日の会議でプレゼンをしないといけない。本を長々と読んでいる場合ではない」という方も、安心して本書を手に取ってほしい。

　本書には、「バックステージノート」という章がある。これは、本書が紹介しているあらゆる手法をまとめたTips集である。この章だけ目を通せば、多くの参考にできる事例に出合えるだろう。

　また、本書の最後には、さまざまなプレゼンの達人たちによる失敗談が書かれている。これは、他人の面白おかしい最悪なプレゼンのエピソードを知っていれば、自分のプレゼンが失敗しても「ここまでひどくはなかった」と安心できるだろう、という著者の配慮である。読者に対するメンタルケアまで万全だ。

■人前で話す機会を与えられたすべての人に

　以上のように、本書ではプレゼンに必要な心構えやテクニック、そして他人の失敗談に至るまで、読者が良いプレゼンを行うためのあらゆることが書かれている。それは時にユーモラスに、時に理論的に、達人のプレゼンさながらに読者を決して飽きさせない。

　この書評を読んでプレゼンに興味が湧いた方がいたとしたら、まず本書を読み、そしてどこかの勉強会などでライトニングトークにチャレンジすることをおすすめする。

　きっとこれまでの人生で得られなかった、エキサイティングで楽しいひとときが待っていることと思う。

群れのルール――群衆の叡智を賢く活用する方法 ピーター・ミラー （著） 土方奈美（翻訳） 東洋経済新報社 2010年7月 ISBN-10: 4492532722 ISBN-13: 978-4492532720 1995円（税込）

　なぜ、人員を増やしたりスケジュールを引き直したりしても、プロジェクトは遅れるのか？

　なぜ、高い技術を持つプログラマを集めてチームを作っても、チームとしての生産性が向上するとは限らないのか？

　知の巨人に聞いても、容易に回答が得られない難問である。知の巨人でも難しいなら、いっそのことアリに学んでみるのはどうだろうか？

■個体の能力は低いが、チームになると賢い「組織のプロ」

　本書は、「組織のプロフェッショナル」の豊富な事例をもとに、効率的な組織の回し方、生産性向上という難問の解決方法、火を噴いたプロジェクトの改善案を紹介している。

　しかし、先生である「組織のプロフェッショナル」は、かなり頼りない存在だ。10秒前の出来事を覚えていなかったり、体のサイズがとても小さかったり、天敵に食べられる危険にさらされている。

ムクドリの群れ。「あの群れは、実際には全体で1つの存在であり、通常の生物学の常識を超えた何らかの法則によって支配されているのではないだろうか」という推測もある（参考：「鳥の群れが「一体となる」仕組み」）

　本書で取り上げられるプロフェッショナル――アリやミツバチ、シロアリやムクドリは、個体それ自体としては、まったく賢くない。だが、ある一定数が集まると驚異的な組織力を発し、すばらしい仕事をやってのける。

　逆に、人間は、虫より圧倒的に優れた知識を持っているにもかかわらず、個体の能力を生かし切れないことが多い。「個体の能力は低いが、チームとしての成果は抜群」である昆虫や鳥たちに人間が学ぶところは多い、と著者は指摘している。

■「チームは静かなパニックによって破たんした」

　まず、なぜ組織がうまく回らないかを考えよう。

　ビール・ゲームという、生産流通システムに関するロールプレイングゲームがある。4人のプレイヤーはそれぞれ、ビールの「工場」「一次卸」「二次卸」「小売店」としての役割を与えられ、発注と納品を繰り返していく。初めのうちは特に問題はなくても、一度ズレが生じると、サプライチェーンは完全に制御不能に陥る。著者が紹介しているゲームの終盤では、小売店は深刻な在庫不足に陥り、一方で工場側はとんでもない過剰生産をしていた。

　「わたしのチームは静かなパニックによって破たんした」と著者は語る。一体なぜこんなことに？

　破たんの原因は2つあるという。「自分が頑張らなければ」と孤軍奮闘するヒーロー主義、そして「あいつらは信用ならない」という部族主義だ。

　飛行機を製造するボーイング社は、まさにビール･ゲームの無残な結果そのものの状況に陥っていた。「エンジニアが悪い」「テスト部門のせいだ」と、誰もが誰かを恨みながら孤軍奮闘していた。誰もがいつも忙しく、忙しいゆえにその場しのぎで問題を解決しようとした。その結果、別の部署や下流でとんでもない問題が生じてしまっていたのである（まるでデスマーチそのものだ）。

　自分たちが状況を制御しようとすることで、実際には状況をさらに悪化させていることにはまったく気づいていなかった。サプライチェーンの中の自分の持ち場だけに集中することで、システム全体の不安定化を助長し、その結果だれもがダメージを受けた。

■アリから学ぶ、分権的な組織とフィードバック

　ボーイング社のリーダーは、アリとミツバチに学んで問題解決に当たった。

　アリは、トップダウンで命令を受けているわけではないのに、適切なエサの場所を見つけ、壊れた巣をまたたく間に修復する（女王アリは子孫を増やすのが仕事で、指揮をするわけではない）。この現象を、研究者は「自己組織化」と呼んでいる。

●自己組織化の基本的なメカニズム

• 分権的な統制
• 分散型の問題解決
• 多数の相互作用

　アリは、ごくシンプルなルールに従う以外は、行動の制約がない（分権的な統制）。エサを取りに行くアリが、緊急事態には巣のメンテチームに入ることもある（分散型の問題解決）。また、ほかのアリからのフィードバック（帰ってくるのが遅い＝こちらの道は遠い）を受けて、自らの行動を変える（多数の相互作用）。

■ミツバチから学ぶ、意見の多様性と意思決定

　また、ミツバチは多様な意見を出し合いながら、新しいすみかの場所を決めている。

●ミツバチの行動ルール

• 知識の多様性を求める
• 友好的なアイデア競争を促す
• 選択肢をしぼりこむ効果的な方法を使う

　新しいすみかの場所を選定する偵察バチが数十匹、めいめいに自分が推せんする場所のアピールダンスを踊る（知識の多様性）。これらの意見はすべて議論の俎上に載り、ほかのハチはアピールに従って自由に場所を見にいく（友好的なアイデア競争）。下見に行ったハチが「これはいい」と思えばさらにアピールダンスを踊り、やがて選択肢はしぼりこまれていく（選択肢をしぼりこむ）。

　ボーイング社のリーダーは、これらのルールをデスマーチ回避策に応用した。また、筆者はほかにもガス会社の資源分配の最適化や大規模な停電障害の問題解決などに当てはめて解説している。

　キーワードは「分散」「意見の多様性」「フィードバック」だ。虫や鳥は、明確な指揮系統を持たずとも、最適な解を見つける方法を身に付けている。彼らの方法を模倣するのは容易ではないし、必ずしもそうする必要はないが、組織の在り方を考える参考になる。

■正統派のビジネス本ではないが、示唆に富む

　本書は、いわゆるチームビルディングや問題解決のノウハウが詰まった、正統派のビジネス本ではない。「群れは暴走する危険をはらんでいる」と、著者自身が指摘しているとおり、群れのルールは一歩間違えば大変な事態を引き起こす。だが、複雑なシステムや煩雑なルールを改善したい人にとって、思考のヒントは得られるだろう。

　何より、本書は読みものとしてもなかなか面白い。著者はナショナルジオグラフィック誌のシニアエディターで、北極でホッキョクグマを追いかけ、メキシコでは殺人バチに追いかけられた経験を持つ人だ。話の引き出しが多く、新しい世界をのぞく楽しさがある。

　チームの生産性がちっとも上がらないことに悩むプロジェクトマネージャ、デスマーチを別の角度から眺めたいプログラマ、「組織」という不可思議な存在に興味を持つ人に、本書を勧めたい。

アプレンティスシップ・パターン 徒弟制度に学ぶ熟練技術者の技と心得 Dave H. Hoover、Adewale Oshineye（著） 柴田芳樹（翻訳） オライリージャパン 2010年7月 ISBN-10: 4873114608 ISBN-13: 978-4873114606 2310円（税込み）

■新人ソフトウェア技術者のための「学びのパターン」

　「無知をさらけ出す」「自分の地図を描く」「良き指導者を見つける」「自分の仕事を省みる」「フィードバック・ループを構築する」「古典を学ぶ」……「良い」とされているけれど、なぜ「良い」のか体系だってまとめられることの少ない、ソフトウェア技術者に必要なスキルアップのための行動というものがあります。日々、なんとなく行っていたり、あるいは行わなければならないと思っていたりする行動パターンが、皆さんにもあると思います。

　本書『アプレンティスシップ・パターン』は、新人のソフトウェア技術者が「熟練職人」になるための行動パターンをまとめたものです。産業革命以前の中世ヨーロッパに広く普及していた職人たちの「ギルド」における従弟制度をモデルにしているところがポイントです。

　ギルドが熟練職人（master）を管理する。熟練職人は工房を持つ。そのもとにジャーニーマン（journeyman：熟練職人には到達していない職人）がいて、技芸を学ぶ。ジャーニーマンは旅をして技芸を都市から都市に伝え、アプレンティス（apprentice：従弟）を監督する――これが当時の従弟制度です。著者は、このモデルをそのまま現代のソフトウェア技術者の世界に適用するのは実用的ではないとしつつも、参考にし、「現代的な工芸スタジオを選ぶことができる」と主張しています。

　現代において、新人ソフトウェア技術者が良き職人から指導を受けられる制度は確立していません。職場に、あるいは新人が配属されたチームに、良き職人がいるかどうかは確率論でしかありません。だから新人ソフトウェア技術者は、自分なりの「従弟制度」を見つけ出し、確立する必要があります。本書に収められている行動パターンは、そのための指針として役立ちます。

■良いパターンは成功例から語られる

　本書に収められているパターンは、優れたソフトウェアフレームワークやデザインパターン同様、正常に機能しているシステムから抽出されている、とされています。著者が出会ってきた熟練職人たちの「経験」の話から形作られているのです。

　いくつか列挙します。

• 情熱を放つ（Unleash Your Enthusiam）
• 無知をさらけ出す（Expose Your Ignorance）
• 無知に向き合う（Confront Your Ignorance）
• 持続可能なモチベーション（Sustainable Motivations）
• 自分の地図を描く（Draw Your Own Map）
• 良き指導者を見つける（Find Mentors）
• 気の合った者同士（Kindred Spirits）
• 練習、練習、練習（Practice, Practice, Practice）
• 壊してよいオモチャ（Breakable Toys）
• 学びを記録する（Record What You Learn）
• 学びを共有する（Share What You Learn）
• 継続した読書（Read Constantly）
• 古典を学ぶ（Study the Classics）

　パターン名を見ただけで、何となく想像のつくものが少なくないと思います。「熟練職人」であれば、「そう、それは大事なんだよ」と、見ただけである程度理解できるかもしれません。逆に「どういうこと？」と首をかしげてしまう新人＝アプレンティスの方は、本書を手にとって、気になるパターンだけでも目を通すと良いでしょう。いくつかのパターンに目を通していると、やがてそれぞれのパターンがリンクし、どう影響し合っているかが見えてきます。

　具体的な例を挙げましょう。エンジニアライフ コラムニストの鹿島和郎氏は、新たにScalaを学ぶべく、関連コミュニティや勉強会を探して参加したり、自ら入門書を読む勉強会を立ち上げたりしています。これは「学びを共有する」「無知をさらけ出す」「白帯」「学びを記録する」「気の合った者同士」の5つのパターンの実践である、と鹿島氏は語っています（もしかすると、ほかのパターンも含まれているかもしれません）。

　同じくコラムニストのkwappa氏は、「良き指導者を見つける」ことの重要性を、自らの「師匠」の思い出を語ることで表現しています。

■学びの環境を構築する

　「ソフトウェア開発は技芸です」と著者は語ります。科学のように、体系化されたものとして扱うほどに、わたしたちはソフトウェア開発を理解し切れていない、というのがその理由です。

　だからこそ、技芸としてのスキル伝承パターンを構築する必要があります。その意味で、よくあるマネージャやリーダー向けの「新人はこう育てろ」的なアプローチではなく、新人に向けて「こうやって学ぶ環境を構築しろ」と伝える本書には大きな意義があるといえます。自分の学びの環境は、自ら構築しなければならないからです。

　本書は翻訳に難があるのか、少々読みにくい部分もあるのですが、「熟練職人」を目指す新人ソフトウェア技術者であれば、読んで損はないでしょう。