アジャイル開発はもう古い。新しい開発手法を考えてみた。

　私はもうそろそろアジャイル開発も時代遅れになってきたと思っています。というのも、実際に使ってみると不便な点や疑問点が出てきて、アジャイル開発の概念にも改善の余地があると痛切に感じるからです。アジャイル開発の思想そのものは大変すらばらしいものですが、それを言うのであれば、アジャイルより前の開発手法も素晴らしいものであり、アジャイル開発の一部であり続けました。しかしながら情報技術は、既存の素晴らしい開発手法をヴァージョンアップして、新しい開発手法を生み出し続けるものだと思います。そこで、私もアジャイル開発を包含した新しい開発手法を考えました。
　アジャイル開発を長年続けていて気づいたのは、開発者目線過ぎて実情に合っていないのが弱点だという事です。アジャイル開発は、開発対象を作る視点でプロセスを考えます。しかしながら、熟練者はそんなプロセスを取る必要はありません。熟練した技術者は、答えが直接出てきます。熟練者はプロセスを経て答えが出るのではなく、答えから先に出てきます。
　恥ずかしながら、私もある程度アジャイル開発に熟練しているといってもよいと思います。そんな未熟だけどある程度熟練している私程度の人間でも、適切な情報を集めた時点で情報システムの完成形が頭の中に出てきます。従って、どうやって答えを出すかというプロセスではなく、適切な情報を集める部分と、お客様とのコミュニケーションに重点を置くべきだと私は考えています。
　開発は関数として表現できます。必要な情報をxとすると、我々技術者は関数fです。Xを渡した時点で答えが出るのですから、どうやってその未知数xを集めるのか、そして、f(x) = yのyをどうやってお客様に説明するのかを重点に考える必要があります。逆に言えば、分析・設計・実装・テストなどといった細かい分類や、細かい技法はもう言われるまでもなく習得しており、全て並列実行するので細かく考える必要がありません。
　厳密にいうと、アジャイル開発でも細かい分類はないといえばないのですが、まだまだ細かい分類で作業しているのが現実です。ストーリー視点の場合、細かい開発作業に着目していないとも言えますが、そのことに関する私の感想は「細かいことに振り回されすぎ」です。
　細かいストーリーから駆動する開発手法は、変化の激しい現在のビジネスには向きません。何故ならば、細かいストーリーはすぐに変化してしまうからです。従って、そんな変化の多いものを中心にするのではなく、ストーリーを答えから逆算しなければならないのではないでしょうか？今時のお客様は、忠実に従う技術者ではなく、新しい見解を提案してくれる技術者を求めています。
　この事を念頭に置くと、新しい開発手法のプロセスは次の２つです。１、情報収集フェーズ。２、製品調節フェーズ。３、作成フェーズ。
　情報収集フェーズでは、鍵となる情報を収集します。具体的には、現状調査やお客様のヒヤリングなどを行います。情報システムの全貌が見えるまで、情報を収集＆分析します。
　製品調節フェーズでは、お客様が我々の提案を気に入って頂けるか尋ねます。その過程で、開発者側とお客様側の意見のギャップをなくします。
　最後の作成フェーズは、他のフェーズと並行して行います。何故ならば、製品調節フェーズを使用と思えば、ある程度製品を実装しなければなりませんし、情報収集フェーズにおいても、設計や実装などを行い、情報が足りているか否かの判断を行う必要があるからです。なお、これらのフェーズは、お客様が満足するまでスパイラルに行います。
　この開発手法の特徴は、よりお客様目線で製品開発するために、激しく変化するビジネス環境に対応するべく、最終製品のイメージをお客様と共有する事を中心に考える点にあります。
　既存のアジャイル開発は、開発者がどうやって開発するのかばかり考えていました。しかしながら、今更いわれるまでもない細部に注目しても無駄ですし、一番大切なのはお客様の満足度です。より一層、お客様と対等にビジネスをしていく関係を築かねばなりません。
　この新しい開発手法の名前は・・・コレクション＆マッチング開発（仮名）もしくは完成物駆動型開発とでもしておきます。何かの参考になれば幸いです。
　新しい開発手法を思いついたら、ぜひ私にも教えて下さい。情報を共有しましょう。

