アジャイル開発についてパワーポイント（英語）を作成してみた

先週アジャイル開発についての紹介パワーポイントを作成して、チーム内での勉強会を行ってみた。社内的な情報を省いて外部公開出来る形にしてSlideshareにアップロードしてみた。ただし、ウチの勉強会が英語プレゼンテーションの練習も兼ねているので英語の資料。

Agile software development from hnishim

といいつつSlideshareを使ってみたかっただけ、という節もある。

 チームメンバ（というか若手メンバ）の気をひくため、あえてアジャイル開発を曲解している部分もある気がする（ツールの部分とか）が、ちゃんとした理解の前の足がかりになればいいなぁ、と思っている。

アジャイルサムライ−達人開発者への道−

アジャイル開発とスクラム 顧客・技術・経営をつなぐ協調的ソフトウェア開発マネジメント

ソフトウェア開発での「技術の伝え方」問題（前編）

畑村洋太郎氏の新書『組織を強くする技術の伝え方』を読んでの書評を書こうと思ったのだが、タイトルからの連想で本の引用なしで書いてしまったので書評ではない形式で載せておく。

ソフトウェア開発での「技術の伝え方」問題

ソフトウェア開発や運用の現場でも、技術の伝え方は非常にクリティカルな問題だろう。それには大きく2つの問題があるのではないか？

1つ目は一部の優秀な開発者にのみ技術・知識が蓄積され、「誰々に聞かないと分からない」領域が出来上がってしまうこと。

2つ目はなんとか仕様や技術を形式知化しようとして、大量の（それもExcelでの）設計書や手順書を作成して、結局大量すぎてメンテされず使われなくなること。

野中郁次郎先生のSECIモデルで整理するとこれ以外にも考えられる問題がありそうだが、今回はこの2点に絞ってみる。

技術の属人化

技術とは属人化しやすいもので、何故かと言うと以下の3点あたりが主要な原因だろう。

1. 開発者自体も無意識に行っていることを含んでいるため、他人に伝えられる形になっていない、その形にすることが面倒
2. 他者に伝えることで「自分だけが知っている」という優位性がなくなってしまうため、伝える側にとって面白くない
3. 技術を他者に伝えるという行為自体は（ソフトウェア開発という意味で）生産活動ではないため、伝えるという行為に意味を見出せない

1.は野中先生が扱っている「暗黙知の形式知化」の話なので今回は詳細は省こう。意識的に言葉にする、形式知化するというのは意識的にやらなければなかなかやらないし、やってみると如何に非常に難しい（出来ないことを実感させられる）行為なので、ひたすら推進するしかないのでは。

優位性がなくなってしまう恐怖

自分の技術に自信を持っている開発者になればなるほど、自分の技術を神聖視する。これは自分でしか出来ないことで普通の開発者では理解できない、と。（これは言い過ぎか。）

これを打破するには、技術共有自体を評価する制度が必要だろう。「君しか出来ない」ことを評価するのではなく、むしろ他のメンバでも出来るようにしたことを評価すること、またその後のポジションを保証する、むしろより魅力的なものを用意することが必要だろう。そのためには人材に流動性がある（新入社員が定期的に配属される、毎年昇進・昇給のチャンスがある）ということが必要であるが。

生産活動ではない行為

開発者の本分は開発である。人に教えることではなく動くモノを作ることが主目的であるし、実際にそれを行っているときが一番「楽しい」ときのはずだ。（マネジャー視点ではそう思っている人を採用しなければいけないし、そう思わせるようにしなければいけない。）そういった人々に開発を行わずに、今まで開発してきたものの仕様や、蓄積してきた知識を形式知化しろと言っても（仮にそれが評価されることだとしても）面倒臭いだけだろう。

何故面倒臭い、価値を見出せないのだろうか？たぶんそれが生産活動ではないからだ。動くモノ、プログラムを書くことは生産活動そのものであり、即「使ってもらえる」ものになるので価値創造をしている実感が湧きやすい。それに対して人に教えるということは、それがいつ実になるか分からず、そうするとモチベーションに繋がらなくなる。*1

