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

　この記事はアジャイル開発を元に考えるプロジェクトマネージャのあり方18の続きです。前回は、時間管理と見積もり技法について解説しました。今回は、経営資源の内の一つお金とプロジェクトの関係について解説します。
　システムを提供する側にとって、システムを開発する大きな理由は「儲けるため」です。営利企業は商売でシステムを開発しているのですから、プロジェクトが赤字になれば経営者はプロジェクトマネージャの能力に疑問を持つでしょう。ところが、非アジャイルの開発文化では、基本的には納品後に検品され、ある程度時間が経過したら売上になります。つまり、売掛金の期間が長く、回収できない危険性が高くなる傾向があります。また、その間にシステムを開発する側の資金が回らなくなります。
　この問題はビジネスモデルの問題であり、プロジェクトマネージャだけの責任ではありませんが、悲しい事に弱い立場の人間が責任を取らされているのが現実です。日本では特に失敗を考えず成功する事を前提にするので、プロジェクト失敗の根本的原因を考えず、形式的に誰かの頭を下げさしたり、誰かのクビを切ったりする会社が多々存在します。
　問題の根本原因は売掛金の期間が長い事ですから、仕掛品（製造途中の製品のこと）の状態のシステムでも価値を持たせればこの問題は解決します。この点に於いても、アジャイル開発の考え方は参考になります。
　アジャイル開発ではイテレーションと呼ばれる単位で開発を行います。イテレーションとは2週間程度の期間の事であり、この期間内でユーザーストーリーを実現します。そうすれば、お客様は進歩状況が分かりますし、要望とシステムのギャップも埋まります。また、イテレーションを基準とした個別契約を結ぶ事が可能となり、短い期間で売上が上がります。
　非アジャイル開発をしているところでも、スパイラル開発で同様の事を試みる会社もありますが、アジャイル開発とは違い、仕掛品でも動く所に重点が置かれていない（継続的インテグレーションという視点がない）ので、トラブルの原因となっています。
　この点から分かるプロジェクトマネージャの役割とは、仕掛品でも価値がある状態に保つ事です。プロジェクトマネージャと経営資源は切っても切れない関係であり、経営資源の内の一つお金についてもよく考えなくてはなりません。ビジネスモデルの甘さもあり、仕掛品でも価値を持たせるのは大変ですが、利害関係者にプロジェクトがもたらす価値を提示し続けないと、プロジェクト失敗と看做されます。
　マイナスの部分が目立ちますが、だからこそそれが出来れば、貴方のプロジェクトマネージャとしての価値が上がります。もし貴方が、その能力を評価されない会社に勤めているならば、辞めた方が得策なのかもしれません。

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

　この記事はアジャイル開発を元に考えるプロジェクトマネージャのあり方17の続きです。前回は、大切な資源である時間と進歩管理について解説しました。今回は、時間管理と見積もり技法について解説します。
　残念ながら、納期以内にシステムを導入できない失敗プロジェクトが沢山存在します。この手の話題は、根性論で語られる事が多いのですが、私は能力の問題だと考えていません。何故ならば、能力の問題ではなく手法の問題だからです。
　プロジェクト失敗と聞けば、プロジェクト管理者の能力が低かった、開発スタッフの能力が低かった・・・などと能力の問題だと思いがちです。しかしながら、確かに能力不足で失敗したケースもあるかと思いますが、優秀な人やチームでも失敗するケースを多々見てきました。従って、能力の問題だけだと思いこみ従来の方法を変えないと、この見積もり問題は解決しません。手法そのものを見直す必要があります。
　様々な見積もり手法が存在しますが、それらの手法は暗に、未来を予測できる、もしくは仕様が不変である事を前提としています。本当にそうであればよいのですが、情報システムの性質を考えると不可能な条件です。仕様は変化しますし、事前に情報システムの全てを把握できません。
　その原因は、悪質なケースを除けば、お客様の心変わりにあるのではありません。市場そのものが変化するのであって、お客様の態度を失敗の原因にするのは現実逃避に他なりません。昨今のビジネスは変化に柔軟に対応する事が求められており、システムを導入する我々のお客様も苦しんでいるのです。
　システム開発はよく建築と比較され、従来の見積もり技法もその思想が見え隠れしますが、建築と情報システムは違います。情報システムの性質を良く考えなくてはなりません。その答えが、変化を前提とするアジャイル開発の見積もり技法にあります。
　アジャイル開発ではユーザーストーリー単位で見積もります。「システム全体の納期は1年後」というふうに未来予測をするのではなく、「このお客様の要望ならば1週間」というふうに個別に見積もりをします。ただし、お客様の要望が「1年以内にシステム稼働」などといった時間に関する制限がある場合があり得ます。その場合は、現状分析と要求分析をある程度しておく必要がありますので注意して下さい。鍵となるのは変化に対して柔軟かつ迅速な対応する力です。
　纏めとして、今までの内容を踏まえて、プロジェクトマネージャのあり方を書きます。現在のプロジェクトマネージャに求められるのは、変化に対して柔軟かつ迅速に行動する力です。具体的には、交渉能力・決断力・コミュニケーション力の3つが重要な能力だと言えます。これらの能力は、熟練のプロジェクトマネージャが持っている力です。見積もり技法さえ変えれば、従来持っている力を駆使して、難しい時間管理を達成できます。