ネタつつき165 － チーム開発と個人開発の違い

　私は一人でシステムを作ることもありますが、どこかのチームに参加してシステム構築を作るときもあります。ですから、個人としての働き方と、チームとしての働き方の違いが分かります。多くの人が個人と集団の働き方を混同しているように見受けられるので、今回は個人とチームの働き方の違いについて書くことにしました。
　私は一人でシステムを作る際には、一切の無駄を省き全てを並列処理します。ソフトウェア工学では、開発工程が提唱されていますが、全てを並列的にするのでほとんど関係ありません。お客様に、いち早く高品質なシステムを届ける事しか考えません。学問と実務には乖離があり、教科書通りに仕事を進めるよりも、最大限のパフォーマンスを発揮する独自の方法をやった方が目的に適っています。自分というリソースを最大限に発揮することを考えています。
　一方、チーム開発ではそんなことはしません。何故ならば、チームでは個人の力を発揮する方法ではなく、他の人が力を発揮できるように考えるからです。チーム開発で、各々が個人的な方法で仕事を進めれば、一体どうなるでしょうか？おそらく、最悪のシステムが出来上がるか、システムが完成する前にプロジェクトが終わるでしょう。自分ではなく、周りのリソースを最大限に発揮することを考えなくてはなりません。
　個人とチームの違いは、力の使い方にあるといっても過言ではないでしょう。一人でするときは、個人の力を発揮したほうが良い商品が出来上がります。しかし、チームで開発するときは、他の人の力を発揮する方が良い商品が出来上がります。システムという同じものを来るのですから、仕事は同じだと考えられがちです。しかしながら、実際は力の使い方が異なります。
　この事は今回に限った話ではありません。何をするにしても、性質を見極め、その性質にあった方法を試すのが一番です。自分のエゴを捨て、思考の幅を広げましょう。そうすれば、何事も上手くいくでしょう。

イテレーション単位についての考察

　アジャイル開発において、イテレーションの単位は重要です。しかしながら、そのことについて海底ある資料が見つからないので自分で書くことにしました。
　私は様々なプロジェクトで、週、日、時の三つの単位を実践してみました。その結果わかったことがあります。それは、プロジェクトの規模、ユーザーの受け入れスピード、開発側の作成スピードの三要因から適切なイテレーション単位が決まるという事です。
　昔、いくつかの不定形プロジェクトで、全てが1イテレーションになってしまったことがあります。単位は週です。これはどういうことかというと、ユーザーが要望する事柄が全て1週間で納品する状態です。このプロジェクトは、ゴールはある程度決まっていたものの、情報システムに慣れていないお客様は手探りの状態であり、慎重に確認を取りながら進める必要がありました。従って、お客様が具体的に要求を決め、その成果物を元に話し合い、次の要望を決めるという開発サイクルに自然となりました。こうなってしまうと、一度に決定する要望が少なく、何でも1週間以内に納品までできる状態になってしまったのです。
　イメージしずらいと思いますので、会話形式で状況のイメージを書きます。むろん守秘義務のため細部を書きません。

