システム開発に銀の弾丸はないが「金の弾丸」ならある『人が増えても速くならない』
例えばソフトウェア開発において、 人が増えても納期が短くなるとは限らない 見積もりを求めるほどに絶望感が増す 納期をゴリ押すと、後から品質はリカバリできない これを見て、「だよねー」「あるあるｗ」という人は、本書を読む必要はない。 プログラミングは人海戦術で何とかならないし、「厳密に見積もれ」というプレッシャーは見積額を底上げするし、納期が優先されて切り捨てられた品質は、技術的負債として残り続ける。経験豊富なエンジニアなら、大なり小なり、酷い目に遭ってきただろうから。 だが、これらを理解できない人がいる。 要員を追加して、手分けしてやれば一気に片付くはず 厳密にやれば、見積りバッファーはゼロにできる 品質のことはリリース後にじっくりやればいい ……などと本気で考えている。これは、ソフトウェア開発とはどういうものか、特性を知らないからだ。こんな無知な人間が経営層にいたり、顧客の代表となった場
イノベーションの神話10
見えてる穴に落ちていたことに気づかされる一冊。 革新的なアイディアは、どこからか「ふってくる」と考えている人は、けっこういる。わたしもその一人で、アイディア出しの手法・ツールを準備すれば、あとはインスピレーションの女神が降りてくるのを待つだけと考えていた…そして、今も待ちつづけている。 あるいは、天才肌のカリスマが全く新しいアイディアで世界を変えてしまうことを、「イノベーション」だと考えている人は、かなりいる。わたしもそう思ってた、iPod の「新しさは」ジョブズだから生まれたんだと、ね。 本書を読んで、わたしの思い込みは粉砕された。もちろん、エジソンが電球を発明したわけじゃないことや、Google の最初のアイディアはYahooで却下されてたことは知っていた。が、知っていたにもかかわらず、わかっていなかった。著者はそれを、イノベーションの神話と呼ぶ。そして、 イノベーションにまつわる神話
人と人をつなぐ技法「チームビルディング」
「チームはできるものではなく、つくるもの」。この視点はありがたい。チームをまとめる立場なら、この視点+技法は必須。プロジェクトチームから町内会まで使える。 好むと好まざるとにかかわらず、社畜でいるかぎり、三十路も後半になると、一匹オオカミでいさせてくれない。「面倒みてやれ」という暗黙のメッセージとともに、何人か付けられる。たいていは、数回の毎朝ミーティングでチームらしくなってくる。 これが10人、20人のプロジェクトチームになると話が違ってくる。さらに、「思惑」「肩書」パラメータが追加されると厄介だ。以前のわたしは、アイスブレイクをいくつかと、赤ちょうちんぐらいしか知らなかった。仕事を通じてチームは形成されるものだと思っていた。 ところが、本書では、チームをつくる方法があるという。短期間で活性化したチームとして機能させるためのメソッドが紹介されている。[アジャイルレトロスペクティブズ]がチ
わたしの7つの「ふりかえり」
[チームリーダーは「アジャイルレトロスペクティブズ」から盗め]の続き。わたしの「ふりかえり」をふりかえってみる。 ■01 定期的に、ふりかえる 実は、定期的なふりかえりは、したことがない。たいていは、プロジェクト終了直後や、さらにずっと後になって、「あんな時代もあったね」と語ることはあっても。ただし、「笑って話せる日」は絶対こない。笑わず小声で真剣に「あの二の舞だよ」、あるいは「まだ学習してへんのかッ」と刺す。 そういうチーム運営を定期的にふりかえる必要性に気づいただけでも、本書に感謝しないと。 まずいチーム運営は、トラブルという見えやすい形でフィードバックをもらっていた。メンバーの不満や、作業プロセスのボトルネック、品質チェックの不備は、プログラマの喧嘩や明白なサボタージュ、収拾のつかないバグズライフに化す。 そして、「トラブルの対処」という形で皆の不満を吸い上げたり、手順書を見直したり
わたしが知らないスゴ本は、きっとあなたが読んでいる: 画面仕様書を「作らない」リスク
IT Pro の開発ドキュメントの最適化で笑わせていただいた。これ書いた人は画面仕様で酷い目に遭ったことがないんだろう。笑った箇所は次の通り。 画面仕様書をプロトタイプ・アプリケーションで代用する方法がある。Webシステムの場合は，HTMLの作り方を工夫すればプロトタイプで実際の入力手順や画面遷移も確認できるようになる。エンドユーザーにとっても，ドキュメントよりは実際の画面で確認した方が分かりやすいので，手戻りが減る。これは帳票にも同じことが言える。 あのな、HTMLで作る画面なんざ、紙芝居だよ。「ふいんき」をかもし出すだけで、そいつは「仕様」じゃねぇ！ボタン配置や文字色を目の前で変えられるものだから、いつまでたっても顧客は「ちょっとコレ直して」と言ってくるんだよ。気軽に直せるものとお金を頂戴しないと直せないものがあることをギッチリと顧客に理解していただくために、画面仕様書はどうしても必要
わたしが知らないスゴ本は、きっとあなたが読んでいる: 全上司必読「もし部下がうつになったら」
全上司必読の一冊。そう「なる」前に読んでおくのと読んでいないのとでは、えらく違ってくる。予防の1オンスは治療の1ポンドに勝る。 7人に1人は「うつ」になるという時代だそうな。うん、プロジェクトの火消しに没頭するあまり、自分に燃え移っていることに気付かず、火だるまになったことがある。罵倒と怒号が飛び交う火事場で残業100超を3ヶ月続けると、確かにおかしくなったよ。 うつになる人が増えているということは、うつになる同僚が増えているともいえる。さらに、うつになる部下が増えていることでもある。 しかし、うつになった社員にどう対応するべきかは、企業レベルでは浸透しておらず、部下から診断書を見せられて困惑する「上司」が大多数だろう。しかも、そうした「上司」は、出世競争のいわばサバイバーなので、うつになった部下の気持ちが理解しにくい。 本書はそうした「上司」たちに向けて書かれている。業務量は変わらないま
わたしが知らないスゴ本は、きっとあなたが読んでいる: 困った現場に効く「プロジェクトマネジメント現場マニュアル」
プロマネ本は沢山あるが、こいつは具体的。プロジェクトのその場その場で発生する問題とその解決策がよく分かる。「こんなときどうする?」形式なので、自分なりの対策を考えて→次のページで"答え合わせ"をするといった読み方もできる。カユいところに手が届く仕掛け。 例えば… 問題がいつまでたってもなくならない。進捗報告はペンディングの山。どうやって片付ける? テストが甘い。行き当たりばったりで、テスト自体のモレヌケによりつぶすべきバグが後になって湧く。なんとかするには、何をどうすればいい? アバウトな品質要求「使いやすい画面にしろ」といわれたとき、何をどうすれば「使いやすい画面」になっているといえるのか? 進捗管理が甘い。「90パーセントです」が1ヶ月続く。あるいは、進捗会議の場が、「なぜ遅れているのか」の言い訳の場になっている。どうする? 答え 問題を管理する。責任者、期限、優先度を決め、進捗を監視
冒険小説とはこれだ「ナヴァロンの要塞」
最近、内藤陳さんの[読まずに死ねるか!]を渉猟している。文字通り、生まれてきた以上、読まずに死んだらもったいない小説を、★★★★★の順に読み漁っている。 このblogでは、面倒なので★による評価をしていない。しかし、もし5段階で判定するなら間違いなく★★★★★（パーフェクト）になる傑作を読んだ。今週は冒険小説のアタリどきだね。以下紹介文より。 エーゲ海にそびえ立つ難攻不落のナチスの要塞、ナヴァロン！ その巨砲のために連合軍が払った犠牲は測り知れない。進退きわまった司令部は、遂にマロリー大尉ら精鋭五人に特命を下した――ナヴァロンの要塞を爆破せよ！ 頭脳と体力の限りを尽して不可能に挑む男達の姿を重厚な筆致で描いた、冒険小説の金字塔 宣伝文句に偽りなし。「金字塔」そのままあてはまる。むしろ、「この本を100とするならば、○○は──」とか、「あの『ナヴァロンの要塞』を超えた!?」といった、天井とし
わたしが知らないスゴ本は、きっとあなたが読んでいる: 見えない仕事がイノベーションを起こす「シャドーワーク」
「シャドーワーク」について、豊富な実践例＋網羅的な考察をした一冊。ヒット商品やイノベーションの陰には「シャドーワーク」が必ず存在する。ルーティーンワークからの変革なんてありえないし、創造的な価値は管理者の目の届かないところから生まれる。これはわたしのような兵隊ではなく、人事部の将校クラスが肝に命じておくべき。 「シャドーワーク」とは、通常業務から外れた、個人の自主的な意志と裁量で創造的に編み出した仕事のこと。仕事そのものへ結びつかないまでにしても、その準備活動も含まれる。いわゆる「やってみなはれ」「渦は自分で起こせ」というやつ。 たとえば、日産の例。新型マーチのコンセプトづくりにあたり、設計開発ラインの「外」で「こっそり」人を集め、意見を出し合う。あるいは、リコーの場合。GR DIGITALの専用Blogを提供するにあたり、「業務外で」「手弁当で」組織横断的に立ち上げる。仕事として「決まっ
わたしが知らないスゴ本は、きっとあなたが読んでいる: 実践しなきゃ、意味がない「アイディアのつくり方」
自分への戒めとして書く。優れた方法は、マネして→習慣化→血肉化してこそ意味がある。付せん貼ってブックマークして終わりなら、読まなかったことと同義。「いま」「すぐ」動かなければ、タタミの水練以下。JUST DO IT 「一時間で読めて一生役立つアイディアの作り方」という惹句どおり、確かにシンプルで強力な方法だ。しかし、こいつを愚直に実践していくことはかなりの努力を要する。そのエッセンスはこうだ―― アイディアとは、既存の要素の新しい組み合わせ以外の何ものでもない アイディアの作成は、車の製造工程と同じように、一定の流れ作業の過程であり、習得したり制御したりできる操作技術によってはたらく←「技術」なんだから鍛錬によって身につくことがポイント 既存の要素を新しい一つの組み合わせに導く才能は、事物の関連性を見つけ出す才能に依存するところが大きい アイディアの作成は、次の五つの段階を経る。どれも飛ば
わたしが知らないスゴ本は、きっとあなたが読んでいる: 東大教師が新入生にすすめる100冊
昨年の「東大教官がすすめる100冊」の2007年版。企画の趣旨は以下のとおり。 ■企画「東大教師が新入生にすすめる100冊」の趣旨 東大教師が選んだ新入生向けのブックリストとして、新書「東大教官が新入生すすめる本」と、紀伊國屋書店のサイト[参照]がある。全部で2100冊程と膨大なので、まとめる。まとめるだけでは面白くないので、100冊に絞ってランキングする。 新書もサイトも、「ただ並べてあるだけ」なので非常に見づらい。さらに、くりかえしオススメされる本の「重み」が見えないため、以下の基準で編集→ランキングする。 年を越えてオススメされる本は、それぞれ1票としてカウント 複数の教官にオススメされる本は、それぞれ1票としてカウント 全集・分冊は丸めて1冊にした。ただし、全集の中の特定巻を指してある場合は「ソコを読め」というメッセージなので別枠とした 参照元では「文系」「理系」と分けているが、混
わたしが知らないスゴ本は、きっとあなたが読んでいる: プロジェクトを成功させる魔法の言葉
あいにく銀の弾丸の持ち合わせはないが、うまくいくプロジェクトでよく使われていた言葉は確かにある。耳にしたときは聞き流していてた言葉を、この本は思い出させてくれた。ここでは、そんな「魔法の言葉」を紹介する。 ネタ元は「目標を突破する実践プロジェクトマネジメント」。ふつう、図書館で読んだ本はそれっきりだが、こいつは買って周りにばら撒く。薄くて分かりやすくて、すぐにやってみようという気にさせるところがいい。 ■ もし、問題があるとすれば、それは何ですか? 朝会や進捗会議で「何か問題はありませんか?」という質問はよくするしされる。けれども答えはいつも決まっている→「特にありません」。でもって、不具合が起きると、「あのとき聞いたのにッ」←→「こうなるとは思ってなかった」となる。 身に覚えない? これを、冒頭の質問にしてみると、アラ不思議、いくらでも出てくる。「問題ない?」には無反応だったのが、「これ
プロマネ必読！「アポロ13」
「アート・オブ・プロジェクトマネジメント」で強くオススメされてたので読む ―― これはスゴい。ドキュメンタリーとして夢中になって読めるだけでなく、プロジェクトが危機に陥ったときの「べき/ベからず集」しても、ものすごく有効な一冊なり。 どうしようもない状況、限られた時間、非常に高いリスク、疑わしい解決策…プロジェクトがパニックに瀕したとき、優れたプロジェクトマネージャは何を考え、どう行動するかを知ることができる。本書を通じて学んだ危機管理マネジメントは、次のとおり。 プロジェクトが危機的状況のとき、あらゆる手段を使って、自分の感情をコントロールせよ。感情は事実をゆがめ、判断を誤らせ、解決への手段の一つ一つに邪魔をする 「危機」は、すぐに数字にならない。必ずタイムラグが発生している。だから、危険な数値が今出ているということは、既に危機的状況に突入している、ということだ 問題に対処するとき、絶対
わたしが知らないスゴ本は、きっとあなたが読んでいる: この本がスゴい2006
今年は沢山の収穫があった。 自力で見つけた作品よりも、他力―― このblogが縁で知った本のほうが、はるかにスゴいものだった。コメントやトラックバックを通じてオススメしていただいた方、はてなの質問に回答していただいた方、わたしのエントリにケチつけたついでに「○○も読んでないくせに」と嘯いた方―― 皆さまに感謝、感謝。 そんな中でも選りすぐりを10選んだぞ。どれも自信を持ってオススメするが、「劇薬小説」だけは覚悟完了の上でどうぞ。これからも、「自分にとって高品質の情報を得るためには、自分から発信すること」を実現する場として、ここを使っていきたいですな。 ――――――――――――――――――――――――――――――――――― 徹夜小説：あなたの健康を損なうおそれがありますので読みすぎに注意しましょう ――――――――――――――――――――――――――――――――――― 大聖堂（ケン・フォレッ
わたしが知らないスゴ本は、きっとあなたが読んでいる: 名著！「デッドライン」
長くなりすぎたこのエントリのレジュメ …というか、見出しの一覧。これ見てご興味ある方はお読み下さいませ。 マネジメントの4つの本質 マネジメントおける簡潔で痛切なエッセンス（一部） 設計とデバッグに関する恐ろしい事実 残業と生産性とプレッシャーに関する恐ろしい事実 生産性の測定について 管理者の怒りについて 会議を効率よく行うための、たったひとつの冴えたやりかた 大事なことが、ずばり書いてある。背中を押したのは「ソフトウェア開発の名著を読む」なんだけど、確かに名著だ。初読は物語を楽しみ、再読、再々読で血肉にすべきだな。 延ばし延ばしにしてた一冊を読み始めて「どうして今まで読まなかったんだあぁぁっ」と叫びだすような逸品がある。本書がまさにそう。デマルコは「ピープルウェア」がピカイチと決め付けてた自分が恥ずかしい。 「ピープル」がプログラマ・チームリーダーの視点で書いているが、「デッドライン」
わたしが知らないスゴ本は、きっとあなたが読んでいる: 「仕様」という言葉の罠を回避する
結論→ 「仕様」と「機能」を意識的に使い分けることで、顧客のテクニック「言葉のすり替え」を見抜くことができる。 客先での仕様調整の場で、新人が手もなくひねられている（騙されているともいう）。もう少し手加減してやればいいのに、顧客の脅しが酷すぎる。 あたりまえじゃないか、その機能が入っているのが仕様です なぜなら、いま私が現場に電話で確認したら、そういう運用になっているからです だから、その機能が入っていないのはバグなんです したがって、あなたは無償で今すぐこれを実装する必要があります テストフェーズ末期やリリース後、何らかの要求を満足していない場合、顧客より一方的に伝えられる最終通牒は、こんな論法だ。非常に強い口調で伝えられると、なんとなく「そうかも?」という気分になり、顧客が正しいという空気が場を支配する。 その結果、ほとんどの場合、泣く泣く自腹で実装していることだろう。ひとつひとつは小
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
