「How to Change the World 〜チェンジ・マネジメント3.0〜」を読み終えました。

　以下、自分用のメモ書きですが、感想などを。

クイック・ウィンは、フィードバックを増幅し、その結果、生み出されたものを集約し、さらに多くのポジティブな変化を生み出すのに役立つ。
頻繁なフィードバックは大事で、そのスピードに対応できるだけのチームや組織の実力なんかも必要だと思いました。

ADKAR モデル
5番目に「補強（Reinforcement）」ってのを定義しているのが興味深かったです。
実際に変化を起こす際には重要な要因だと思います。

彼らはそれが自分自身の心地よさにつながると考える時にも行動を変える！
この辺のイメージをうまく伝えて、自分も含めたチームが自分達の中にその「心地よさ」を持つことができるか？というのが大事だと思いました。

変化の結果を恐れるため、変化は望ましくないと考えている。
変化した後もその人が重要と考えることを(それまでと同じ形でないにせよ)提供できる･･･ことを保証できれば、強力な味方になることもあると思います。
それを提供できるか？というのは簡単なことではないかもしれませんが。

「ありがとう」の言葉だけで、人々のよい行動を認知をし、やり続けさせるに十分なこともよくある。
こればっかりでも困るけど、これがあるだけで、頑張れる、アクションを起こす動機にはなりうると思います、少なくとも自分は。

組織で変化を促そうとするなら、いくつかの異なるメッセージとやり方を使い分けて、異なる人々に対処していくことになるだろう。
まさにそうだと実感しています。これを十把一からげにしてやろうとするから、結局何にも変化しないものになってしまいます(で、リソースだけが消費される･･･というパターンで)

よい仕事をするための正しい下地を作ること
良い表現。
自分の想いだけが先走り過ぎて、結局アウトプットや変化に至っていないのも多いので注意しないと。

物事がうまくいっているように見えるときは、自己満足に陥っているだけだったり、終わったと 勘違いしているのかもしれない
これは自戒を込めておかないと落ち込んでしまうと思いました。
チームのふりかえりと一緒で「自分自身のふりかえり」を客観的、定量的にできるようにする･･･などの工夫がいるかなぁと。

人の振る舞いを変えるためには、彼ら自身を変えるかわりに、環境を変えることを考えて欲しい。
自らの意志がないと変わらないよってことで。
変えることはできなくても、変わることのお手伝いはできるかもしれませんが。
で、それがここで言っている「環境を変える」ことと理解しました。

よい結果に対する褒賞はよい振る舞いに対する褒賞とは異なることを覚えておこう。
これは結果だけを見るのではなく、そのプロセスを見るってのも大事ということと理解しました。

最初は入り込むのがちょっとしんどい印象があったけど、すぐにグイグイ引き込まれていきました。
おそらく翻訳者がよく知っている方々なので、安心感があったというのも関係していると思います。

※注意：この記事は旧サウスポーなエンジニアの独り言から移行し一部修正したエントリです。

コンサルタントの道具箱

(本棚を整理していて)久しぶりに読み返してみた本です。
数年前にこの本を買った時は、そこまでしっくりこなかったように思います。
ですが、今の自分が読み返して「あぁそういうことかぁ」と思うことが多くありました。

目次

イチゴジャムの法則
知恵の箱
金の鍵
勇気の棒
願いの杖
探偵帽と虫めがね
イエス・ノーのメダル
ハート
鏡
望遠鏡
魚眼レンズ
ジャイロスコープ
卵、カラビナ、羽根
砂時計
酸素マスク

題名が「コンサルタントの～」となっていますが、「コンサルタントのための」ではなく、もっと広く捉えて「人生を豊かに生きるための道具箱」と感じました。
目次のそれぞれが道具箱にある道具を示しています。

私が印象に残った部分です。
「やるべきでないことは、いっさいやるべきでない。以上。」
最近、似たようなアドバイスをもらったことがあって、余計に響きました。