お客様「先週分の商品を検品している最中です。今のところ、大好評です。」
私「有難うございます。」
お客様「それで、次に話しを進めたいのですが、
　インドリさんはどうすればよいと思いますか？」
私「貴社におかれましては、○○業務を情報化し、
　コスト削減と利益増大を目指すのが得策かと思います。」
お客様「なるほど、○○業務ですか。
　あの辺は、検証もしやすく、効果も見やすいので、我が社としても助かります。」
私「承知いたしました。その方針で進めるとなると・・・、
　かくかくしかじかになりますが、よろしいでしょうか？」
お客様「業務手順に変更がありますか？」
私「そうですね・・・貴社の業務手順から言うと、
　○○の行程を省略し、今回開発するシステムの○○を使用するという形になります。
　操作法につきましては、既存画面のパターンを踏襲しますから、
　教育コストもあまり要らないと思います。
画面はこんな感じでいかがですか？」
ここで私は下手なGUI画面の絵をかきます。
お客様「なるほど、この画面だと今まで同じ操作感覚のようですね。
　ただ、前回と操作する人が別になりますので、大丈夫でしょうか？」
私「担当者は○○課の人ですよね？」
お客様「ええ、そうです。」
私「貴社の業務書類を拝見したところ、今回話題になっている業務手順では、
　いくつかの書類を記入するという事になっています。」
お客様「ええと、これらの書類ですか？」
私「はい。今回、それらの書類から項目を抜き出し纏めてみました。
　ですから、業務で慣れ親しんでいる形式となっているので、
　違和感を減らせると思います。」
お客様「それはいいアイデアですね。それは、いつ出来上がりますか？」
私「有難うございます。来週出来上がります。」
お客様（笑顔で）「やはり、来週ですか。
　インドリさんならばそういうと思いました。」
私「どうしてですか？」
お客様「何を頼んでも、インドリさんは、来週までには出来上がるといいますから。
　しかも、実際に作ってくるので正直言って驚いております。
　システム会社の人はみんなそうなんですか？」
私「いえ、普通のシステム会社は、人月単価で運用されているので、多分違うと思います。
　私の場合個人ですから、余計な会議も意思決定もいらず、
　今現在開発しながら打ち合わせをしておりますので、
　今現在の技術で考えられる最高スピードで開発していると思います。」
お客様「それは、すごいですね。
　X社さんから評判を伺っておりましたが、
　ここまで仕事が速いとは思いませんでした。」
私「有難うございます。
　それでは、画面のサンプルについては今日明日中に送信しますので、
　ご確認して頂きたく思います。
　気になったことがあれば、何でもおっしゃってください。
　変更が無ければ、来週には完成品を持ってきます。」
お客様「その方向でよろしくお願いいたします。」

大体こんな具合です。お客様が喜んでいるから問題がないとも考えられますが、私自身はこの状況を問題視しています。何故ならば、イテレーションの意味が全くないからです。
　アジャイル開発は、適切なイテレーションを決定し、お客様と歩調を合わせつつ開発する事が重要です。たとえお客様が喜んでいても、開発手法としては間違いです。お客様に喜んでいただけるのは前提で、今よりもっと正しく開発することを目指さなければなりません。
　そんな事情から、随分前に日単位のイテレーションを採用しています。それでも二三年前から、日単位のイテレーションでも違和感を覚えるようになりました。日単位では、ちょっと曖昧で、お客様のスケジュールを乱す場合があり得ます。私としては、お客様のスケジュールを1ミリも変えないようにしたいので、より精密で高度な開発手法を考えている最中です。私は、お客様がシステム開発の依頼前と全く変わらずに、業務を続けられることを目指しているのです。
　そういった経緯から、1イテレーション1時間のアジャイル開発を考えたのですが、結局のところ全面的に導入できない状態です。その理由を考えるために分析し、次の関係を導き出しました。アジャイル開発のスピードは、開発規模を超えない（第一の壁）。また、お客様の受け入れ態勢（第二の壁）と、開発側の製作スピード（第三の壁）が採用可能なイテレーションを決定する。

1イテレーション＝規模÷受け入れ態勢÷開発スピード。

　すなわち、プロジェクトの性質・受け入れ態勢・開発スピードの酸要因により、適切なイテレーションは決定します。ですから、毎回イテレーションの決定を行う工程が必要になります。私はこの工程を削減し、どのようなプロジェクトでも、いかなる状況下でも正しい、理想的なイテレーションを探しているのですが、残念ながら今のところ発見できていません。
　纏めます。アジャイル開発の単位である1イテレーションには、週・日・時の三単位が考えられます。イテレーションの単位は、プロジェクトの性質、受け入れ態勢、開発スピードの三要因で決定されます。残念ながら、絶対的に正しいイテレーションは発見できておらず、現状は1イテレーションの単位を毎回決定しなければなりません。この稚拙な文章が少しでも役立てば幸いです。

アジャイル開発は走りながら計画する