参考書

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

　この記事はアジャイル開発を元に考えるプロジェクトマネージャのあり方16の続きです。前回は、適切に人的資源が活かされているのか、チェックする方法について解説しました。今回は、大切な資源である時間と進歩管理について解説します。
　数回にわたって、人的資源を活かす方法について解説してきました。これで話しが終われば、プロジェクトマネージメントは簡単なのですが現実はそう甘くありません。私達開発者には「納期」という名の悪魔が付きまといます。
　納期という名の悪魔は、私達開発者を常に苦しめます。数え切れない数の人々が「ああ、もう少し時間があれば」と嘆きます。しかし、死神と同じく納期は絶対の存在です。納期からは逃げられません。
　しかし、プロジェクトマネージャに管理能力があれば、「納期」という名の悪魔を天使に変える事が出来ます。プロジェクトマネージャに必要な能力のうちの一つが時間管理能力なのです。解決方法を導き出すために、時間管理の失敗についての考察から始めます。
　システム開発でよくある失敗の一例が「全ての要望に応えるシステムを納期以内に開発できない」事です。その原因は色々ありますが、お客様の要望が常に変化する事と、開発作業に費やす時間を事前に見積もる方法が存在しない事の2つです。この2つの要因を解決するのが、プロジェクトマネージャの仕事です。

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

　この記事はアジャイル開発を元に考えるプロジェクトマネージャのあり方15の続きです。前回は、「新人でもそれなりに成果が出せる環境」について解説しました。今回は、適切に人的資源が活かされているのか、チェックする方法について解説します。
　前回、従来のマネージメント手法である「細かいところまで管理」する方法は問題が多く、プロジェクトマネージャは細かく仕事を割り当てないで、仕事の割り当てをまかしてしまうのが一番だと説きました。
　もちろんこれは、マネージャが管理を放り投げ、無責任にふるまう事とを推奨しているのではありません。不適切な管理は生産性を下げるからそれを止めるべきだという論旨です。大規模開発に参加した方は十分に体験していると思いますが、管理方法を間違ったプロジェクトは悲惨です。不必要な書類や会議に時間が浪費され、お客様のためになるものが全く生産できません。この状態が続くとデスマーチになります。
　この問題の本質は、管理という手段が目的へと変わり、お客様が望むものが生産されていないところにあります。特に多重請負構造の日本でよく見受けられる現象です。コミュニケーションは重要ですが、あくまでもお客様へ実際に製品を提供する事が大切なのであって、不必要な会議や書類といった生産性に寄与しないコミュニケーションはただのバグです。
　しかしながら、仕事の成果を測る指針が必要なのもまた事実です。ですから、書類を一切排除するといった極端なアジャイル開発もまた弊害となります。必要なのは生産性向上を目的とした管理です。管理者は常に生産性向上を意識せねばなりません。
　従来の報告書といった資料による成果測定法は、書類作成を開発者に強いる点に問題がります。これらの書類は不必要な情報が多く、生産性を向上させる効果もありません。作成するだけ時間の無駄です。本当にプロジェクトマネージャがするべきなのは、開発チームが生産したユーザーストーリの状況を把握する事です。
　具体的には、開発するべきユーザーストーリ、現在実現しているユーザーストーリ、そして個々のユーザーストーリの規模に着目します。それらに目を向けていれば、プロジェクトの状況が把握できます。それに加え、誰がどのユーザーストーリに関わっているのかをチェックしておけば、チーム全体の生産性と個人の生産性を知る糸口になります。
　日本の組織は集団を重んじ、個人の生産性を軽視する傾向がありますが、個人の生産性があってこそチーム全体の生産力につながるので、個人の生産性を軽視してはなりません。
　しかしだからと言って、生産力を計測する事に力を入れ過ぎてコストをかけるのもまた問題です。基本的には、プロジェクトマネージャが記録し、後でそれを検証できるようにします。理想的には、継続的インテグレーションを実現し、それらの情報を元にユーザーストーリの状態を管理できるツールを用意します。そうすれば、不必要にコストを掛けずにプロジェクトの状態を常に把握できます。

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