「不変の言葉」
「願いの杖にできること」
「1969年の雪嵐」
当たり前だと信じている(誰しもが疑わない)前提、状況は視点を変えると覆すことができるかも？というエピソードです。
私も今の状況がいくつかの「当たり前」に対して、「こんな風にしてみたらもう少し良くなるのでは？」と言っていく必要があるので、響きました。

「自分とデータの間に三角形があるときは、斜面を選ぼう」
これは普段から心がけている行動指針の1つでもあるので、良い言葉だなぁと思いました。

「(提示された内容には感謝を示すことができなくても)提示してくれた『コト』自体に感謝すれば良い」
「フィードバックは、非難ではなく助言だと考えよう。」
「パーソンの特異性原則」
ここにあった「相手が奇妙な行動をとっていたら、たぶん奇妙なものに反応しているのだ。それはたぶん自分である。」という文章は、知らず知らずのうちに相手にそういう印象を与えていないか気をつけないと…と響きました。

「今のところはね…」
「ジェリーのプロジェクト期間の鉄則」にある「完璧主義はスケジュールの敵である。妥当性はスケジュールを救う」
　

※注意：この記事は旧サウスポーなエンジニアの独り言から移行し一部修正したエントリです。

<

div class=”yellowbox”>小さなチーム、大きな仕事―37シグナルズ成功の法則 (ハヤカワ新書juice)

「37シグナルズ」の理念を書き記しています。
ページ数は多くなく、また簡潔に書かれているので非常に読みやすいです。
読みやすい故にサラッと流れてしまいそうですが、1つ1つを自分に当てはめて考えみると、色々と思うところがありました。
＃私も2、3回読んでいます。

◆目次
まず最初に
見直す
先に進む
進展
生産性
競合相手
進化
プロモーション
人を雇う
ダメージ・コントロール
文化
最後に

仕事依存症はバカげている
無闇な仕事依存症は確かに効率が良くないと思います。
けれど、仕事の種類の区切りを明確に分けていて、かつ、情熱、モチベーションを持っているのであれば、(ある程度の期間であれば)良いのでは？と思いました。

おそらくここで言いたいのは「やるべきこと、やらないでいいこと」を判断せずに、ただ「仕事があるから」という理由だけでするのは…と思っています。

この辺はこっちのエントリにも書いた「やるべきでないことは、いっさいやるべきでない。以上。」と通じるものがあると思いました。

あなたに必要なものを作る
今手掛けているサービスでは(ありがたいことに)「自分だったらこういうのがあったら嬉しいよなぁ」というアイデアを取り入れる余地があります。
で、特定のお客様向けへのシステム開発でも「自分だったら…」の意識を持ってみると、その質が良くなるのでは？と思います。

「時間がない」は言い訳にはならない。
「失敗から学ぶこと」は過大評価されている
　フリカエリなどでも「ダメだったこと」「うまくいかなかったこと」を挙げて「じゃ、次どうしようか？」という話をすることがあります。
　(それも必要かもしれませんが)それよりも「今回うまく行ったこと」を明確にして、ノウハウとして共有した方がチーム、組織としては有効です。

中途半端な製品ではなく、半分の製品
会議は有害
会議はそれなりの規模の組織であれば、かなり数多くあり、かなりのリソースを使っています。
当然、それなりの意思決定をしようということも多いのですが、その割にはアウトプットがいまいちな会議が多いのも事実です。
これらをファシリテートできれば、それこそコスト削減や競争要因になります。

小さな勝利を手に入れる
1、2週間毎に成果を出せるようにしたり、プチフリカエリを行って成長を認識する…という感じかと思います。