　どうやらアジャイル開発を誤解している人が多いようなので、アジャイル開発の真実について、現場で実際に使っている人間の立場から書くことにしました。
　アジャイル開発で一番よくある誤解は、分析や設計などをせず、直接プログラミングだけをするというものです。それは、スラムダンク方式であって、アジャイル開発ではありません。スラムダンク方式というのは、開発方法論を全く使用せず、勘でプログラミングをしている状態を示す言葉です。アジャイル開発はよく誤解されますが、開発方法論の一種ですから無計画でするものではありません。
　では、いつ分析と設計をするのでしょうか？「それは、今でしょう。」というのは半分冗談ですが、真実も含んでいます。というのも、ウォーターフォール型開発とは違い、最初の段階で集中してするものではありませんが、しかるべき時にするものだからです。
　具体的には、その時点でわかっている範囲（スコープ）で、分析と設計をします。適切な用語がないので、私はこれをドメインスコープもしくは関心領域と呼んでいます。より細かく実例を言うと、私はお客様と会話しながら、運用イメージに至るまで、全ての開発行程を脳内でやります。この時、お客様が要望している範囲がドメインスコープであり、その範囲内および、接点と思われる部分をすべて分析と設計を同時にしています。
　先ほど言ったのは私個人の技ですが、集団作業をするときも考え方としては同じです。分析と設計は実装とセットで常に行うものなのです。例えば、アジャイル開発の一種スクラム開発をする場合、お客様が望んでいる範囲の分析と設計を作業とみなし、プロダクトバックログに優先順を高くして入れます。バックログに入れるのは実装作業だけと誤解している人も多いようですが、プロダクトバックログは、実装に限らずシステム開発に必要なもの全てが要素です。従って、しかるべき分析と設計もバックログに入れるのです。
　ただし、アジャイル開発がウォーターフォール型開発は大きく違いますから、一度バックログに入れて、やったらおしまいというものではない点に注意してください。仕様が変更されたり、実装結果から新しいことが判明したりしたら、また分析と設計の作業をバックログに入れます。常にやるときは今なのです。
　現実で起こる変化に対応して、アジャイル開発のバックログ（やるべき作業）は常に変化します。しかしだからと言って、状況に流されながら、先を考えずに実装だけしていればいいというものではありません。プロジェクトの闇の中、常に見通せる範囲の分析と設計を行います。一般的に分析と設計というと、硬直したもののように感じられるでしょう。ですが実際は、変化に対応して、柔軟に分析と設計を行うのです。無計画に現実に流されるのと、現実を直視して計画を変更しながら開発するのとでは大きな差があります。
　アジャイル開発は言葉のイメージだけが一人歩きしている感がありますが、実際に現場で行っているものとは違うことが多いので注意してください。どうやら、アジャイル開発に限らず、流行ると言葉のイメージが独り歩きするようです。一例をあげると、オブジェクト指向もアジャイル開発同様、イメージが独り歩きしているようです。一部をすべてだと錯覚したり、データ中心とプロセス中心を無暗に排除したり、実際のものとは違うものをオブジェクト指向と勘違いしている人が多々見受けられます。もしかしたら、有名で知っているつもりの言葉ほど疑って、よく調べる必要があるのかもしれません。

Team Foundation Serverの403エラーで悩んだら

　みんな、Team Foundation Server使っていますか？Windows系開発者ならば使っていますよね？
　Team Foundation Serverは、アジャイル開発をするのに必須のアイテムだといってもいいでしょう。なおかつ、アジャイル開発をしない人にも役立つ優れものです。そんな便利なTeam Foundation Serverですが、日本語の資料がなくても困っている人が多いと思います。だから今回はよくあるエラーの403について書きます。
　Team Foundation Serverを使っていると誰しも遭遇すると思うのですが、403のエラーは結構戸惑いますよね。私も遭遇した時戸惑いました。特にWindowsや開発環境のバージョンが上がってから目をすることが多くなっています。何故ならば、403はセキュリティ関係のエラーだからです。
403というエラーコードは、必要とされている権限がないとき発生します。ですから、403を目にしたとき、まずはセキュリティの資格情報について考えましょう。しかも、Team Foundation Serverを使っているときの多くのケースは、発生場所がIISです。IISのセキュリティ権限をチェックしましょう。簡単な権限設定ならば多くの人が解決すると思うので、これから、その中でもちょっとややこしい設定を書きます。
　難しいのはスクリプトの実行権限です。設定するための画面が遠くて苦労します。その順番は、コントロールパネル　→　管理ツール　→　インターネットインフォーメーションサービス（IIS）マネージャー　→　ハンドラーマッピング　→ 機能のアクセス許可　→　スクリプト　です。ここまで来たら、後は実行権限を与えるか考えるだけです。目標に至るまで画面遷移が長くて大変ですが頑張ろう。　
　ところで、何故エラーメッセージがあれほど簡潔で分かりにくいのでしょうか？疑問に感じたり、怒りを覚えたりした人もいるかと思います。それは、セキュリティ的な理由があります。エラーメッセージを詳細にすると、クラッカーに攻撃するための情報を与える羽目になります。だから、セキュリティ関係のエラーは、マイクロソフト社のものに限らず、そっけないものになるのです。この辺は、すごくデリケートで、セキュリティを考える側にとって、頭が痛い問題です。ですから、怒ったら駄目です。業務システムを開発する側は、このセキュリティ事情をユーザーに必ず伝えるべきです。教えておかないとトラブルのもとになります。システムを開発する際は気を付けてください。

