開発現場は常にトラブルと隣り合わせ

みなさん、こんにちは。自分は2001年頃にアジャイルプロセスに出会ってからさまざまなプロジェクトでアジャイル開発を実践してきました。はじめの頃はそれぞれのプラクティスを闇雲に実施した時期もあります。プラクティス自体は期待通りであったり満足にいかなかったりとさまざまでしたが、ほとんどのプロジェクトは良好な結果を残すことができました。

たまたまではありますが、自分は20年以上も中規模のシステム開発プロジェクトのリーダーを務めることが多く、現在においても現場で開発リーダーとして日々働いています。大抵の方は、それだけの年月を同じような規模で同じリーダーという役割を続けることはまれなんじゃないかなと思います。そういう意味ではシステム開発の現場をかなり良く知っている方ではないかと思います。

そのため、多くの開発リーダーの方々が直面している問題には自分も何度もぶつかってきており、その都度なんらかの解決をしてきました。現場に長くいる方なら分かると思いますが、トラブルは常にそれぞれの現場で発生しており、それぞれの原因や効果的な対策は必ずしも一筋縄ではいかないものです。以前はアジャイルプロセスである程度解決できると思っていた時期もありましたが、それだけでは解決できない現実もわかってきました。

アジャイル適用の現場では

最近またスクラムを中心とするアジャイルプロセスが脚光を浴びているような気もしますが、座学や理論が先行しているようにも感じます。また、たまたまうまく言った事例を提示されているだけで、その周りには多数の失敗事例もあるように思います。つまり、同じやり方でも成功するかしないかはその時々の状況によるのではないだろうかということです。

ではどうしたらよいかというと、自分の長いプロジェクトリーダー経験から言えることは、その都度問題を確認し、その都度最適な手法で対応していく必要があるということです。同じような状況のプロジェクトでもそれぞれ対策方法が違うのではないかということです。人間というアナログな存在が関わることで、どのプロジェクトも同じようにはいかないものです。もちろん何の対策もなく、方針も決定せずプロジェクトを進めることはできません。ある程度の指針は立てるべきです。そこにアジャイルプロセスを摘要するのは良いのですが、それを守ることが必ずしも成功への近道となるわけではないということなのです。

引き出しを増やそう

では結局なんの対策もなく、問題が起きるのを待てばよいのかというとそうではありません。問題の傾向はある程度似通っていますし、同じような対策で効果が得られる場合も多いと思います。ただ対策方法がたくさん入っている引き出しを持っていれば、その時々に最適な対策を引き出しから取り出すことができます。その引き出しに入っている対策方法が少なかったり、一般的な対策方法だけだとどうしても選択肢が限られ、本当に最適な対策がその時点で実施できない可能性が高まってしまいます。

たとえば、プロジェクトで問題が起きた時に、アジャイル手法を知っているリーダーと知らないリーダーがいた場合は、やはり知っていることが多いほうがよりプロジェクトを成功に導ける可能性が高いはずです。もちろん最適解はアジャイルを適用しない方法かも知れません。が知らないよりは知っている方が選択肢が増え、効果的な手法を実施できる可能性は高いはずです。

まとめ

これからお伝えしていく内容は、「現場から届けるアジャイル開発」としていますが、実は特にアジャイルに特化しているわけではありません。すでに自分の中ではアジャイルという言葉では表せない独自の手法をたくさん持っている気がしています。特に、自分がリーダーを担当するプロジェクトでの成功事例などから、あまり他のプロジェクトでは見かけない手法を中心にこれから開発手法などをご紹介できたらと思います。

ほとんどのプロジェクトでも、「ドキュメントが整備されていない」という問題が起きていると思います。どうしたらドキュメントを満足いくレベルに書き上げることができるでしょう。次回は自分の経験から常にドキュメントを最新に保つことのできる管理方法についてお伝えします。

執筆者紹介

川上文夫

1962年5月2日生まれ。パッケージベンダーのグループマネージャーとして複数プロジェクトのPM、PLを兼務。要件定義からプログラミング、テスト、運用を担当している。数多くのプロジェクトのリーダーとして20年のキャリアがあり、オフショア開発の経験も豊富。独自プラクティスに軽量議事録、朝会Wiki、設計実装並列手法などがある。アジャイル系コミュニティにも所属し、記事の執筆やワークショップ登壇など精力的に活動を続けている。