プロジェクト管理は決して精密な科学ではないが、これにソフトウェア開発が持つ予測が難しいという性質と組み合わせられると、大きな悲劇のレシピが生まれる。わたしは、ソフトウェア開発プロジェクトに取り組んでいるプロジェクトマネージャーがよく犯す過ちを数多く見てきた。それらの過ちの一部はソフトウェア開発に限ったことではないが、この文脈では特に頻繁に起こり、ダメージも大きい。 1．「人数を増やせばよい」という誤解 Fred Brooks氏は同氏の有名な言葉の中で、よくあるプロジェクト管理の間違いについて「ある女性が9カ月に1人子どもを産めるからといって、9人の女性がいれば1カ月に1人の子どもを産めるわけではない」と表現している。そして、この間違いは今でも頻繁に見られる。ある問題に多くの人間を割り当てれば、その問題は早く解決するという考え方だ。残念ながら、これは正しくない。 プロジェクトに人を1人投入す

技術はできて当たり前の管理職：柴田 芳樹 (Yoshiki Shibata)：So-netブログ ところが、現実は逆で、若手の方が色々なことを勉強していて、新たな手法を導入しようとすると、勉強していない管理職に対して「分かりやすく説明する」ことが求められたりします。 もしくは逆に、どこぞで聞きかじってきたツールや手法を無分別に導入しようとする上司に対して、それが業務に合わないことを部下が苦労して説明しなければならないこともある。（基本的な専門用語すら通じないので説明が大変） さらにひどい場合は、反論を予測した上司が、経験のある社員をスルーして、口答えのできない初心者（新入社員など）に自分の肝いりのツールの使用を強いることもある。失敗覚悟のプロジェクトに試験的に導入するのならまだしも、本格的な業務に（誰でも簡単に開発ができるという触れ込みの）新ツールとソフト開発の素人をセットにして放り込んだ

プロジェクトで危機的な状況に直面したとき、やってはいけないことが少なからずある。日経SYSTEMS5月号（4月26日発行）の特集記事「プロジェクトの危機 その時どうする」の取材では、このように感じる指摘を、ベテランのプロジェクトマネジャー（PM）から受けることができた。 特集記事で取り上げた危機的な状況には、「震災の影響によってプロジェクトが進められない」といったものに加えて、コストオーバーや納期遅延、品質の低下というものを含む。このとき、どのように対応すればよいかを、「人が足りない」「時間がない」「タスクが山積み」といった状況ごとに紹介している。 記者はこの特集の事例取材で、コストオーバーや納期遅れ、品質の低下といった危機的状況での対応を、主に担当した。これらの危機的な状況は、PMやリーダーが「順調に進んでいる」と思っている中で、急に判明することが少なくない。このとき、プロジェクトはかな

Spring BootによるAPIバックエンド構築実践ガイド 第2版 何千人もの開発者が、InfoQのミニブック「Practical Guide to Building an API Back End with Spring Boot」から、Spring Bootを使ったREST API構築の基礎を学んだ。この本では、出版時に新しくリリースされたバージョンである Spring Boot 2 を使用している。しかし、Spring Boot3が最近リリースされ、重要な変...

アジャイル開発に取り組むチーム向けのコーチングや、技術顧問、認定スクラムマスター研修などの各種トレーニングを提供しています。ぜひお気軽にご相談ください（初回相談無料） みなさんこんにちは。@ryuzeeです。 Bob Hartman氏のAgile antipattern: Target fixationが良い記事なので、抜粋・意訳にてご紹介します。 日本でよく言われるのが、「期日までに使わない（と思われる）機能も全部作れ、契約だから」。 限られた時間軸の中で変化を受け入れながら進めている中でこういうのを要求されると、品質やチームのモチベーションやコラボレーションを犠牲にしはじめてしまいます。 このような状況が続けば焼畑農業のようにチームには何も残らなくなります。 結果として顧客にとっても幸せな結果にはなりません。 期日を約束したりストーリーポイントのゴールを約束したり、その他のゴールが命取

アジャイル開発に取り組むチーム向けのコーチングや、技術顧問、認定スクラムマスター研修などの各種トレーニングを提供しています。ぜひお気軽にご相談ください（初回相談無料） 1. ふりかえり（レトロスペクティブ）をしないか、間違ったふりかえりをするふりかえりをせずして、どうやって物事をよりうまくできるようにすることができるというのだろうか？ ふりかえりは、全てのチームメンバーがうまく行ったこと、もっとうまくできるだろうことについて議論できるという点で必要不可欠だ。 そしてもちろん言うまでもなく、失敗から学習しなければならない。もしそういったことが行われていない（形式的なふりかえり）なら、ふりかえりは役に立っていない。 2. ダメなプロダクトオーナープロダクトオーナーはいつでもプロジェクトのために時間を使えるようでなくてはならない。 プロダクトオーナーはスプリントプランニングやふりかえりに参加しな

Spring BootによるAPIバックエンド構築実践ガイド 第2版 何千人もの開発者が、InfoQのミニブック「Practical Guide to Building an API Back End with Spring Boot」から、Spring Bootを使ったREST API構築の基礎を学んだ。この本では、出版時に新しくリリースされたバージョンである Spring Boot 2 を使用している。しかし、Spring Boot3が最近リリースされ、重要な変...

