書籍」カテゴリーアーカイブ

「アジャイルコーチの道具箱 – 見える化実例集」を読んだ

アジャイルコーチの道具箱 – 見える化実例集」を読みました。

ギルドワークスで現場コーチとして、様々な現場がアジャイルな開発をうまくやれるような支援、現場の改善や見える化をしている自分としてはとても興味をそそられるタイトルです。
また翻訳した方々も@haradakiro@ryuzeeなど期待せざるをえない人達ばかりで、すぐに読み始めました。

読んでいる途中「あの現場のあのチームはこれが良さそうかな」「あのチームが持っている課題はまずこれをやってみて、それからこっちをやってみてはどうだろう?」とアイデアが色々出てきてワクワクしてきました。

やるかどうかは現場のチームが決めればいいですが、「こういうアイデアがあるよ」「こういう感じで一度試してみてはどうかな?」とコーチとして色々なカードを見せたり、背中を押すことができそうです。

コーチだけでなく、チームが見える化を推進していくのも役立ちます。
「見える化する対象は分かったけど、どう見える化すればいいかわからない」という悩みはここにある様々な実例でほとんど解決できそうです。悩みにピッタリのそれがなくてもパラパラと見るだけで解決できそうなヒントは浮かんできます。
#もちろんどうやって運用するか?当たり前にするか?という次のステップはありますが、「やってみる」ことはできそうです。

以下は読みながら垂れ流したツイートです。

SCRUM BOOT CAMP THE BOOKを読みました

SCRUM BOOT CAMP THE BOOKはいい本です!マネージャーも開発者もみんな読んでみてください!」で終わらせようと思ったら・・・


・・・と言われたので、もう少し書いてみます。

さらに「なかなか書けないなぁ」とウダウダしているうちに長沢(@tomohn)さんにも先を越されてしまったりしました。

いや、でも本当にいい本なんですよ。
私の説明や感想なんかより「とりあえず(2時間もあれば読めるから)読んでみてよ!」です。

読書感想文ですが

Scrumを構成する事柄(原則やロール、イベント等々)について、「どういう背景で、なぜそれが必要なのか?そしてそれがなかったらどうなるのか?」とかなり深く書かれているように感じました。
正解がない中でボクくん達のチームが何を考え、決断して、振る舞えば、より良いゴールに辿り着けるのか(これもあくまで”可能性が高くなる”の話ですが)がテンポの良いマンガとして描かれています。

実際にScrumをやっていると、陥りやすかったり、悩みやすかったり、はまったりしやすい色々なポイントに対して「自分(著者達)ならこう考えて、こうするよ」と考えや豊富な経験を見事に文章に書かれている点も素晴らしいと思いました。
#章やコラムによっては3人それぞれの声が脳内再生されたりして、ニヤニヤしました。

マンガのように最初のScrumでこれほどうまく行くこと(それでも、ボクくん達チームはリリース間際は深夜残業な様子でしたが)は簡単ではないでしょうし、もしかするとプロダクトオーナー、チームメンバーが最初から前向きなのも、なかなか珍しいかもしれません。

繰り返しになりますが、そんなところも含めてScrumの嬉しいところも、難しい(そんな簡単に上手く行かないよ)ところが余すところなく書かれています。

Scrumを実践者はもちろん、「アジャイル、スクラムって聞いたことがあるんだけどなぁ」という方もぜひ読んで「こういう方法もあるんだ」と手持ちのカードを増やしてもらえたらと思いました。
#自分が読みながらつぶやいたまとめ

最後になりましたが、こんな素晴らしい本を届けてくださった著者のみなさん、ありがとうございました!

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

ビジネスモデルを見える化する ピクト図解

ビジネスモデルを見える化する ピクト図解

少し古い本ですが、冒頭の例とその説明が分かりやすくて、一気に読みました。

冒頭の例

1:デジタルカメラ・電動ハブラシ・ヘアドライヤー・インクジェットプリンタ・ヘルスメーター・パソコン・・・カテゴリーが異なる商品の中で「儲ける仕組み」が同じなのはどれか?
2:Hanako・Goo・赤すぐ・週間少年マガジン・・・どれも雑誌だが、「儲ける仕組み」が微妙に違う。どのように違うか?

「ピクト図解」とは?

・「ビジネスモデルを見える化する」ツール
・1枚の図に「3W1H」をまとめる
 ※3W1H:「誰が(Who)」「誰に(Whom)」「何を(What)」「いくらで(How much)」
・オブジェクトは3つのエレメント、2つのコネクタ、2つのオプションとシンプル
・3つのメリット

1:”経営者の視点”を手に入れられる
2:説明不要で誰とでも共有できる
3:画像パターンを応用してアイデア発想ができる

#本書後半では、ピクト図解を応用した発想法として「ダイアグラム発想法」「アナロジー発想法」も紹介して、これも興味深いです。
 

読書メモ

・似たように見えてもそれぞれビジネスモデルが違う。
 また(一見売っている物や業界自体が)違って見えても(ピクト図の上では)同じようなビジネスモデルもある。そのビジネスモデルを見抜くことが大事。