分秒単位の最速アジャイル開発を考えてみた

　ビジネスに速さが求められているのが原因でここ最近は、1時間1イテレーションでアジャイル開発することも要求されてきました。基本は日単位なのですが、何時間かかるのか気にされるお客様も増えてきています。また、内部イテレーションとして時単位を採用する場合もあります。こうなってくると当然、分もしくは秒単位のアジャイル開発が気になります。そこで、もっと速くしたらどうなるのかについて考察してみました。
　1イテレーション1～10分、もしくは1イテレーション10秒程度のアジャイル開発（まさか1秒単位で知りたいと思う人はいないでしょう）とはどんなものでしょうか？私が推測するに、あらゆるシステムの要素を細分化することが前提になるでしょう。何故ならば、分もしくは秒単位で見積もりを出すのですから、自然と誤差が大きくなる大きな粒度での見積もりを避けると思われるからです。また、粒度が大きくなり、常に数イテレーションが普通になってくると、分秒単位で開発を考える意味がなくなってしまいます。一般的に、1イテレーションの要素が全くない状態だと見積もりの正当性が疑問視されます。誰しも最小単位がわからない状態では、見積もりの精度を疑うでしょう。従って、精密かつ細かく見積もりを出すのが開発の前提となります。
　さて、そこまで精密にアジャイル開発をするプロジェクトとはどんなものでしょうか？運用する対象を考えない事には始まりません。私はそんなプロジェクトに出会ったことがないので推測するほかないのですが、社運を賭けて行うプロジェクト、他社との競合が考えられる速さが勝負のプロジェクト、・・・などの極めて重要な一大プロジェクトだと思います。人が精密に行うときは、ほぼ必ずと言っていいほど重要なものです。よほど変わった人ではない限り、人は重要でないものにまで神経をすり減らさないでしょうし、そこまで精度が高い進捗情報が必要でないと思います。
　話しを進めるために、細かな仕様もあり動機もあるとしましょう。そうなると問題となるのは、どのように開発するのかです。通常の開発方法では、分秒単位の進捗状況を管理できないでしょうし、細かな単位で仕事を割り振らなければなりません。となれば、細かな単位の進捗情報と連動する開発ツール、およびプロジェクト運用テクニックが必要です。
　分秒単位で開発を管理するという事は、現在どの機能に何秒使っているのかを常に把握しなければなりません。それに加えて、細かな単位で分けられた機能を、細かく技術者に指示できなければ、見積もりを保証することはできません。分秒単位の見積もりを出すのですから、何年何月何日何分何秒にどの機能がどれだけの割合完成しているのかわからないとなりません。その難題を達成するには、プロジェクトの管理者は、迷わず仕事を割り当てないとなりません。何故ならば、迷うことによる時間のロスは、通常のアジャイル開発よりも大きいからです。仮に120秒で仕上がる予定の機能について30秒悩んだら、それだけで25％の時間を無駄にしたことになってしまいます。すなわち、分秒単位のアジャイル開発を採用するという事は、それに伴う分割コストとの戦いを意味するのです。
　普通の人は物事を細かく分けると、それだけ精度や信頼度がますと考えるでしょう。しかしながら、システム開発はそれと逆に、精度と信頼性が落ちます。何故ならば、分割を行う事で発生する各種コストと不確定要素が増えるからです。細かく管理すればするほど、コミュニケーションコストと管理コストは増しますし、人は機械のように精密かつ正確に働けません。それゆえに、成功する確率が減ります。
　では、分秒単位のアジャイル開発は絶対にありえないでしょうか？私はそう思いません。世界の変化スピードはまし、人が求められる仕事量と技術進歩は年を追うごとに速くなっています。ならば、今では考えられない開発手法も、将来では当たり前になると考えるのが妥当だといえるでしょう。それに、どんな技法にも適材適所があります。プロジェクト単位ではなく、自分用の時間管理で役立つかもしれません。なんにせよ、分秒単位のアジャイル開発を想定しておくと、将来の仕事に役立つと思います。今目の前にある仕事だけをさばいていては、変化の波についていけません。常にあらゆる状況を想定し、それを受け入れる準備をしておけば、秒進分歩と呼ばれるこの業界でも余裕をもって生き抜けるでしょう。