　この記事はアジャイル開発を元に考えるプロジェクトマネージャのあり方14の続きです。前から引き続き「新人でもそれなりに成果が出せる環境」について解説します。
　新人教育を終えたら、与える仕事をプロジェクトマネージャは熟慮しなくてはなりません。何故ならば、人的資源を最大限に生かすのがプロジェクトマネージャの仕事だからです。ですが、実際にやった事がある人にしかわからないかもしれませんが、適切な仕事を割り振るのは非常に困難です。
　難し過ぎる仕事を新人に与えてしまうとプロジェクトが達成できません。また、何時までも先輩方が手厚く保護するのは大問題です。人は誰しもプロジェクトに貢献しているという実感を求めます。貢献しているという実感がなければ、指示待ち人間になってしまいます。指示待ち人間は、責任感を持って自主的に仕事をしません。指示通りに仕事をこなすだけです。この状態の人が居ればプロジェクトはうまく回りません。
　プロジェクトマネージャの仕事は、人的資源の割り当てだけではありません。他にも時間・資金・情報の各種資源をコントロールせねばなりません。ですから、プロジェクトマネージャは効率よく仕事を捌かなくてはなりません。ですが、指示待ち人間が居ると、プロジェクトマネージャの他の仕事に集中できなくなります。人的資源の割り当てを効率化しなくてはなりません。
　私は様々な方法を考え一つの結論に達しました。それは、そもそも人的資源の割り当てをしないのが最善だという事です。プロジェクトマネージャがあれこれ考えても、人が持つ技術力や知識は多種多様であり、完璧に把握してコントロールする事は不可能です。仕事ができないと思われた人が、ある局面に於いては一番仕事が出来るという事は珍しくありません。その逆もまたしかりです。おまけに、情報処理技術は日進月歩であり、技術者のスキルセットもまた日々変化します。それをリアルタイムに把握し続けるのは不可能なのです。特に他社がプロジェクトに参加する場合、誤情報の可能性も視野に入れると、完璧に把握する方法はありません。
　プロジェクトマネージャが個々の人間を知りつくす事は不可能ですが、誰がどういった能力を持っているのかは、現場の人間と本人が一番知っています。ですから、プロジェクトマネージャは細かく仕事を割り当てないで、仕事の割り当てをまかしてしまうのが一番です。そうすればたとえ新人でも自分がやれる範囲で仕事を頑張っているという実感が得られ指示待ち人間になりません。
　しかしだからと言って完全に人任せにしてはなりません。プロジェクトマネージャは仕事の進行度をよく観察し、適切な仕事がなされているのかを判断せねばなりません。特定の人に仕事が集中していないか、全員が仕事をしているのか、手を抜いていないか・・・など、人的資源が最大限に活かされていのかを継続的にチェックしましょう。

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