原文(投稿日：2010/04/19)へのリンク どうやら私たちが知っているアジャイルは成長フェーズを終え、新しいフェーズに入り始めているらしい。このことを示す証拠が数多く現れてきている。 アジャイル思想リーダ Alistair Cockburn氏 これを示すデータの一つに、Alistair Cockburn氏がAgile2009の基調講演として行った「アジャイルを葬るためにここに来た。賞賛するためではない」がある。そこで氏は次のように論じている。 アジャイルソフトウェア開発は、1990年代に同じ場所で作業をする小さなプロジェクトにおいて定義されました。それが今や、世界中の分散した巨大な商業プロジェクトに広がり、IEEE、PMI、SEI、防衛省などに影響を与えています。アジャイル開発は以前よりも広い展望の中に位置づけられたので、それに応じた見方をする必要があります。 Forrester Re

Spring BootによるAPIバックエンド構築実践ガイド 第2版 何千人もの開発者が、InfoQのミニブック「Practical Guide to Building an API Back End with Spring Boot」から、Spring Bootを使ったREST API構築の基礎を学んだ。この本では、出版時に新しくリリースされたバージョンである Spring Boot 2 を使用している。しかし、Spring Boot3が最近リリースされ、重要な変...

本研究所では、アジャイル開発を素材に、より良いシステム開発のあり方を求めていきます。開発手法そのものを見直すことは、より良いシステムを作るだけではなく、開発を担当するチームが成長し、個人の満足度も高まると考えられるからです。今回は、アジャイルと要件定義の関係について考えてみます。 みなさんはもう十分に実感されているかもしれませんが、ここ最近の私は、アジャイル開発における要件定義の重要性を改めて認識するようになりました。アジャイル開発といえば、要件定義よりも「まずは作ってみる」といったイメージが強いかと思いますが、要件定義が重要な作業であることには変わりがないと考えています。 一般的に、アジャイルではユーザーが実施したいことを端的に表した「ユーザーストーリー」を作成し、開発を進めていきます。ですが、これまでの私が「それだけでは要件定義が不足している」と不安に感じていたのは事実です。 そんなと

人間の心に働きかけるというのは大変複雑なことです。 世界中で同じように物事を考える脳は二つとありません。 同じ指紋がけっしてないように、二人の人間が働くスタイルは90パーセントであっても合致しません。このように多くの個々の人間を作り出し、しかも全て違うという自然の摂理は美しいとさえ感じます。しかしビジネスであｈ目標は全利害関係者にとって “一つであり同じ”なのです。 ここでいう人々とは (a)プロジェクトチームメンバー(b)ビジネスユーザー (c)経営陣及び出資者など様々な立場でプロジェクトに係わる人を意味します。人々はどのプロジェクトでも管理されることが必要なのです。 というのは プロジェクトのゴールに向かって並ばせ、ワークスタイルを統一する ベストなものを引き出す 集中してやる気のある状態にするだからです。 もしプロジェクトの誰もが完璧であれば、どの業界のどんなプロジェクトも失敗するこ

Spring BootによるAPIバックエンド構築実践ガイド 第2版 何千人もの開発者が、InfoQのミニブック「Practical Guide to Building an API Back End with Spring Boot」から、Spring Bootを使ったREST API構築の基礎を学んだ。この本では、出版時に新しくリリースされたバージョンである Spring Boot 2 を使用している。しかし、Spring Boot3が最近リリースされ、重要な変...

昨日はIBMのラショナルソフトウェアカンファレンスに参加しました。1日中、ソフトウェア開発方法論に関するセッションを聞いていたのですが（最後のセッションは、自分が司会のパネルディスカッションでもありましたが）、その中で最も印象的だったウォーカー・ロイス氏のプレゼンテーションを紹介したいと思います。 ウォーカー・ロイス氏はIBMラショナルソフトウェア部門のバイスプレジデントで、アジャイル開発手法としてよく知られるRUP（Rational Unified Process）の創始者でもあります。彼の講演は、この日の基調講演の1つでした。

お金の発生するところに全てYesと言って帰ってくる。 優先順位はもちろんHigh。 なんでもハイ。 さて。 以下の状況下で打つべき手はなんであるか考えよ。 ・納期過ぎてる ・設計終わっていない ・設計レビューなし ・データなし ・テーブル中途半端 ・DB更新バンバンアリ ・開発体制：一人でコーディング〜単体テストまで ・コードレビューなし ・単体テストレビューなし ・結合環境なし ・テストなんとなく ・でも納品しようとしている 打つべき手 (1) 体制を根本から見直し、悪循環を断ち切る努力を行う (2) 今目先のことだけやって、未来にやってくる必然から目をそむける (3) 気づかなかったことにする 後手後手を踏んでなお「一人一人が完璧にこなして当然」とか思っていることをやめないのは 現実見えないからなんじゃないかとしみじみ思うのだがどうなんだろ。 管理しきれないことの責任を当人に押し付ける

[記事より] 単純にうれしくなった。なんでだろう。いやいや、Agileが普通になるってことはよいことだ！！それがアメリカであったとしても。 こちら http://d.hatena.ne.jp/masayang/20090825 より Covert Agile: Development at the Speed of…Government? もう一つの政府系受託開発事例。 顧客は空軍。 ・今回は「従来の半分の期間で完成させてみせる。ただし予算は従来の倍いただきます」という触れ込みで入札し、受託した。 ・驚いたことに、契約は「ウォーターフォール」。 ・お客の予算管理部門には、ウォーターフォール的な計画書を提出し、途中の説明も全てその計画書に準じたものに。 ・お客の現場部門と開発者達はAgileで。 すばらしい。 政府の案件でも「半分の期間でやるから予算倍なっ！」ってのがまかり通るあたりがすばら