1時間1イテレーションは可能か？

　昨今は既に1日1イテレーションの時代に突入しています。私はおよそ10年前（2002年頃）にはすでにしていましたが（フリーになるのと同時に実施している）、世間一般でもそれが常識になりつつある感がします。そこで、1時間1イテレーションにするとどうなるのかを書くことにしました。時間1イテレーションのアジャイル開発を何度かしてみましたが、非常に難しくあまり良い結果をもたらしませんでした。その理由はいろいろありますからこれから説明します。
　第1に文化的な問題です。実現可能性から言えば、開発者である私には可能でしたが、お客様側が対応できませんでした。日本の意思決定システムでは、1時間単位で変化する開発スピードについていけません。よく言われますが、日本は慎重に和をもって事をなす民族です。その文化がある限り、時間単位で意思決定を下すのは不可能です。従って、そのまま開発するのではなく、お客様の受け入れ態勢を考慮して、開発以外の工夫をせねばなりません。純粋な開発スピードでは可能ですが、お客様を助けるコストを加味すると、非常に難しいと言わざるを得ません。
　第2にコミュニケーションコストの問題です。私が1時間1イテレーションのペースで開発をできる理由は、全ての開発要素を並列的に処理できるからです。お客様と会話しながら、分析・設計・実装・運用・テスト・ネットワーク・データベース・セキュリティなどの全ての事柄を頭の中でします。そして、お客様との会話が終わった時点で、ほとんどの事が終わっており、後は実際に作業するだけの状態になっています。それぐらいしないと1時間1イテレーションは実現できません。しかしながら、開発チームで仕事をするとなると、コミュニケーションコストが発生しますから、そのスピードで物事を処理するのはほぼ不可能です。成功するには、開発チームの全ての人間が阿吽の呼吸で意思疎通ができる、熟練のプロである必要があります。実際問題それだけの人材を集められないでしょう。
　第3にビジネス面の問題があります。開発はビジネスでもあります。ビジネス面で考えたとき、契約と信頼関係が1時間1イテレーション実現の障壁となります。事が速く進むのは良いのですが、ビジネスに契約はつきものです。契約をどうやってするのかを考えねばなりません。契約にもコストが発生しますから、いちいち契約をするのは不可能です。従って、高い信頼関係がないと成り立ちません。その他にも、ビジネスとして考えねばならないことが沢山あります。
　最後に利益が問題となります。3つの問題を解決して得られる利益に疑問が生じます。開発側とお客様側の双方に、それだけの負担を伴う開発が利益を出すのか、それが大いに疑問です。1時間1イテレーションで開発するのは非常に疲れます。同時に複数の仕事を引き受ける場合も想定すると、私の感覚からいえば、プロジェクト3件が限界だと思います。技術力向上により、限界は少し増えるでしょうが、開発チームとなるとそれが可能だとは思えません。
　纏めます。1時間1イテレーションは一応可能ですが、いくつもの条件を満たさないと、プロジェクトは失敗します。それだけのリスクとコストをかけるのですから、大きな利益が得られる状況でのみ行うべきだと思います。しかしながら、お客様側に1日1イテレーションを提示しておき、開発チーム内で作業を細かく分け、1時間1イテレーションで管理することは一般的に可能だと思います。すなわち、外部イテレーションと内部イテレーションを設定するのです。そうすればより高度な開発体制が整います。むろんこれにも高度な開発体制が要求されます。
　これらの結果を踏まえると、イテレーションの単位はプロジェクトに適したものを選ぶという原則が成り立つと思います。アジャイル開発はもともと柔軟性が必要な開発手法です。イテレーションの設定も柔軟に行いましょう。