あなたの見積りは最悪だ
観客をつくる
料理人を見習う
会社を「知人のいないパーティー」にしない
　プロジェクト毎にお互いのことをほとんど知らない…それこそ同じ組織に属する程度…ような状況で良いパフォーマンスができるわけはありません。
こういう組織の管理職ほど「頭数を揃えばできる」と思っていて、「とりあえず人を追加しようか？」などという発言が多いように思います。

全員が働く
ダメージコントロール
大げさに反応しない
ひらめきには賞味期限がある

この本に書かれているようなことが出来ていけば、良い組織になると思いますが、組織、部門の規模が大きければ「すぐに変える」というのは難しいかもしれません。

ですが、グループ、チーム…極端に言えば自分自身…であれば、良い提案、アクションはすぐに実施し、自分でその効果を出せることが多いと思います。

※注意：この記事は旧サウスポーなエンジニアの独り言から移行し一部修正したエントリです。

ワンランク上の問題解決の技術《実践編》 視点を変える「ファンクショナル・アプローチ」のすすめ
著者：横田 尚哉

問題解決がテーマの本は色々読みましたが、その中でも良書の部類に入ると思います。

ポイントは題名にある「ファンクショナル・アプローチ」という手法です。
ある程度、この分野(問題解決)の知識、経験があれば題名の通り「ワンランク上の」考え方として使うことができると思います。

◆目次
1章 ワンランク上の問題解決とは
2章 実践ファンクショナル・アプローチ―ステップ1・準備
3章 実践ファンクショナル・アプローチ―ステップ2・分解
4章 実践ファンクショナル・アプローチ―ステップ3・創造
5章 実践ファンクショナル・アプローチ―ステップ4・洗練
6章 日常をファンクショナル・アプローチで考える
終章 目標に向かって、とるべき針路を見つけよう
付録 ファンクショナル・アプローチ・シート

私が印象に残った箇所を羅列すると…。

問題解決のカギは「問題の認識」と「改善点の特定」

ワンランク上の問題解決をもたらす思考のルール

1：固定観念にしばられず、前回と違った方法を試してみる
2：手段にこだわるのではなく、改善点に焦点を当てる
3：「見落とされている改善点」を探す
4：過去を手放し、未来のあるべき姿から発想する

身体的/精神的に疲れていて、余裕が無い状態だと安易に↑の思考に陥ってしまい、せっかくの問題解決の機会を逃していないか自問します。

「それは何のため？」「それは誰のため？」

これらの答えに窮するのであれば無駄な努力(＝そもそも目的がおかしい)というロジックです。
似たような思考で、私は「これが解決すると誰がハッピーになる？」と考え、そしてそのハッピーになる人物にとって「どうあって欲しいか？」と思いを巡らせ解決策を考えたりします。

「手段志向」よりも「目的志向」

(上の話と似ていますが)問題/課題に対して「どのように～」と考えるのが手段志向で、「何のために～」と考えるのが目的志向であると定義し、目的志向で考えていきましょう(これが本書でいう「ファンクショナルな視点を持つ」ということ)ということです。

より効果的な解決手段を見つける5つのヒント

1：使用者優先の原則
2：機能本意の原則
3：創造による変更の原則
4：チームデザインの原則
5：価値向上の原則

ファンクショナル・アプローチの4つのステップ

準備→分解→創造→洗練とありますが、特に「分解」の記述は興味深いものでした。
上位/下位を設定したファンクションに対し…
「もし上位ファンクションが必要なくなれば、下位ファンクションも必要なくなるか？」
「下位ファンクションは、上位ファンクションの達成に役立っているか？」
「もし下位ファンクションが機能しなければ、上位ファンクションはまだ機能しないか？」
…と問いかけし、それに違和感があれば、問題/課題に対する目的が間違っているというロジックです。
そしてそれらを繰り返す中で問題/課題の本質であるキー・ファンクションを見つけ出していくという内容です。

ひょっとすると他の問題解決の手法や考え方を知らない方が読むと比較検討ができなかったりして、理解が少し難しいかもしれませんが、何度か読み、実践をこなすことで「あ、そういうことか！」と分かると思います。

