【アジャイル開発】で本当にプロジェクトをマネジメントできるのか？アジャイルの基礎知識と現場での活かし方を解説！
アジャイルって注目されているけどプロジェクトマネジメントにおいて懐疑的な方はこんな悩みをもっていると思います。
- そもそもアジャイルをあまり理解していない
- アジャイルでどうやってプロジェクトを管理するかイメージできない
こんな疑問や不安にお答えしていきます。
今回の記事を読めばこれがわかる！
☑️ アジャイル開発でおさえるべき2つのこと
☑️ アジャイルなプロジェクトマネジメント
この記事を書いている僕はSupreme TechのSM(スクラブマスター）のヒコです。＊土曜の夜は必ずスキンフード (SKINFOOD) ブラックシュガーでスクラブをするのが習慣。これまで10プロジェクト以上でアジャイル開発を経験しています。
そんな僕がアジャイルで本当にプロジェクトをうまく管理できるのか詳しく解説します。
目次
アジャイル開発でおさえるべき2つのこと
僕が実際にアジャイル開発をこの3年やってきて思うことは「アジャイル開発って成長し続ける人生と一緒やな〜」です。変化に柔軟にかつ迅速に考え対応していくこのスタイルは、これまで割ときっちり計画をして進める感じのプロジェクトマネジメントが多かった僕にとって、手法の違いに当初は驚きました。
実際にやってみるのとネットの記事や本で読むのとではまぁまぁギャップがあると感じているので、僕の経験も踏まえてリアルなアジャイル開発についてを解説していきたいと思います。
アジャイル開発とは？
アジャイル開発が注目される理由
世間一般的に言われている理由として、目まぐるしい近年のビジネスの変化に対応できるプロジェクトマネジメントの手法だからだそうです。
これについて実は僕も身をもって感じてます。SupremetechとEnlytを発足してから僕は自社プロダクトの1つである簡単見積もりシュミレーションツールEstimにPO（プロダクトオーナー）としても関わっています。社内や社外で実際に利用してもらったフィードバックや、世の中の需要の変化を考えながら開発すべきことを決めていくとなると、先週必要だったものが今週は必要ないということもたまにあります。そんな早い変化についていくとなるとアジャイル開発くらい柔軟で素早い動きがとれる手法は必要不可欠です。なので注目される理由がよ〜くわかります。
アジャイル開発の手法
アジャイル開発ってのは基本的に反復型です。計画、実装とテスト、レビューといった流れを1週間や2週間単位で繰り返します。僕がこれまでプロジェクトでアジャイル開発で進めようとなったときに採用していたのはアジャイルの代表的な開発手法であるスクラムなので、スクラムを例にして簡単に説明します。
スプリント
スクラムでは短く区切られた期間を「スプリント」と呼んでそれを繰り返します。その区切りの期間は1週間でも2週間でもいいと思います。正直アジャイル初心者のチームだと1週間はキツイと思います。僕らは2年目から1週間のスプリントの扱いになれましたが、当初は開発メンバーからブーイングの嵐でした。1週間が王道みたいなノリがありますが、そこはチームと相談して段階的に進めるのがおすすめです。
プロダクトバックログ
開発したいことはとりあえずプロダクトバックログに入れていきます。思い浮かんだことはとりあえずいれるくらいがちょうど良いと思っています。よく「これって本当にいるの？いらないの？」みたいな議論が早い段階で行われることがあるのですがそれは不毛な議論です。いるかいらないかはその都度その都度変わりますので、とりあえずいれて開発するのが近づいてきたら考えるくらいで良いと思います。極論をいってしまえばいるかいらないかはユーザーが決めることなので、サービスを提供する側の人間がそれについてたっぷり時間をとって話し合ってもあまり意味がないと思ってます。あくまでも僕の意見です。
スプリント・バックログ
優先度の高い要件をスプリント・バックログにいれて開発に着手していきます。ここでよくある失敗が、後ほどしっかりめに説明しますが「完了」の定義が曖昧なことです。スプリント内のゴールが明確でないまま進むことが多々あるので要注意です。
振り返り
これはスプリントの最後にプロジェクト・チームの良かった点、悪かった点を洗い出し、次のスプリントに生かす為の会です。自省をする機会にもなりますし、チームが普段言えなくて溜まっているストレスもここで発散してもらえば良いです。あと悪い面の改善だけでなく、良かったことなどは他のメンバーから言われると嬉しいですよね。それがモチベーションとなってよりよいパフォーマンスも期待できます。なので必ず行いましょう。ただ何十スプリントにもなってくると振り返りに必ず飽きてくるので、KPTやFun/Don/Learnなど振り返り方法を変えて気分展開することをおすすめします。ベトナムのダナンでFun/Done/Learnしてみた。という記事を過去に書いたのでよければ読んでみてください。
アジャイル開発でうまくいくプロジェクトとは
アジャイル開発だからどんなプロジェクトでもうまくいくとは限らず、向き不向きがあります。忘れてはいけないのがアジャイル開発をする上での前提条件です。開発チームはもちろん開発に関わる全てのステークホルダーが受けいれる必要がある条件があります。僕はこの認識が違うだけでプロジェクトが破茶滅茶な状態になった経験は何度もあります。ですからここで最低必要な3つの前提条件を解説します。これらさえ押さえればプロジェクトが100%成功するわけではないですが、これらが押さえられていなければ99%失敗すると思います。ではその3つをみていきましょう。
アジャイル開発を成功させる３つの最低前提条件
1. 不明確性を受け入れる
決まっていないことって怖いですよね。見通しを立てづらい状況をなんとしてでも打破したいその気持ちはわかります。しかし、アジャイル開発が力を発揮するのは、ビジネスと平行して走ってこそです。ですので、不明確な中で何を明確にし何ができるかという発想が重要になってきます。
2. 変化に合わせる
1の不明確性と一緒で、ビジネスの変化に開発も合わせていくことで力を発揮できます。開発中の仕様の大きな変更や削除は当たり前です。計画通りに進めることに固執するのではなく、変化に対して割り切りその都度計画を変更しながらプロジェクトを進めることを頭に入れておく必要があります。
3. 切り捨てることに勇気をもつ
ひとたびほっておくと開発したいことは溢れ返ります。やらないということも選択肢であることを頭に叩き込んでおく必要があります。その中で優先順位を付け、本当にやるべきことのみに注力することが重要です。忘れてはいけないのは「ほしいかほしくないか」は実際のユーザーが決めることです。
アジャイルなプロジェクトマネジメント
ここまででアジャイル開発の特徴は理解できたと思います。もう既にお気づきかもしれませんが、従来のプロジェクトマネジメント手法ではアジャイル開発に対応しきれないことが多少あります。そこでここからは、アジャイルなプロジェクトマネジメントを解説していきたいと思います。
従来のマネジメント手法とアジャイルとの違い
一般的にプロジェクトの初期段階では決定できないことが多く、不確実な点を残したままプロジェクトを進める場合がなくありません。そういった場合、従来のマネジメント手法とアジャイルのマネジメント手法では対応の仕方が異なります。
従来のマネジメント手法 – 中規模開発のケース
僕が50人規模のヘルスケアアプリ開発のプロジェクトマネージャーをしたときは、割と綿密に計画を練って進めるマネジメント手法でした。要件定義の段階で超概算の見積もりを算出、少し要件が仕様になってきたら概算見積もりを算出、この仕様でいきましょうと最終決定したら正規見積もりとして算出といった3段階の見積もりが存在していました。また、開発に着手する前には画面遷移図、画面詳細を作成し、万全な状態にしてから開発を進めて、計画を見直すときは、いかに変更による影響をいかに少なくできるかというアプローチが主流でした。
アジャイルのマネジメント手法 – 小規模開発のケース
僕が10人以下のLINE系のアプリ開発のスクラムマスターをした際は、変更に対して積極的なアプローチを取っていました。というのも毎週やりたい開発の優先度や、仕様の追加と変更は普通だったので。ですので画面遷移図くらいはデザイナーが先回りして作成することはあっても、仕様はスプリント計画の1時間前くらいにGithub上に作成するというのが通常の流れでした。これだけだと煩雑な感じですが、このスピード感と柔軟性を保ちながらチームのパフォーマンスを最大限に引き出すために、計画、設計、実装、テスト、デモの結果のフィードバックといった一連の作業を1週間もしくは2週間の間に実施しうまくプロジェクトをマネジメントしていました。
アジャイルなマネジメントで忘れてはいけないポイント３点
「完了」の定義を決める
余談ですが僕らは「Done」の定義とかとも言ったりします。
この「完了」の定義が決まっているか決まっていないかでプロジェクトの成否を決めると言っても過言ではありません。
過去にあったのが、エンジニアは自分の実装が終わっていたら「完了」と思っていて、テスターは自分のテストが終わったら「完了」と思っていたというケースでした。各スプリントのゴールにズレができ、作りたい機能というのはスプリントの積み重ねですので、最終的に意図したものが完成しないという悲劇がおきました。チームできちんと定義すべきだった「完了」は、「〇〇の開発環境で実装、テスト、不具合修正までが完了してる」で、共通認識を持って進めるべきでした。
このように定義はチームによってことなっても良いのですが、ステークホルダー含むチーム全体で共通認識をもつためにも明文化することはとても重要です。
開発状況は可視化する
各スプリントの最初にストーリーからタスクへのブレイクダウンし、各タスクの見積を行います。ここまで終えれば良いというわけではありません。自分のチームが日々どのタスクを対応し、どれくらいのペースで進めているのかというは見張るわけではありませんが、必ず把握しておきたいところです。そこからチーム前提のベロシティや、見積もりと実際との差分、それらの内訳を分析し、チームの改善につなげたり見込みをたてることができます。僕は直感的にチームの状況がわかるようにGoogleスプレッドシート上でバーンアップチャートを使ったりすることが多いです。
弊社では、ストーリー名、担当者、ステータスなどが明確に管理でき、自動で開始時間なども記載されるような仕組みになっています。こちらもGoogleスプレッドシートでテンプレ化しています。その他にも、チームメンバーの１スプリント内での稼働時間をアサイン率から算出し、スプリント内で対応する工数がその稼働時間を超過していないかなど、スプリント内でのメンバーのタスクと稼働時間の管理を細かく、正確にできるシートとなっています。
以前僕が書いた記事でアジャイル開発のチームビルディングは３つのポイントと２つのコツがあります。ここでアジャイル開発における可視化についても詳しく書いているのでぜひ読んでみてください。
コミュニケーションをデザインする
アジャイル開発におけるマネジメントでは、開発チームのみでなく、開発に関わるステークホルダー全てを含めた自律的なコミュニケーションをとることがとても重要です。自律的とはいってもそこの部分はかなり属人化するところなので、雰囲気だけで乗り切ろうと思っても難しいです。「おれたちアジャイルだもんな！」と言っても、セルフマネジメントが苦手なメンバーや、アジャイル初心者の集まりだとコミュニケーションなんて起きません。
ですので、コミュニケーションが起きやすいような仕組みをつくることが重要です。スクラムを例にしますが、僕が必ず行っているのが毎日同じ時間に短い時間のミーティングを行うデイリースクラムと、週次の頻度でこれまでやこの先の計画を見直すリファインメントミーティングです。そしてそれらに開発に関わるステークホルダー全員も招待しています。そうやって決まった時間に決まった目的をもったミーティングを設けておくことでコミュニケーションを促す機会となります。普段自分からあまりしゃべらないメンバーとかもこういう機会があると意外としゃべってくれて思ってるよりも効果があります。
まとめ
開発のマネジメント手法の情報はネット上に数え切れないほど存在しているため結局どの手法がいいのか迷ってしまいます。しかし、今回こちらの記事でご紹介したアジャイルの特徴、各々の手法に適したプロジェクトのタイプ、アジャイルなプロジェクトマネジメントの具体的な方法を参考にすれば、みなさんにあった手法がみつかると思います。
しかし、ソフトウェア開発のプロジェクトマネジメントは予期せぬことばかり起きます。アジャイル開発も知識だけではどうにもならなず、やってみないとわからないことばかりです。ですので、これから実際にアジャイルでプロジェクトを始めてみる方、実際に開発過程でアジャイルなプロジェクトマネジメントをされている方で、何かお悩みのことがある方はぜひ気軽にお問い合わせからご相談ください。これまでのアジャイル開発、プロジェクトマネジメントの経験から何かお力になれると思います。
Enlytについて
株式会社Enlytはベトナムに開発拠点SupremeTechを持ち、Enlytではこれまで50以上の開発プロジェクトを行ってきました。（ 株式会社Enlytの実績は開発実績ページから）ベトナムと日本のグローバルなチームで、数多くのプロジェクトを成功に導いてきました。
アジャイル開発をご検討の際は、株式会社Enlytまでご気軽にお問合せください！お客様の納得のいくまで、共に開発させていただき、アイデアを最高のかたちにサービス化いたします。
下記ボタンより気軽にお問合せください！