これを解消するには形式知化の作業自体を生産活動の中に組み込んでしまうのが良いのではないか。生産活動と切り離してしまうから面倒になるので、それがシームレスに同一作業に内包されていれば面倒さは軽減されるだろう。

具体的に言えば、ペアプログラミングを利用して実装方法を属人化しないとか、開発レビューを多人数で行ってチーム内で仕様を共有しておくという手法。あるいはコード内のコメント規約にてコーディングとともに仕様をコメントに落としこむようにするとか。

この開発行為（生産活動）と形式知化の一体化はもっと具体例とともに掘り下げたいところ。また考える機会を設けてみよう。

といったところで長くなったので中断。2つ目の「仕様書がメンテされない問題」は次回のテーマとしてみる。

組織を強くする技術の伝え方 (講談社現代新書)

知識創造企業

*1:そういう意味では、テストという自らバグ出しを行う懺悔フェーズが開発者にとってモチベーションが湧かない理由と同じ。

ツールの導入にはメンバのコミットメントが必要：『チーム開発実践入門』を読んで

 Redmineを導入しようと色々と調べているうちにアジャイルやDevOpsといった文脈でソフトウェア開発を効率的に行う、その品質を向上させるためのツールがずいぶんと揃ってきていることを知れた。それらの多くはOSS（オープンソースソフトウェア）なのでインストールするサーバさえあれば原則コストフリーで導入出来てしまう。

これは導入を検討してみるしかない、ということでその辺りのツール群が体系的にまとめられているものはないかな、ということで行き当たったのが本書である。

ちょっと書名が分かりにくくないかな？読んでみると確かに適切なタイトルなのだが「チーム開発」という言葉からはチームビルディングや（もっとソフトな意味での）コラボレーションなどの印象を受ける。

ケーススタディ

第1〜2章は導入部となっていて、本書のスコーピングと、「ダメプロジェクト」の事例紹介（ケーススタディ）から始まっている。こういった失敗例としてのケーススタディってなかなか難しくって、あまりにイケてなさ過ぎる事例を出してしまうと「さすがにこれはありえないだろ」と読者が引いてしまうし、とはいえあまり良い感じにしてしまうと失敗例にならない。個人的には障害管理がメールではありえないだろ、さすがにエクセル管理くらいはしてるだろ、と思ってしまったが、良く考えれば一昨年サポートに行った炎上プロジェクトでは確かにそれさえも出来ておらず、そこにエクセル管理を入れることだけのために僕がいたことを思いだした。とするとこの例はあながちありえないケースでもないのかも。

記載のメッシュ

ケーススタディに続き、以下の4領域について説明が続く。

• バージョン管理
• チケット管理
• 継続的インテグレーション・継続的デリバリ
• リグレッションテスト

上記4つの領域について具体的なソフトウェア名とそれがどう使えるかをざくっと把握し、チーム開発ツールとして今何が揃っているのかを知り、自分のプロジェクトであったらどう使えそうかを考えるきっかけになる本として、現在ほぼ唯一日本語で読める良書だろう。

一方で、具体的なインストール手順やカスタマイズ方法などが書面の半分程度を占めている印象だが、概要を知るためにそれらの情報は必須だろうか。実際にインストールやカスタマイズを行うときはどうせツール個別の書籍や情報にあたるものじゃないかな？そのときに本書を開くとは思えないので、じゃあなんでここに書いてあるのかと思うと意味が無い気がする。

そういった内容よりももっと、どういったことがこれらのツールによって可能で、そのときにポイントとなることは何で、こういった解決策が考えられるといった内容を充実させてくれれば、（もしくはそういった内容はすでに書けているのでもっと薄くしてしまったほうが）良かったのにと思ってしまう。

でもこれはもしかすると非技術者な僕から見たときの視点であって、開発者の人からすると、何が出来る、どう使えるみたいな話だけだと「地に足がついていない」と評価するのかな？