※注意：この記事は旧サウスポーなエンジニアの独り言から移行し一部修正したエントリです。

Photo credit: Create-Learning Team Building & Leadership via Visualhunt / CC BY

1回の会議・打ち合わせで必ず結論を出す技術
著者：斎藤 岳

題名の通り、会議/打合せでいかに(参加者全員が納得し、次のアクションへつながる)結論を出すかを書いています。

◆目次
第1章 「結論を出す能力」を身につけよう(なぜ、会議の技術を学ぶのか
世の中に溢れる「メタボ会議」 ほか)
第2章 会議・打ち合わせを科学する(「結論が出る」メカニズムとは?
会議の「負のループ」を断ち切るには? ほか)
第3章 会議・打ち合わせの技術を知る(ゴールはなに?
アイスブレイク・巻き込み ほか)
第4章 困った!問題にどう対処する?(問題のある参加者にどう対応するか
グループが問題に直面したときにどう対処するか)
第5章 プロジェクトにおける会議のコツを学ぶ(「メタボ会議」ではプロジェクトは失敗する
難易度が高い会議では、準備が重要 ほか)

よく見かけるNGな会議/打合せを「メタボ会議」と名付け、それをなくすために「7つの心得」「11の技術」を紹介していくという流れになっています。

私が印象に残った箇所を羅列すると…。

「発散」「収束」のギアチェンジ

私自身が心の中で気をつけているつもりですが、参加者全員で共有できているか？、また、場の雰囲気がそうなっているか？までは辿り着いていないなぁと。

GAPのP(Point of view)

ハッとさせられました。G…Goal、A…Agendaは意識していてもPまで意識できているかは弱いかも…。

良くない会議の特徴

これに陥っていないか？をセルフチェックに使えそうです。

キーワード「今日のゴールはなに？」

特に社外のお客様との打合せに一緒に行くメンバーと事前に意識合わせをして「打合せが終わった時にどんな状態になっていればOKなのか？」を共有しておきます。

ラップアップ

色々話した末の結論の確認は大事で、これを怠ると「で、結局どうなの？」とまた振り出しに戻ってしまいまうこともあります。

後半の「困った人/状況への対応」部分は、後付けな感じがして少し蛇足かな？と思いましたが、前半…特に事例はOK/NGケースをそれぞれ対比しており、分かりやすく「すぐに実践できる」内容が多いように感じました。

※注意：この記事は旧サウスポーなエンジニアの独り言から移行し一部修正したエントリです。

Photo credit: shoothead via Visualhunt.com / CC BY-ND

「先読み力」で人を動かす(リーダーのためのプロアクティブ・マネジメント)
著者：村中 剛志

◆目次
序 章 先読み力ってなに?
第1章 あなたの先読み力を知る
第2章 先読み力を鍛えるタイムマネジメント
第3章 メンバーが躍動するチームマネジメント
第4章 成果を生み出すミーティングはこうつくる
第5章 チーム関係者を巻き込み成功に導く
終 章 リーダーに必要な三つのこころ

この本はプロジェクトリーダーとして「どうすればメンバーのレベルを上げて、良い仕事ができるだろう」と(いつも以上に)強く思っていた時に読み、題名にもなっているキーワード「プロアクティブ」が強く心に残った、私にとっては最近の良書です。

「プロアクティブ」とは「指示待ち」や「トラブルや問題が発生してから動く」(＝リアクティブ)のではなく、「自分から動く/アクションを起こす」ことです。
自分自身をプロアクティブにするだけでなく、チームメンバー/チーム自体をプロアクティブにしていくには？に焦点を置いているのも特徴です。

以下、自分(とメンバー)が意識したいと思うポイントです。

【「できる」人の5段階】

自分/チームメンバーのレベルを意識、共有して求めるレベルやレベルアップの方向性を考える必要があります。新人なのに「自分で考えてみて」なんてのはまだまだ早いというわけです。

