はじめに
筆者は、金融会社でのシステムエンジニアからエンジニア人生が始まり、2000年からはWeb業界にて5回ほど転職をしてきました。そこでは、自社サービスの立ち上げや業務委託でのシステム開発やR&D（Research and Development）業務やその支援、そしてITプロジェクトにおいてトラブルが生じた場合の問題解決支援などを行ってきました。
数名の小さいチームから大手企業の数十名のチームまでさまざまあり、その度にプロジェクト管理の難しさやチーム運営の難しさなどを痛感してきました。本稿は、そのような筆者の経験をもとに、アジャイル開発の課題点や気がついたことなどを紹介するものです。
本稿の対象読者
本稿は、アジャイル開発管理手法を理想的に機能させるための手法であったり、ノウハウを示すものではありません。むしろ、アジャイル開発の文化を導入できない、または、実際試してみたけど、自分達の組織やチームには導入は難しいという判断に至った方向けです。
筆者もさまざまなプロジェクト管理や開発モデルを勉強してみましたが、どうしても、自分のチームにぴったりとあてはまると感じた手法がないと感じていました。
しかし、自分なりに工夫しチームやプロジェクトを回し、ある程度、効果がある共通項の知識や経験がたまってきてから、再度、プロジェクト管理や開発モデルの手法を知ると、本質的には似たことをやっていることに気がつきます。
そして、部分的にでも導入していけるノウハウがあると感じ、それらは、トップダウンではむしろやりにくく、現場からボトムアップだからこそできることも多々あると思っています。
本連載では、さまざまなチームやプロジェクトにおいてプロジェクト管理手法や開発モデルを適用してきた経験から、現場からボトムアップによって、組織にあったアジャイル開発管理手法を取り入れていく方法を解説します。
アジャイルモデルの開発管理手法を取り入れたい理由
アジャイル開発管理手法を取り入れたい理由には、さまざまなものがあると思います。例えば、以下のような理由が挙げられます。
- 自分の組織にあったプロジェクト管理をしたい
- 機能別組織の垣根を取り払ってプロジェクトに取り組んでもらいたい
- 顧客のニーズを素早く反映し、短いサイクルの開発体制を作りたい
- 混沌化している現状を整理したい
1、2のような理由の場合では、トップダウンでの導入が多いこともあり、アジャイルモデルが示す環境や人員、役割等の前提を整えてから手法を取り入れることが可能です。つまり、形式的な側面から入ることもより容易になると思います。
しかし、3、4のようなニーズの場合、必ずしもアジャイルモデルに適した前提でプロジェクトがないことや、チーム組織の構造も現場ではどうしようもないことが多々あります。
そのようなケースで課題があっても、どこから、または何から手をつければよいのか分からなくなりがちです。
本連載の前編となる今回は、プロジェクトの環境や目的という大きなマクロ的視点から、アジャイルを取り入れる際の課題を紹介したいと思います。
現場で感じた違和感
プロジェクト管理などを勉強してみて最初に感じたのは、教科書的な「条件」や「べき論」と、自分が置かれている条件が全く異なっていて参考にならないと感じた点です。本来、プロジェクト管理とは、図1のように課題を解決するための手法の1つに過ぎません。
しかし、当初は、図2のように、開発管理手法を決めると、自ずと問題が解決するかのように考えていました。
アジャイルという言葉が世の中に出てきた2001年頃、ネットビジネス自体が爆発的に広がり、多くのITプロジェクトの失敗事例とともにさまざまなフレームワークが普及しました。このような理由から、アジャイルという考え方、もしくは姿勢のようなものが、具体的なフレームワークソリューションと結びついて、具体的な手法の1つとアジャイルを結びつけて考える流れができてしまったという背景もあると思います。
もちろん、課題や原因を一切考えないわけではありませんが、自分が意識してもいない課題や問題などが自動的に解決されると感じてしまっていた一面があることは否めません。
実際、多くの管理手法モデルは、図3のように代表的な「課題」「原因」「行動」の一例を示しながら、管理方法の考え方を示しています。そのため、多くの人が理解を深めるために、その代表的な「課題」「原因」「行動」を中心に想定して物事を見るようになりがちです。特に、自分がまだ気がついていない課題である場合には、そこで示す、その後の行動をすることで、その見えない課題を解決できていると思いがちです。
つまり、見えない課題、見えない原因を回避するために、なんらかの行動を選択しなければならないという思考から、どの管理モデルの行動（管理ルールを含む）を選択すればよいのかという思考に陥りやすくなります。それでは、管理モデルの説明が、自分にとっては図4のように手法を排他的に選択しなければいけないように感じてしまうことでしょう。
しかし、実際にはあくまで手法は解決方法の1つであり、図5のようにそれぞれの手法の中から自分にあったものや、そのときの条件にあったものを選択すれば良いだけだったのです。
ただし、このように自由に選択したとしても、実際にプロジェクトを進めていくと、効率化や単純化がしたくなるため、図6のようにある手法に偏った選択をするようになってきます。または、ある手法に偏るように、自然と考え方や組織の構成を変えていきます。
このようになれば、最初は自分にとって「条件が異なっている」と思っていたものが、実は、本来の手法の「派生」や「応用」に見えてくるようになるわけです。そもそもアジャイル手法やウォーターフォール手法といった管理手法もこのような行程を経て、カテゴライズされたという、ごくあたりまえのことに気がつく方もいるはずです。