ツール導入に大切なこと

さて、こういったツールの導入で大切なのは、本書でも何度か出ている通り「使用するメンバが使う意味を納得すること」だと思う。

そのために一番良いのは、開発者側から自然と「このツール使いたい！」という声が挙がって、草の根的にツールが浸透していく場合。逆に残念なのはトップダウンで「このツール使え」とだけ降りてきて結局「使う」事自体が目的化してしまう場合。

実は昨年くらいにそんなトップダウン型でテスト自動化ツールを我々のチームで試験導入してみようということになったのだが、完全に失敗した。というより失敗”させた"といったほうが正しい。導入推進している人たちもイマイチであったものの、何がダメだったかというと我々のチームがそのツールを入れるメリットを感じていなかったからだ。ツールの得手不得手も分からない状態で渡され使えと言われても、「こう使ったら我々のチームで効果的に使えるんじゃないか」という発想には至らない。結果、我々のチームに「テスト自動化アレルギー」を残しただけになってしまった。

そのようなことがあったので、現在実施しているRedmine導入ではチームメンバへの浸透を第一に考えている。本当は草の根的に声が挙がって使い始める形を取りたかったけれど、ちょっとそれは難しそうだったので推進は僕がやることになってしまったが、「Redmineを入れることで現場的にどういった効果が見込めるか」といった面や、「そもそもOSSとか使って新しい開発手法試してみたくない？？」って若モノの心を揺さぶる方向で攻めている。これが実を結ぶかはこれから次第なので、また導入&運用開始後に判定してみたい。

 

チーム開発実践入門 ~共同作業を円滑に行うツール・メソッド (WEB+DB PRESS plus)

感情の帝王学：『マキアヴェッリと『君主論』』を読んで

たまにはITの現場的な話から離れて、マキャベリを読んでみたのでそれについて。

今回読んだのは『マキアヴェッリと『君主論』』という文庫、これは前半がマキャベリの生涯、およびその周辺の歴史的背景、後半が君主論の内容となっている。正直前半はヨーロッパ人の訳の分からない名前や地名ばかりで読み終わるまでが辛く、覚えていることはひとつもないのだが、もしかするとその後の君主論パートを理解する上で理解を助けてくれている、のかも知れない。

感情の帝王学

マキャベリズムという言葉が「目的のためなら手段を選ばない」思想としてしばしば否定的な意味で使われるが、（Wikipediaにあるように「国家のためであれば」という枕詞を付ければ）まぁその通りだと思う。非常に非情であるし、国家を存続、隆盛させるためであれば犠牲を厭わないという徹底した思想が伺える。

しかしその論理を裏打ちしているものは、徹底的なまでに「感情」の観察結果である。君主がこのような行動をとったら臣下、民衆、敵国はどのように感じるか？では君主はどう振る舞い、どう行動すれば国家を存続、隆盛出来るのか？というロジックでほとんどのことが語られている。

「非情な管理」という意味では同じ方向性であるテイラーの科学的管理法のような、人間を機械のメタファーで見る管理論とは真逆の論理に依拠している*1。むしろプログラマのヤル気にフォーカスしたデマルコの『ピープルウェア』と同類と見たほうが適切だろう。

そういう意味で君主論の内容の現代への応用は孫氏の兵法などよりもしやすいと思う。例えば陣形の話などを学習しても現代に応用するにはそれを一つのメタファーとして捉えてから再度現代的な事象に落とす、という「概念化→具体化」のプロセスが必要なのに対し、君主論の内容は人の感情の話なので場面を中世から現代へ「置き換え」だけしてしまえば通用してしまう。

オフショアに赴くマネジャー

さて、まだ実際の内容に触れていないので引用しながら示唆を導き出してみよう。

言語、習慣、制度において旧来の領土と異なる地域に領土を得た場合、そこには多くの困難があり、それを維持するためには非情な幸運と努力を必要とする。そこに生ずる諸困難に対する最上かつ最も有効な対策の一つは、征服者自らがその地へ赴き、居をかまえることであり、この方策は領有をより確実で永続的たらしめる。