【仕事の優先順位は四つの箱で考える】

タスクの優先順位付けとして有名な図(「緊急/緊急でない」「重要/重要でない」の4つの組み合わせでタスクの優先順位をつける)の話です。
目の前のタスクに忙殺されている場合、小1時間でもこれをすることでずいぶん楽になると思います。

【ミーティングのクォリティは事前に「段取り」で全て決まる】

(社内/社外を問わず)ミーティングでは事前準備やアジェンダは大事ですよということです。
ごくごく当たり前の話なのですが、様々な理由で「出たとこ勝負」になっているミーティングも時々見かけます。
たいがいそういうのは終わった後、「結局どうなったの？」ということになります。

【お客様がお客様社内で認められるために行動する】

前提として自分がお客様に認められるのはありますが、そこからさらに進んで…ということです。
組織としてのビジネスの側面も大事ですが、現場のプロジェクトリーダーとしては、やはりそこはお客様の成果を最大限に出来るように…と考えます。

【メンバーに依頼する時の5つのポイント】

「望む結果(ゴール)」やそのガイドライン、マイルストーン等を意識して伝えておきましょうということです。
この辺が曖昧なタスクだと、手戻りや余計な工数がかかっているといると思います。

【70%の力で働くすすめ】

メンバーに任せてうまく行かなかった時等、不測の事態に備えていつでもリーダーはある程度余力を残して(これが70％)、行動しましょうってことです。

「リーダーが一番働くべき」「メンバーより早く帰るなんて以ての外」という考えの人もいるようですが、それぞれの役目に応じたタスクがあり、その最後の砦としての役目も果たせなくなっては意味が無いと思います。

小難しいことを書いているわけではありませんし、図や表も色々と使われていて読みやすいと思います。
日常のタスクに忙殺されている人は、改善のきっかけをつかめるかもしれません。

※注意：この記事は旧サウスポーなエンジニアの独り言から移行し一部修正したエントリです。

Photo credit: thinkpublic via Visual hunt / CC BY-ND

ペアプログラミング―エンジニアとしての指南書
著者：Laurie Williams, Robert Kessler
翻訳：長瀬 嘉秀, 今野 睦, テクノロジックアート

今の小規模プロジェクトで、ペアプログラミングをしていました。
2人チームだったので常に同じペアでしたが、たくさんのメリット(と少しのデメリット)がありました。
#その辺りの話は別エントリで書きます。

そのペアプロ関連でこの本を手に取りました。

◆目次
第1部 理解の習得
(ペアプログラミングの7つの神話、ペアプログラミングの7つの相乗的な方法 ほか)
第2部 ペアプログラミングの開始
(オフィスレイアウト、ペアローテーション:コミュニケーション、ナレッジマネジメント、トレーニング ほか)
第3部 ペアプログラミングパートナー選択の原則
(専門家‐専門家のペア、専門家‐平均的なペア ほか)
第4部 ソフトウェア開発プロセスにおけるペアプログラミングのケーススタディ
(ソフトウェア開発プロセスケーススタディにおけるペアプログラミング:XP、
ソフトウェアケーススタディにおけるペアプログラミング:CSP)
第5部 おわりに(前進、限界の超越、有能なペアプログラマの7つの習慣 ほか)

翻訳ものですが、割と読みやすく感じました。

第1部は、いざ「ペアプロをしたい！」と思った時に、たいがい出てくる（上司、同僚、チームからの懐疑的な)意見と、それに対する対策や反論が、具体的な数字も含めて書かれています。
数字だけで導入を決定付ける根拠にはなりませんが、興味深い内容と思います。

第2部では、いざペアプロした時に、よりそのメリット引き出すにはどうしたら良いかが書かれています。

