月別アーカイブ: 2011年1月

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

コンサルタントの道具箱

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

目次

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

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

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

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

「不変の言葉」
「願いの杖にできること」
「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の組織全体ではアジャイル開発には程遠い…ということを認識しているか余計に思ったのかもしれません。
ちょうど今年のアクションにも関係する内容で(その為に大晦日に買った)、良書だと思いました。

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