僕が5年前くらいに行った仕事で「インドの開発センタの品質が悪いので、それを落ち着かせつつ日本&中国で巻取る」というのがあったのだが、そのためにインドの開発センタに僕やその大勢の巻取りメンバが行った時、すでに2人の日本人マネジャーが滞在中だった。正直その頃は「この人たちは日本に居ると報告しないといけないし出張の口実作ってインドに逃げて遊んでるだけなんじゃないかなー」とこっそり思ったこともあったのだが、やはりマネジャーが現場を直接見ないとマネジメントは出来ない。特に人種が違う場合は彼らが何を考え、何を行動原理とし、どんなズルをしやすいか、などを理解することはリモートでは絶対に到底無理だ。

メンバリリースの判断

人間は寵愛されるか、抹殺されるか、そのどちらかでなければならないということである。何故ならば、人間は些細な危害に対しては復讐するが、大きなそれに対しては復讐出来ないからである。

まさにマキャベリ節の刺激的な文章だ。プロジェクト体制で言えば「抹殺」はプロジェクトからのリリースにあたるだろうか。プロジェクトに貢献してくれているメンバを評価し、昇給・昇進、チャレンジングなロールを与えることは当然として、そうでないメンバに対して中途半端な処遇、つまり重要なことはさせられないからと低レベルの作業だけ振っていると彼（彼女）自身も不満が溜まり負のスパイラルに陥ってしまう。むしろ早期にパフォーマンスを見極め、本当に活用出来ないメンバはリリース（または配置換え）の選択すべき、なのかも知れない。（ここは断定出来ないなぁ。）

補足：『よいこの君主論』

君主論について読んだ本はこれが実は2冊目で、以1-2年前に『よいこの君主論』を読んだ。これは「もしもクラス統一を目指す小学生がマキャベリの『君主論』を読んだら」という『もしドラ』的な題名でも良さそうな本だがこれがなかなか面白い。

今回佐々木の本書で原典にあたってみると、「あれーそんなこと言ってたっけなー」と思うところも多々あったのだが、君主論の雰囲気を感じ取るには手軽だし、ゲーム的・マンガ的に読み進められるのでオススメ。

マキアヴェッリと『君主論』 (講談社学術文庫)

ピープルウエア 第3版

よいこの君主論 (ちくま文庫)

*1:科学的管理法を非難しているように聞こえる言い方だが、個人的にはむしろ科学的管理法は素晴らしい発明だと思っている。ニュートン力学で説明出来ない 事象がありそのために一般相対性理論があるように、科学的管理法も適用範囲を間違えなければこれ以上ない素晴らしい効力を発揮する管理方法だ。

Redmineのチケット一括登録

今週Redmineに既存の案件を移行しようとプラグインの導入を試してみた。

1−2週間前に社内でOSSの勉強会があったのでどうしたらいいか聞いてみたところ、

• 出来るだけ移行数を減らして（未完了分のみ等）1件1件登録
• Redmineのデータベース構造を解析して直接SQLで登録
• Seleniumなどを利用して1件1件登録するのを自動化

という案を頂いたのだが、プラグインがあることは知っていたので「いやいやさすがにそれはないだろｗ」と心のなかで思いつつプラグインの導入をしてみた次第。

Redmine Importer

 ということで以下などを参照しながらプラグインの導入をしてみた。

http://stdman.blogspot.jp/2012/08/redmine-20-csv.html

が、結果としては上手くいかない。インストールは出来、管理画面でアクティベート&ロールに権限付与して画面にImporterのタブまでは出るところまではいったのだが、タブが"translattion missing: ja, label_import"などとなってしまう。ちょどここと同じような状態。で、そのタブをクリックしても"Page not found"となってしまう。言語等を変えたり、別の方のGitHubから持ってきたプラグインに差し替えたりしても上手くいかず。