第3部では、色々なペア(経験豊かなPG-新米PG、内向的なPG-外向的なPG…etc)のケーススタディがユーモアを交え書かれています。
#典型的日本人同士でどうなるかも考察してみたいです。

どの章も、理論や方法論だけでなく、実際に著者の経験を元に書かれているようです。
最初に書いた今のプロジェクトでペアプロする前には「へぇ～、こんなもんかぁ～」で終わっていましたが、2度目はペアプロの最中に読んだので「そうそう！！これこれ！！」とものすごく共感できることが多く、「次も是非ペアプロでやってみたい」となりました。

ペアプロはそのやり方故にかなり食わず嫌いされている印象があります。
もちろん全てにおいて「ペアプロ万歳！」ではありませんが、「ペアプログラミング」はもっと評価されても良いアプローチと思います。

※注意：この記事は旧サウスポーなエンジニアの独り言から移行し一部修正したエントリです。

Photo credit: Menlo Innovations via VisualHunt.com / CC BY

速効!SEのためのコミュニケーション実践塾 (日経ITプロフェッショナルBOOKS)
著者：田中 淳子

私が定期購読している雑誌「日経SYSTEMS」の前身である「日経ITプロフェッショナル」の初期に連載を加筆、修正して単行本化したものです。

◆目次
第1部 基本編(顧客訪問―基本のビジネスマナーをしっかりチェックする
リスニング・スキル―深く正確に聞くためのテクニックを学ぶ
顧客説明―顧客に深く理解させる「説明力」を身に付ける
質疑応答―質問にしっかり答えて説明を締めくくる ほか)
第2部 応用編(先輩として手本を示す―“先輩らしく”行動し優秀な後輩を育てる
新入社員が配属されたら―きめ細かい配慮で後輩の不安を和らげる
新入社員をOJTで教育する―OJTの方針を明確にしてこまめに声を掛ける
新入社員の表現力を育てる―細かい点を見逃さず表現の間違いを正す ほか)
付録

基本編と応用編の2部構成ですが、基本編が大きくヒヤリングとプレゼン部分の2つに別れている印象です。

元が連載ものだったからか、簡潔に各項目をまとめられています。
だいたい1項目10ページ弱なので、1日1項目を読む…という細切れな時間を有効に使える内容です。
小難しい心理学の話や長々した文章もなく、読みやすくまとまっています。

この辺は「人材教育コンサルタント」という肩書きの著者の特徴(他にもちょくちょく著者の本を読んでいますが)だと思います。

内容的には「これは目からウロコ！！」的な新たな驚き、気づきはそれほどないと思います(読者の経験にもよりますが)。
ただ、仕事がバタバタしてしんどい的には、忘れがち、置き去りにされがちな基本的な部分を思い出させてくれる感じです。

例えば↓…。

・「顧客の視点から回答する」
→「こんな最新の技術を使っています！」ではなく「これでどんな風に変わるのか？」を伝えましょう。

・「具体的な根拠を示す」
→「すごく早くなる」ではなく、「1時間の作業が5分になります」と具体的な数字を出しましょう。

・「ネガティブな先入観を与えない」
→第2部(先輩として手本を示す―“先輩らしく”行動し優秀な後輩を育てる)にあるのですが、新人が入ってきて初めて後輩ができたりして、話す時についつい(悪い方の)噂話や仕事の愚痴などを言ってしまいがちです。

第2部は若手のOJT担当がやってしまいがちなNGが分かりやすく書かれています。後輩や部下がそろそろできはじめる若手の方は一度読んでみると良いと思います。

※注意：この記事は旧サウスポーなエンジニアの独り言から移行し一部修正したエントリです。

Photo via Visualhunt

最高のプレゼンテーション―心をつかむ見せ方、話し方

プレゼン ＝ 「パワポ(PowerPoint)を作らな！！」＋「本番でのしゃべり！」となるのがだいたいの感じだと思いますが、この本はプレゼン ＝ (構成の善し悪しももちろん)始まる前の準備、心構え、そして始まってからの参加者との関係が大事ですよ。
ってことを著者の数多くの経験をかなり具体的に書いています。