・代表的な8つのビジネスモデル。
・いくつかの企業のビジネスモデルの話が出ているが、どの例も分かりやすいし、「なるほど、そうか」と思うのが多かった。(ユニクロのフリースの話、土間土間のメニューの話、アスクルの事業発展の話)

自分やお客様のビジネスをピクト図に描いていくのは割と費用対効果が良いと感じた。
 実際に自分の組織や考えているのを描いて、眺めて、色々いじっているといくつかアイデアが出てきたし。
 本格的な業務コンサルタントでなくても、このレベルのお客様のビジネスモデルを知っていることは損にならないし、知っておかないと”御用聞き”から抜け出せないかと。

・「めざすゴールによって、選ぶべきビジネスモデルは変わる」というのは当たり前なんだけど、「ビジネスモデルを考える」ことだけが目的になりがちなので、いつも意識しよう。

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

Photo via Visualhunt.com

How to Change the World 〜チェンジ・マネジメント3.0〜

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

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

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

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

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

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

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

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

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

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

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

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

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

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

コンサルタントの道具箱[読書感想]

コンサルタントの道具箱

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

目次

イチゴジャムの法則
知恵の箱
金の鍵
勇気の棒
願いの杖
探偵帽と虫めがね
イエス・ノーのメダル
ハート

望遠鏡
魚眼レンズ
ジャイロスコープ
卵、カラビナ、羽根
砂時計
酸素マスク

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

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

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

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

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

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

***********************

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

小さなチーム、大きな仕事―37シグナルズ成功の法則

<

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

アジャイル開発の本質とスケールアップ 変化に強い大規模開発を成功させる14のベストプラクティス[読書感想]

アジャイル開発の本質とスケールアップ 変化に強い大規模開発を成功させる14のベストプラクティス (IT Architects’ Archive)

2011年最初に読んだ本です。
300ページほどの大型本で、この手のは一気に読まない/読めないのですが、これはとても興味深い内容で(また翻訳に違和感もなく)グイグイと読むことができ、一気に最後まで読んでいました。

◆目次
第1部 ソフトウェアアジリティの概要
第1章 アジャイルメソッドの概要
第2章 なぜウォーターフォールモデルは正常に機能しないのか?
第3章 XPの本質
第4章 スクラムの本質
第5章 RUPの本質
第6章 リーンソフトウェア、DSDM、FDD
第7章 アジャイルの本質
第8章 アジャイルスケールアップへの挑戦

第2部 スケールアップ可能な7つのプラクティス
第9章 定義/ビルド/テストコンポーネントチーム
第10章 2レベル計画作りと追跡
第11章 反復型開発の習得
第12章 頻繁な小規模リリース
第13章 コンカレントテスティング
第14章 継続的インテグレーション
第15章 継続的な考察と適応

第3部 アジャイルな企業を作る
第16章 意図的なアーキテクチャ
第17章 リーン要求開発のスケールアップ:ビジョン、ロードマップ、およびジャストインタイムの詳細化
第18章 システムオブシステムとアジャイルリリーストレイン
第19章 高度に分散した開発の管理
第20章 顧客とオペレーションへのインパクトの調整
第21章 組織を変化させる
第22章 ビジネスパフォーマンスを計測する

結論:アジリティはスケールアップ可能である
索引

「小規模開発環境で適用されている(日本では「されつつある」)アジャイル開発を(それなりの規模の)企業に適用するには、どのような課題があり、それらをどう解決していけば良いか?」という内容が3部構成で書かれています。

第1部はアジャイルの歴史やXP、スクラムなどの主要なアジャイルメソッド、RUPなどそれぞれの特徴、開発メソッドの解説を簡単に説明しています。
第2部ではアジャイルのプラクティスの中からスケールアップできる…大規模に拡張可能な…7つのプラクティスについて言及しています。
第3部ではスケールアップした際に企業が直面する課題に対するプラクティスとして新たに7つ言及しています。

特に印象に残ったのは、第3部で「アジャイル開発(やそのマインド)を現場・チーム以外にも企業全体に広めていくには?」を考察している点でした。

アジャイル開発がメインになった時に、マーケティングやセールスにとってどういう影響があり、それに対してどうすれば良いか?
またエグゼクティブは組織全体にアジャイル開発を根付かせる為にはどうすれば良いか?
企業体にはどのような阻害要因が発生しうるか…等々、アジャイル開発を開発現場の視点で書かれた内容とは違っており興味深かったです。

自分が所属しているSIerの組織全体ではアジャイル開発には程遠い…ということを認識しているか余計に思ったのかもしれません。
ちょうど今年のアクションにも関係する内容で(その為に大晦日に買った)、良書だと思いました。

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

ワンランク上の問題解決の技術《実践編》 視点を変える「ファンクショナル・アプローチ」のすすめ[読書感想]

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

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

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

◆目次
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回の会議・打ち合わせで必ず結論を出す技術
著者:斎藤 岳

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

◆目次
第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のためのコミュニケーション実践塾[読書感想]

速効!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倍速くなる最強の図解術[読書感想]

仕事が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をさわることはあっても仕事は初めてです。
で、思い立って以前に買って積読していた↓をちゃんと読んでみました。

■(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