ここでImporterの問題か？そもそもプラグインをインストールするのに僕たちの環境が何かおかしいのかを切り分けするために他のプラグイン（Work Time）を入れてみたら全く問題なくインストール出来たので、Importerの問題のよう。

Redmine 2.5.1をBitNamiで入れているのだが、バージョンが合わないのかなあ。

Redmineチケット★一括★

と、困っているところで「Redmineチケット★一括★」なるフリーウェアを発見。REST APIを使ってRedmineにつながて一括登録をしてくれるそうだ。

これにはexeファイル等と一緒にxlsのテンプレートも用意されており、手順通りにやってみるとかなりすんなりと登録出来た！

ただし、既にかなりガチガチにワークフローや項目のカスタマイズをしていたため、カスタマイズで必須としているところにデータがなかったりするとエラーを吐いて登録出来ない。そのため、カスタマイズを行うよりも前に移行してしまうか、何でも出来るスーパーユーザ権限を自分に与えたりして一時的に制限をゆるめてから登録を行うことが必要だった。

ほとんどの項目がこれで移行出来そうなのだが、課題は2点。

• 1件1件の登録にある程度の時間がかかる。1件2-30秒かかるので、僕のチームの過去案件すべてを登録しようとすると12−3時間必要な計算だ。まぁこれは回しっぱなしにするしかないだろう。
• 「リストから選択」の項目で「複数選択」可にしている項目で、複数選択したデータを入れようとしても、考えられるどのようなフォーマットにしてもエラーとなってしまう。これはデータベース構造を解析しないと解決出来なさそう。ちょっと僕の手には負えないので、今週チームメンバにヘルプを求めようと思っている。（このあたりは引き際が肝心ｗ）

Redmine超入門 (日経BPムック)

入門Redmine 第3版

スクラム的チーム構造と要求管理：『アジャイル開発とスクラム』を読んで

この本のあとに『アジャイルサムライ』を読んだので少し印象が薄まってしまったが、アジャイルとスクラムについてが平易にまとまっており、また各種プラクティスにも言及しているので次に興味を持って調べてみようとするとっかかりとしても良い本だった。

従来のビジネスとITの関係は目的が分断されてしまっており、「要求が劣化する」というのは非常に耳が痛い。

ビジネスはシステムを開発し、投資した以上の効果を上げることが目的である。ところが、ITは契約を満たすこと、すなわち、「使用どおりのシステムを納品すること」が目的になってしまう。

では要求を劣化させずにITをインプリするにはアジャイル開発が必須というわけではないし、逆にアジャイル開発の手法さえ取れば劣化させずに要求を満たせるというわけでもないのだろうが、現時点でそのProbabilityを上げる方策としてはアジャイルが最適解なのだろう。

スクラムのチーム構造

アジャイル、スクラム、そしてXPなどは現時点で明確な線引きはなく渾然一体とした概念となってしまっている（そしてそれは正しい姿なのだと思う）が、その中でスクラムとしての特色は以下の3つにチームの役割が分かれているところだと思う。

• プロダクトオーナー
• 開発チーム
• スクラムマスター

これまでの古典的なウォーターフォール型開発における官僚制的組織であれば、プロジェクトマネージャがプロダクトオーナーとスクラムマスターとしての役割、および開発チームのリーダを兼任している状態だ。これに対しスクラムでは三者の分断を推奨している。プロダクトオーナーが要求をまとめその優先度を明示し、開発チームはプロダクトオーナーは開発のやり方を決めて製品を完成まで持っていき、スクラムマスターは「サーヴァントリーダ」として開発チームが自律的に滞りなく作業を進められるための支援を行う。

 一見するとこの主張には違和感がある。スクラムなどアジャイル系開発手法は比較的小さなチームに適合する手法と言われているが、上記のようにプロジェクトマネージャが有していた職掌を分解して別々の役割を置くというのは小さなチームに適合するのか？というところ。