　この記事は、アジャイル開発を元に考えるプロジェクトマネージャのあり方13の続きです。前回は、プロジェクトマネージャが果たすべき役割を具体的に解説をしました。今回はその続きである、「新人でもそれなりに成果が出せる環境」について解説します。
　前回の記事にて「新人でもそれなりに成果が出せる環境」が大事であり、人員の流動が激しいプロジェクトでも生産性を上げる事が大事だと述べました。これからそれを可能にするにはどうすればよいのかを解説します。
　誰しも新人の頃は仕事の要領が分からず戸惑います。プロジェクトマネージャは、新人が戸惑わない仕組みを考える必要があります。プロジェクトマネージャは新人に対し、どの仕事をどのようにすればよいのかを, 具体的に指示出来なくてはなりません。ただ単に教育担当者を決め、その人に任せてしまうだけでは上手くいきません。
　担当者任せにしてしまうと、その担当者は方針が分からず困ってしまいます。さらに方針が分からない状態では、非効率的な指導方法にならざるをえませんので、担当者の生産性も落ちてしまいます。担当者の生産性を下げずに、新人でも生産できる環境をあらかじめ熟慮して決めなくてはなりません。その環境は会社に依存し、全ての会社に適用できる方法は存在しませんが、原則を述べる事は出来ます。
　基礎知識がない状態の新人を、プロジェクトに参加させないのが基本原則です。基礎知識は果たすべき役割によって異なりますが、ひとまず実装工程を元に解説を進めます。
　プログラミング言語の文法、開発ツールの使い方、仕様書や設計書の読み方、プロジェクトに関する知識、コミュニケーションの取り方は必須です。これらの基礎能力がない状態の新人をプロジェクトに参加させると、開発生産性が非常に落ちます。新人教育を効率よく行う手順および、知識の確認体制をあらかじめ熟慮しなくてはなりません。
　また、役割に関係なく新人に対して、セキュリティに関する教育もするべきです。クラッカーが新人に対して、ソーシャルエンジニアリングの手法によるクラック行為を行う可能性があります。強いコンピュータの権限を持ちがちな新人開発者は、特に目を付けられやすいので注意せねばなりません。

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

　この記事はアジャイル開発を元に考えるプロジェクトマネージャのあり方12の続きです。前回はマネージャの管理方法について解説しました。今回はより具体的に、プロジェクトマネージャが果たすべき役割を解説をします。
　プロジェクトマネージャがするべき事は、精神面および物理面から職場の環境を整え、お客様の要望を叶える事です。開発メンバーに自己管理をさせているからと言って、その間何もしなくてもよいという事ではありません。プロジェクトマネージャは常に仕事を抱えています。
　システム開発でよくある失敗は、開発者達の職場環境を軽視し、期待していた成果が出ないと叱責する事です。システム開発は、どの工程も高度な創造性を必要とするクリエイティブな仕事です。環境を整えないと仕事の成果は望めません。一時的には開発メンバーに鞭を打ち、残業をさせて無理やり補う事は出来ますが、本来クリエイティブな仕事なのでそれは長続きしません。人を犠牲にする根性論は長続きしません。
　人を叱責する前に、プロジェクトマネージャは職場環境を整え、新人でもそれなりに成果が出せる環境を構築しなくてはなりません。大概のプロジェクトは、全員がプロフェッショナルな人材だという事はありません。毎年新入社員は入ってきますし、途中でメンバーが抜けたり、新しいメンバーが追加される事が頻繁にあります。それら人材を最大限に生かすのもプロジェクトマネージャの仕事です。
　

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

　この記事は、アジャイル開発を元に考えるプロジェクトマネージャのあり方11の続きです。前回はマネージャがどうやって管理するのかについて解説しました。今回も引き続きマネージャの管理方法について解説します。
　前回私はマネージャが管理するべきものは結果だと書きました。日本ではよくこの部分が拡大解釈され、「マネージャは情報処理技術を知らなくてもよい」という間違った考えになってしまいます。もちろんそれは違います。何故ならば、マネージャが情報処理技術を知らないと、結果を正確にチェックできないからです。情報処理技術を知らない人間が、情報処理技術の産物である結果を理解できるはずがありません。もしそれが可能ならば、エンドユーザーがマネージメントをすればよい話しになります。それが出来ないのですから、情報処理技術を知らない人間が結果を管理できないのは自明の理だと言えます。
　開発者が出した結果を判定するのは技術力が要ります。開発者が間違っている場合、プログラミングが達者でないとマネージャは見抜けません。しかしだからと言ってプログラミングだけに通じていても駄目です。仕様や設計が間違っているケースも多々あります。仕様や設計が間違っているのにもかかわらず、担当したプログラマを責めると人望は失われますし、本当の間違いが見過ごされてしまいます。マネージャは情報処理技術全般に通じていなくてはなりません。
　それに加えて、マネージャはプロジェクトの背景知識も持たなくてはなりません。システム開発は作るべきものを詳細に理解してないと失敗します。情報処理技術に通じているからと言って、他業種のお客様にとってよいシステムを作れません。システムはお客様にとって心地よいものでなくてはなりません。
　しかしながらマネージャも人間です。情報処理技術の全てを極め、エンドユーザーの業務知識も熟知しているということはありえません。その理想を追い求める姿勢は大事ですが、現実を直視せねばなりません。マネージャは知らないものは知らないと認める度量がなくてはなりません。マネージャは人間性に優れ、人望がないと駄目だという事です。続く...

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