最近のアジャイル事情

　アジャイルと言えばイテレーションです。昔は、1イテレーションを何週間にするのかが話題になっていました。しかしながら、今アジャイルで「何週間」なんていったら「アジャイルじゃねえ」と笑われます。というのも、単位が週ではなく、日になっているからです。
　10年以上仕事している人ならば分かると思うのですが、開発に馴れてくると大概のものは1週間で出来てしまいます。下手なユーザーストーリーを設定すれば別ですが、新人よりも分析能力が高いので、そもそも1週間以上かかるようなユーザーストーリーなんてほとんど設定しません。10年以上のキャリアを持つ人が、1週間以上もかかるストーリーなんて粒度が粗すぎます。
　アジャイルの本質は変化なので、お客様に提示するまでの時間を極力短くし、ユーザーからのフィードバックを頻繁に得ようとします。それ故に速さを求め続け、お客様の要求を引き出した時点で、分析／設計／実装／運用の想定が殆ど終わっている状態になりますから、大概の事は「来週お持ちします」で終わりです。後はフィードバックを繰り返すだけです。
　殆どの事が1週間以内に終わるので、自然とお客様から「もっと細かく報告してくれ」と言われるようになります。細かくと言ってもマイクロマネージメントの話しをしているのではありません。ユーザーストーリーはある程度の長さを持ちますから、それを細かくしたサブストーリーの進行状況をお客様は聞きたいわけです。
　その理由をお客様に聞いたところ、「仕事が速すぎるのでこちらの要求が間違っていないか心配になる」だそうです。何週間もかかっている遅き時代では、仕様を変更したい時に直ぐに声を掛けられます。しかしながら、今の様に日単位のアジャイルでは、1週間後には完成しているのでストップが出来ないのです。これは仕様の確認作業が原因で起こる事象です。
　システムを発注する側のお客様はその道のプロですが、情報技術については素人です。ですから、何を要求したいのか分からない状態です。従って、実際に試してみてようやく判断しています。アジャイル化により速さが増すと、お客様の確認作業が間に合いません。そこで、今何を発注しているのか詳細に把握したくなるわけです。
　ただし、お客様に報告する情報は簡潔でなくてはなりません。ただでさえ、ついていけない速さになりつつあるので、情報の洪水に溺れてしまわないように、情報量を制御せねばなりません。お客様が知りたい抽象度、かつ知りたいであろう情報を察して報告するセンスが求められます。
　例えば、システムの仕様について憂慮するべき点が見つかる場合もあります。その場合、お客様は極力早期に検討するために、一刻も早くその情報を知りたいと願います。大概の場合、ユーザーストーリーを練る段階で分かりますが、ユーザーストーリーの整合性を図るために、複数のユーザーストーリーを予め作る作業があります。その段階で判明した仕様の不備、もしくは検討課題が発生する場合もあります。また、所詮人間がする事ですから、やってみて初めて気付く事もあります。そうした例外情報こそお客様は知りたいのです。その他にも「業務そのものが変更された」なんて場合もあります。世の中は「人間にとっては想定外」で出来ているのです。神様でなければ100％の未来予知はできません。ですから、想定外が起こる事を想定しておくのは当然なのです。
　こうした出来事から私は、今や開発は速くて当たり前であり、システムを受け入れる側のお客様に対して如何にきめ細かいサービスをするのかが求められているのだと考えました。システム開発もサービスの一種です。我々開発者は、お客様がより快適に感じるサービスの提供を、目指さなくてはならないのではないでしょうか？

アジャイル開発を元に考えるプロジェクトマネージャのあり方22