ただこれはこれまでの組織がプロジェクトマネージャに権限を集約させすぎておりそれ故にプロジェクトマネージャ自身がボトルネックになったり、違う感性・コンピテンシーを求められる役割を全うできずに片手落ちになってしまうというケースが多いという反省点が考慮されていることと、逆に開発チームはこれまで機能単位などで分断されていたのを統合することで全体としてはスリム（リーン）な体制にできていることで説明出来るだろう。

ここで面白かったのは、僕の今いるチームがこの構造に非常に近い形に自然となっていたことだ。僕はチームのリードながら基本的に案件の内容やソリューションは概要レベルのみの把握に留めて管理やチームのサポートに回るスクラムマスター、もうひとりの同じクラスのメンバは要件をきっちりと抑えつつソリューションは基本チームに任せるプロダクトオーナー（チーム内から見れば彼こそチームリードに見えるだろう）、そしてそれ以外のメンバが開発チームとしてそれ以下のチーム割をほとんどなく対応してくれている。このような体制が「今までの感じとちょっと違うな」という違和感を覚えながら良い感じで回っていたのにも、このスクラムの構造を照らし合わせると納得がいく。

ただ、これって『人月の神話』で書かれている「外科手術チーム*1」でも「執刀医」と「管理者」、その他諸々の役割に分けるのと一緒なので、古くて新しい（だけど現実にはなかなか難しい）分担なのかも知れない。

要求の優先順位付け

もう1点、スクラムの特徴を挙げると、要求の管理の部分だろうか。要求を「ストーリ」の形、すなわち完璧な仕様として記述せずにユーザの言葉で簡潔に記述することとともに、全ての要求に順番をつけることが求められている。

順位付けされて並んでいることが重要で、例えば要求に高・中・低のような優先度を付けるわけではない。

これは非常にシンプルな指針であるのにこれまで気が付かなかった。まさに目からうろこ。

僕のチームでも「この要求とこの要求どっちが優先なんですか？」という会話が何度も飛び交っている。チケット管理システムに優先度の項目（まさに高中低）はあるけれども事実上使用されていないし、TATの長い大きめの開発作業と日に日に発生する問合せ・作業依頼対応も一緒くたに管理されているので、特にオフショア開発者にとってはどれを優先させて対応すべきか、この要求・タスクはいつまでに完了させなければいけないかが聞かなければ分からない状態なのだ。

これをプロダクトバックログの形でバックログになっている要求・タスクすべてに順番をつけてあげれば、上記のような無駄な確認は不要となるだろう。

とはいえこのすべての（未完了の）要求・タスクに対して順番をつけるというのは手作業だとなかなか難しい。完了したものは除かないといけないし、連番をつけていっても100番と101番の間に差し込みたいものが出てきたら100.5番なんてかっこ悪い番号を付けることになってしまうからだ。

ということでここらへんはシステムの力に頼りたいところ。Redmineでも標準では出来ないので、Redmine dashboardかRedmine backlogを入れて試してみたい。

アジャイル開発とスクラム 顧客・技術・経営をつなぐ協調的ソフトウェア開発マネジメント

アジャイル開発とスクラム 顧客・技術・経営をつなぐ協調的ソフトウェア開発マネジメント

*1:外科手術チームの場合は執刀医と管理者以外にも多くの役割が定義されており、スクラムよりも大規模なチームが想定されていると思われる。

タスク管理におけるリスクの扱い方

今日もちょっと手を抜いてプロジェクト内で作成途中の講義マテリアルのために書いている文を流用。プロマネというより、個々人のタスク管理の話です。

不確実性のあるタスクを先に片付ける

以下の2つのタスクを抱えていて、どちらも期限は今週中だとします。どちらから手を付けますか？

1. 新しく入れる予定のチェックロジックの技術検証。始めて使用する技術で何から手を付けていいか分からない
2. 月次定常作業のデータ変換&投入作業。変換ロジックが複雑なため自動化されていないが、これまでも実施したことがあり手順は確立している。