◆目次
1 勝負は壇に上がる前に、すでにはじまっている
2 最初の3分間で参加者の心をつかめ
3 テーマをわかりやすく伝えるスキル―「りんごの木のアプローチ」
4 プレゼンを面白くする13の方法
5 参加者に活動してもらうやり方
6 「見せる」技術を磨く―ハイテクかローテクか
7 配布資料の作り方と活用方法
8 身だしなみのチェック
9 プレゼンに成功する7つの条件
10 役員等を対象にしたプレゼンの場合
11 プロが伝授するプレゼンの秘訣
12 プレゼンの成果を測る5つの評価法

海外の翻訳なので、アドバイスの中には「日本人向けでは無いやろ？」的なのもありますが、目的を理解した上でアレンジすれば使えるレベルです。
書いていることは特別難しくありません。
ただ実際に「十分準備とその心構えをしているか？」と問われると…。

資料をバサッと配り、プロジェクターにも映して、それを読み上げるだけのプレゼンもあります。
それなら資料を配ればいいだけで、(この本にも書いているように)私ならサラッと目を通して「あ、この資料を読むだけやな」と分かると別の考えごとをしたり、許されるなら席を立ってしまうかもしれません(失礼なことですが)。

私が特に気に入った内容は以下です。

1：最初の3分間でWIIFM(What’s in it for me) ＝ 自分(参加者)にとって役立つことは何かを提示する。

「この人の話を聞けば自分は何が得なのだろう？」と聴衆に興味を持たせる(そして持続させる)ことが大事です。
そうしてもらわないといくら内容が良くてもそこまで辿り着いてもらえないわけですから。

2：繰り返しで強調する。

大事なことは繰り返し言うというものです。

私がプレゼンをする際に気をつけている大事なことの1つは「(今から伝えることに)自分が自信を持っているか？」ということです。
提案、調査報告、新製品の紹介でも、自信を持って「こうです！」と思えなかったり、「どこかウソっぽいよな」とか思っているなら、その気持ちは聞き手に伝わってしまうものだと思います。

※注意：この記事は旧サウスポーなエンジニアの独り言から移行し一部修正したエントリです。

Photo credit: The U.S. Army via Visualhunt.com / CC BY

仕事が10倍速くなる最強の図解術

報告書やプレゼン資料を作成する際に、図解化することで抜けや漏れが無いか(MECE)、また説得力のある論理構成になっているか？を確認し、質の良いものを造り出しましょうという内容の本です。
※見栄えが良くなるレイアウトやキレイな図の書き方の類の本ではありません。

著者の開米 瑞浩 さんの記事は雑誌等で何度か読んでいたので、手にとってみました。
目次はこんな感じです。

■第1章 「図解」でスキルアップ(「デキる人」は図で考える
図解が必要な理由を整理する ほか)
■第2章 図解の基本はマトリックス(最初の一歩はマトリックスから
テーブル型対座標平面型 ほか)
■第3章 ビジネス・フレームワークを図解せよ(目標のある行動を考える　事故の予防や処理を考える ほか)
■第4章 文章を読み解く図解の作法(文章のままでは百回読んでもわからない　ステートメントに分解せよ ほか)

文章はマトリックスで解読する

文章で書いていると、論理的なおかしさ(本書では「間違いでは無いが、意識的/無意識の隠蔽」とあります)に気付かないことがあります。
それをマトリックスなどの図解に当てはめていくことでMCSE的な問題点等が見えてくるということです。

具体的例は本書を読んでもらうと良いでしょう。
全部本書のようにうまく当てはまるとは行きません(うまくいくのであれば人生苦労はしませんが・笑)が、それでもかなり整理出来るのでは？と思う内容です。