　この記事は、アジャイル開発を元に考えるプロジェクトマネージャのあり方21の続きです。前回は、経営資源「情報」とプロジェクトの関係について解説しました。今回は、今までの総括をします。
　今回までの解説で、従来型のウォーターフォール開発モデルで培われた「管理のための管理」をするプロジェクトマネージャは、変化が早い現代に合わない事が分かって頂けると思います。今求められているのは、変化に対して臨機応変に対処できる誰からも頼られる人です。
　変化に対し柔軟かつ迅速に対処するには、物事を厳密にコントロールしようとする管理ではなく、変化を前提とした誘導型管理をする必要があります。開発メンバーを統治するべき部下として捉えるのではなく、プロジェクト成功を共に目指す仲間として捉えます。開発メンバーを統制するのではなく、成功へと導くために「もの」、「情報」、「金」、「時間」を有効に使います。
　もちろん、プロジェクトマネージャは開発メンバーにだけを見ていればいいという事はありません。自社はもちろんのこと、関連会社の利害関係者の事を考えなくてはなりません。そしてなによりも、お客様の事を第一に考えなくてはなりません。
　たまにお客様の事を考えない開発者がいますが、お客様の事を考えないで開発したシステムは役に立ちません。プロジェクトマネージャは、お客様にとって実際に使えるシステムなのかをよく考え、開発メンバーが間違った方向へ進まないようにしなくてはなりません。
　従来のプロジェクトマネージャは、「部下を統率する上司」といった色が強く出ていました。変化が遅い時代では、そういったプロジェクトマネージャでも結果を残す事が出来ました。しかしながら、現代は変化が早く、あらかじめ全てを正確に予測し、物事を制御できません。従って、統制ではなく常に誘導をし続けなくてはプロジェクトは失敗します。
　アジャイル開発を採用するかどうかは、会社の体質に関する難しい問題だと思います。しかしながら、求められているプロジェクトマネージャ像は変わりません。この連載を読んで少しでも多くの人が、新しいプロジェクトマネージャ像について考えて頂ければ幸いです。

アジャイル開発を元に考えるプロジェクトマネージャのあり方21

　この記事はアジャイル開発を元に考えるプロジェクトマネージャのあり方20の続きです。前回は、経営資源「もの」とプロジェクトの関係について解説しました。今回は、経営資源「情報」とプロジェクトの関係について解説します。
　プロジェクトが始まると、様々な情報が飛び交います。プロジェクトで発生した情報をコントロールし、適切な人に情報を提供するのもまたプロジェクトマネージャの仕事です。情報の管理をおざなりにすると、開発メンバーや利害関係者に余計な負担を掛け、情報の誤差がデスマーチを呼びます。分かり難いと思いますので、具体例を挙げつつ詳しく説明します。
　仕様の変更はほぼ必ず発生します。よほど単純なプロジェクトでない限り、あらかじめ全ての情報を完備し、仕様を完璧にする事は不可能です。仕様の変更に伴い、開発メンバーにその事を伝える必要があります。この際に情報の管理をしないと、仕様の変更を知っているメンバーと、仕様の変更を知らないメンバーとの情報格差が生まれ、その差がシステムにバグを発生させます。
　仕様変更はそれほど頻繁に起こらないと、考える人もいるでしょう。しかしながら、オブジェクトの変更と言った些細な変化も日々発生します。そうした比較的小さな情報の変化でも積み重なると、プロジェクトを混乱させます。
　情報を必要とするのは開発メンバーだけではありません。利害関係者も情報を必要としています。責任者はそのプロジェクトの進歩度や、現在起っている課題／問題に興味がありますし、お客様は自分の要求が正しく解釈されているのかを気にします。開発が終わってから、お客様の要望と違うシステムだと分かっても手遅れです。
　アジャイル開発では、プロジェクトに関する情報の管理もカバーしています。開発メンバー間の情報を共有するための「共同所有」、お客様と開発メンバーの情報を共有するための「オンサイトのユーザ」がありますし、アジャイル開発の一種スクラム開発では情報のコントロールも行う役割「プロダクトオーナー」が設定されています。
　プロジェクトは情報が命です。プロジェクトマネージャは情報を管理し、開発メンバーと利害関係者を満足させなければなりません。大変な仕事ですが成功すれば、内外ともに評価の高いマネージャになれます。