正解は1から着手すべきです。そして1に割く時間は「今週の作業可能時間 - 2の見積作業時間」に区切ることを厳守して、そこまでに終わらならそうなことが分かった時点でアラートをあげます。これを逆の順序で行ってしまうと、アラートをあげられるのが遅くなってしまいます。

不確実性のあるタスクを先に片付けることで、早いタイミングでアラートをあげることが出来、期限ギリギリ、もしくは過ぎてから遅延報告するという最悪の事態を避けることが出来ます。

これは、当たり前じゃんと思う人がほとんどなのですが、実際にそれに従って動けている人は少ない。「うーん、1はどこから手を付けていいか分からないし、とりあえず2を始めるか」とやってしまうことって多いですよね。

＜不確実性のあるタスク例＞

• SVのレビュー結果によって手戻りが発生する可能性のある（可能性が高い）作業
• 始めての作業で完了までに必要な工数に検討がつかない作業

＜不確実性のない（小さい）タスク例＞

• （たとえ作業時間が長くとも）既に一度実施したことがあり、どのくらいの時間が必要か判明している作業

リスクを低減させるところまでを先に片付ける 

一つ前の応用問題です。以下の2つのタスクを抱えていて、どれも期限は2週間後。前半1週間で何を終わらせますか？

1. 新しく入れる予定のチェックロジックの技術検証
2. 「こんな感じで資料まとめといて」とSVから丸投げされた資料作成
3. 先日ユーザから声の上がった仕様変更の要件定義（要求仕様書作成まで）

正解は1-3を並行して作業し「各作業にどのくらいの時間・工数がかかるか」を見極めるところまでを前半で行うべきです。

＜前半でやるべきこと＞

1. えいやでPGM組んでみてメインストリームの検証
2. たたき台を作ってSVと認識合わせ
3. メール・口頭でユーザと要件概要をすり合わせ

までをやってしまいましょう。

 ＜前半にやるべきでないこと（後半にやるべきこと）＞

1. 例外処理等細かな検証、仕様書や報告書の作成
2. 資料の細かい中身の作り込み、見栄えの調整
3. 要求仕様書の作成

 不確実性のあるタスクを複数抱えているのであれば、1つのタスクに注力せずに、各タスクの「不確実性をなくす」ところまでの作業を先にやってしまうべきです。

※ ただし、自分がマルチタスキングすると極端に効率が落ちる自覚があるのであれば、SVにタスク割り振りを相談することも考えましょう。

リスクを外部化する 

ある月の初旬、ユーザからあるデータの一括更新をしてほしいとの依頼がありました。来月から更新されたデータが必要なので、同月末までにやってほしいとのことですが、まだ更新対象のデータの選定中なのでそのうちに送るそうです。

あなたはこの依頼に対してどのように回答しますか？

正解はデータ受領後に必要な時間を見積もり、いつまでにデータを送ってほしいかをユーザに伝える、です。その際に「XX/XXまでにデータ受領出来ない場合は、今月中に対応出来ない可能性がある」とリスクを共有することが大事です。また、見積時間があいまいな場合は、最悪のケースを想定して最大でかかる時間・工数を採用すべきでしょう。

特に運用保守の現場では「言われたらやるしかない」という状況になりがちですが、上記のような予防線を張っておかないと以下の様な状況に陥ってしまう可能性があります。 

• 当月中にタスクを完了させるために、残業や休日出勤が発生する。
• 当月中にタスクを完了出来なかったことを自社の責任にされる。
• 当月中にタスクが完了出来なかったことによる追加の作業をさらに依頼される。

リスクの管理は進捗・工数と違って（そして品質と似て）定量的に測定しづらいもののため軽視（というよりは見ないふり）されがちです。一方で後々にならないと顕在化しにくく、顕在化した時点では手遅れという可能性があるという意味では可視化しやすい進捗・工数よりも厄介なものですね。そのため、それら以上に意識的に扱う必要がある、と思います。

熊とワルツを - リスクを愉しむプロジェクト管理

熊とワルツを　リスクを愉しむプロジェクト管理