　この記事は、アジャイル開発を元に考えるプロジェクトマネージャのあり方10の続きです。前回は開発者の自己管理について解説しました。今回はマネージャがどうやって管理するのかについて解説します。
　前回の最後に、個人の仕事の細部まで管理する必要はないと書きました。ただし、全く管理する必要がないという事ではありません。細かい単位ではなく、より大きな視点に基づき管理をせねばなりません。管理のスコープを変える必要があるのです。
　従来の管理技法は、個人体で割り当てる仕事とその成果を管理していました。それは、ウォターフォール開発モデルに従い、個々の人が「プログラマはプログラミング以外の事は考えるな」酷い時には「2千行コーディングしろ」などといった細かい単位で仕事をしていたから成り立った事です。しかしながら、アジャイル開発ではその様な細かい単位で仕事をしません。それに加え、その様な細かい単位の管理は作業を煩雑化するだけで生産効率を上げません。ですから、その様な細かい単位の管理は時代遅れだと言っても過言ではありません。
　管理のスコープを広げ過ぎると、管理者が非常に有能な場合に限り品質をあげる事が出来ます。しかしながら、管理者の負担が増し、管理コストにより迅速な開発が出来なくなります。おまけに、管理される側が成長する機会を潰してしまいます。何故ならば、管理される側は、管理される事に慣れきり、自己管理がおざなりになるからです。日本ではそんな開発者が歳をとった後で、プロジェクトマネージャにするのですから上手くいくはずがありません。歳だけとった自己管理能力が低い開発者は優れたプロジェクトマネージャになれません。従って将来の事も見越し、個人に自己管理をさせるのがベストだと言えます。
　プロジェクトマネージャが管理するものは、個人が自己管理の結果生産した結果です。過程はあまり管理する必要がありません。それどころか、管理しない方がよいと言っても過言ではありません。技術者はきつく管理されると、最適なパフォーマンスを発揮できません。技術者は放任するぐらいが丁度いいのです。
　日本の管理方法は管理のための管理になりがちで、書類を提出させて満足している節がありました。いわゆる官僚的になっていると言えるでしょう。しかしこれは本末転倒です。本来管理管理とは、生産能力を上げる為に行うものであり、無駄な書類を作ったり、無駄な会議をして時間を潰すためのものではありません。管理は個人の力を最大限に発揮させ、集団作業で発生するコストを軽減する為に尽力しなくてはなりません。続く...

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

　この記事は、アジャイル開発を元に考えるプロジェクトマネージャのあり方9の続きです。前回は人員の管理について解説しました。今回は開発者の自己管理について解説します。
　ウォターフォール開発モデルなどの従来の開発方法論は、「設計通りに実装しろ」というふうに、上流工程から仕事を振られる形で開発が進められていました。しかし、アジャイル開発はそうではありません。分析や設計と言った行為は行いますが、あらかじめ定められたプロセスを硬直した形で行いません。開発者は短い期間で動くものを求められます。
　アジャイル開発は、チームを重要視する姿勢が目立ちますが、個人もまた重要視されています。何故ならば、アジャイル開発は顧客やチーム間での「信頼」を大事にするからです。個々の開発者が宣言した期間内で目標が達成出来ないと、信頼を失うのは明白です。また、責任感がない人を信頼する人はいません。
　従って、アジャイル開発でのチームの重視は、開発者個人の重視も意味します。さらに、アジャイル開発はプロセスをシンプルにし、作業を細かく分けて開発を進めるので、従来よりも活発に開発作業をせざるを得なくなります。ウォターフォール開発モデルとは違い、短期間で動く／動かないという形で仕事の成否がはっきり出されますので、開発チームは責任を曖昧にし難くなります。チームの責任がはっきりすると、個人もまた責任感を感じざるをえません。
　そういった事から、開発者個人も自己管理を余儀なくされます。以前のように仕事が上流から降ってくるのではなく、主体的に開発作業を進めるアジャイル開発は、プロジェクトマネージャの負担を減らします。従来のように、個人の仕事の細部まで管理する必要はありません。続く...