これを意識して他の人の文章や読んでいると無意識のうちに頭に図解され、その一部が欠けていたり、これって同じ事を言っているのでは？とMECEで無い部分を見つけやすくなりました。

主張は1つ、理由は3つ

プレゼン系でよく言われていることですが、主張1つに対し、理由を3つ述べるとことです。

会議やディベートで「言いたいことは**です。その理由は以下の3つです」と持っていきますが、その理由3つが弱かったり、「お前、それ3つとも同じこと言うてるやん」ではあかんということです。
本書ではその3つをもれなく、だぶりなく…これも有名なフレームワークMECEです…構築し、また抽象化のレベルを合わせることで良いロジックツリーを構成しましょうというものです。

文章を読解・図解するための4S手順

4Sとは、Statement・Sticky note・Sequence・Summaryです。

まず短い文章に分解し、それを付箋紙に書き出します。
で、その順番をああでもない、こうでもないと考えます。
最後にそれを眺めて要約します。
これで文章を解読しようというものです。

人間が同時に記憶、把握、考えれる数は7つ(±2)とよく言われます。
それ以上は紙に書き出したりして整理する必要があります。
で、その時にただ単に文字の羅列(買い物メモとかならそれでも良いですが)では、手順なんかに漏れがあったりします。その時にこういう図解を知っておくとすごく良いと思いました。

繰り返しですが、本書では図解のテクニックでは無く(もちろんそれも書いていますが)、その図解することで、論理的に考える力を強くしましょうというのことを書いています。

1回読だけではなく、読んで→実践→読んで(また新たな発見)→実践が出来る良書です。

※注意：この記事は旧サウスポーなエンジニアの独り言から移行し一部修正したエントリです。

Photo via Visual hunt

仕事でJavaを使ってのシステム構築をしています。

勉強したり、資格を取るためJavaをさわることはあっても仕事は初めてです。
で、思い立って以前に買って積読していた↓をちゃんと読んでみました。

■(Javaの格言―より良いオブジェクト設計のためのパターンと定石)
著者：ナイジェル ウォーレン (著), フィリップ ビショップ (著), Nigel Warren (原著), Philip Bishop (原著), 安藤 慶一 (翻訳)

【目次】
第1章 カプセル化
第2章 継承
第3章 ポリモルフィズム
第4章 型の安全性と定数
第5章 例外
第6章 コールバック
第7章 クラスのロードとオブジェクト生成
第8章 生成に関するイディオム
第9章 パフォーマンスとリソースとのバランス
第10章 コレクション
第11章 イテレータ
付録A 図ならびにコーディング規約について
付録B 規則・設計原則・ヒント一覧
付録C 重要用語集
付録D 参考文献

Javaの文法、カプセル化やポリモルフィズム等オブジェクト指向の基礎知識が前提で、UMLダイアグラムやデザインパターンも知っていればより面白いです。

各章のサンプルプログラムに対し、オブジェクト指向の深い考察が記述されています。
また保守、機能追加が加える際にどのように(オブジェクト指向的に)考えていくと良いかということも色々と考察されています。

特に第1章～第5章は上級プログラマーレベルであれば知っておいて損はないと思いますが、1回読むだけでなく…実際に仕事で使い…そして再び読むと「あぁ、なるほどねぇ」と思うこともあるような本です。

「10日で覚える～」「初めての～」シリーズとは趣が全く違います。また「Tips集500」は「こんなことしたいんだけどなぁ」の時に役立ちますし、実際の現場ではこっちが必要ですが、本質的な点や設計レベルで考えるのであれば、こんな感じの本に書いている内容を知っているとかなり良いと思います。

ちなみにピアソン・エデュケーションの本は良くも悪くもガッツリ深く書いている本が多いので、理解するのにパワーがいります。

※注意：この記事は旧サウスポーなエンジニアの独り言から移行し一部修正したエントリです。

Photo via Visual Hunt