はじめに
ソフトウェアの開発プロセスはそれだけで学問が出来上るほど重要であり、それらを知識として持つことはITエンジニアには必須です。ただし、現実のプロジェクトではなかなかその知識の通りにはならない。。。。
本投稿では「プロジェクトマネジメント効率化」と「アウトプットの完成度を高める」ことを目的に僕がプロジェクトマネージャーとして試行錯誤してきて感じたことを紹介します。その中で使い始めた AzureDevOpsが使いやすかったので、それを使う前提に紹介します。
基本的に AzureDevOps はアジャイル開発を対象としたサービスです。本当はキチンとしたアジャイル開発やプロトタイプ開発をしてみたかったのですが、諸事情等もありそれは出来ませんでした。そのため、「基本的にはウォーターフォール開発だけどアジャイル開発のエッセンスを取り入れた開発プロセス」を目指して試行錯誤することにしました。
諸事情
- 契約形態/開発費用/スケジュールの問題
- 学習コストや管理コストの問題
- 今までウォーターフォール開発でやってたメンバばかりだし・・・
・・・etc.
なぜ、AzureDevOpsなのか
個人的に「プロジェクトマネジメント効率化」と「アウトプットの完成度を高める」ために重要なことは特に下記の3つだと思っています。
- その1 メンバ間でPJの情報を共有し、客観視できること
- その2 ドキュメントやソースが過不足なくまとめられていること
- その3 システム発注元や仕様の意思決定者に開発状況が分かる様にPJを進めること
AzureDevOpの機能を使うと上記を実現し易くなりました。
- Wikiを使ったドキュメントの一括管理
- PJの体制図や設計書まで、全てMarkdown形式で作成・管理できます。
⇨ ドキュメントのフォーマットを合わせるのがめっちゃ楽！印刷とかも楽！ -
mermaidを利用して図形も書けます。
⇨ 図形の統一感もでます！IT系の設計書の図形の9割はこれで書けます。 - ブラウザのみでドキュメントの作成・管理・閲覧・検索が出来ます。
⇨ ファイルを開いて、「あれ？欲しい情報どこ？最新はどれ？」みたいな無駄がなくなる！ - Bordsを利用した作業/課題の可視化
- カンバンボードを使って、タスク管理や課題管理が出来ます。
⇨ PJの状況を定量的に説明しやすくなる！ - Repos/Pipelinesを利用したソース管理
- gitでバージョン管理ができます。
⇨ コードレビューとかもこの中で出来ちゃう！ - Pipelinesを使ってgitにプッシュされたソースをAzureのサービスに自動デプロイ出来ます。
⇨ プロトタイプ開発する時とかめっちゃ楽！ - これらの機能をMSアカウントで管理
- ユーザごとの権限割り振りとかも簡単に出来ます。
⇨ 例えば、発注元の担当者に設計書を公開する、みたいなことができる！
⇨ 特定のPJメンバごとにgitブランチの権限与えるとかも簡単に出来る！
もちろんこれ以外にも便利な機能はたくさんありますが、これだけでもかなり便利。
特に、「設計はエクセル、バージョン管理はGit、課題管理は別のサービス」のようにPJの遂行に別々のツールを使うこともあると思いますが、それが一元化されるだけでもかなりの効率化になると思います。
個人的にはAzureDevOps使っていない他のPJで、”エクセルを開いて「あれ？欲しい情報どこ？最新はどれ？」”的なことがあった時点で、もうモチベーションガタ落ちになります。。。。もう、そんな管理には戻れない（笑）
ちなみに上記3つの項目のうち、特にその3が、個人的に超重要だと思っています。システム発注元や仕様の意思決定者は非IT系であることも多いです。そういう方たちも分かる様に「現在このPJではどういう思想でどういったモノを作っているんですよ～」と常に説明できれば、問題が起きたときのフォローも得やすいですし、仕様変更による後戻り作業も減らせます。また、もともと非IT系の方を意識してPJの状況を整理していれば、開発メンバ内で多少のスキル差があってもスムーズにPJを遂行できます。
本投稿の対象となるPJ
- 新規開発する中小規模の開発PJ （PJメンバが ～10数人程度くらい？）
- WEBを中心とした業務システムの開発（IoTやスマホアプリ絡みでも可）
- 自社サービスの様に継続的に開発するシステムだとさらに相性良さそう
あくまで僕が実践した対象が上記の様なものだったってだけなので、他の形態のPJでも使えるかもです。
AzureDevOpsを使う時のポイント
ドキュメントは全部Wikiにまとめる
こんな感じで書いていきます。
wikiでまとめる意味
ドキュメントをwikiでまとめる利点は先述の通り、サクッと情報をみる事ができる点です。
特に、「PJの目的と目標」とか「体制」等のチームでPJを進めるための根幹となる情報をサクッと見られるようにするだけでも意味があると思います。
個人的にこれらの情報はPJメンバ全員が体に叩き込むレベルで理解している必要があると思います。しかし、それぞれをエクセルとかで別ファイルとして作ってしまうとファイルを開くのが面倒で中身を確認するのはPJがスタートするキックオフミーティングの時だけでいつのまにかみんなの意識がずれている、みたいな状況になりかねません。
一方、Wikiにこれらの情報を書いていれば、定例ミーティングの際にさっと確認したり、別のドキュメントを作成する時に "間違って" 見てしまうこともあります。そのため、このような重要な情報をPJメンバの頭に留めておける可能性がより高くなります。この小さな意識の差が後々のPJの成果に大きく影響するような気がしています。
アジャイルっぽくスケジュールする
大枠のスケジュールはガントチャートで記載する
スケジュールを明記します。なんだかんだ大枠なスケジュールはガントチャートを利用した方が見やすいです。それもmermaid を利用して書くことができます。
大枠スケジュールはガントチャート、細かいスケジュールはカンバンボードって感じで管理するのが効率良いと思います。
イテレーションをうまく使う
AzureDevOｐｓの管理方式に「Agile」を選ぶと、「Iteration(イテレーション)」というものを定義できます。本来なら、アジャイル開発を行う際の小さな開発のサイクルを表すのですが、上記諸事情を考慮して、ウォーターフォール型の工程をそのままイテレーションに当てはめてしまいます。
こうする事でカンバンボードで各工程ごとにタスクや課題を分けて管理する事が出来ます。
後々仕様決定の理由とかを調べたりする時にも便利です。
後述しますが、タスクや課題をこのイテレーションごとに管理する事が出来ます。
また、ウォーターフォール開発でも、上記のように工程の中に明示的にプロトタイプ開発を繰り返し行う形でスケジュールしてしまうのもめっちゃアリだと思います。
プロトタイプ開発の部分のみをアジャイル開発のようにいくつかのイテレーションで繰り返し行うだけでも後々の仕様変更や後戻り作業がかなり少なくなります。
カンバンボードを使ってタスクや課題の管理をする
ユーザーストーリーごとにタスクを管理する
一般的なアジャイル開発でのユーザーストーリーは「要件」に近いイメージですが、僕はいくつかのタスクをまとめる単位として使っています。
例えば、下記のように要件定義工程の中で「〇〇機能の要件定義をする」というユーザストーリーを作ってその中で必要なタスクを記載していくイメージです。
このカンバンボードは全工程を通して見る事も出来ますし、各工程ごとに見る事も出来ます。
ユーザーストーリーの詳細を確認するとこのように、リレーション(紐付け)された子要素としてタスクを管理出来ます。
ユーザーストーリーやタスクに紐づける形で課題を管理する
各ユーザーストーリーやタスクは自由にリレーションさせることが出来ます。
このようにユーザーストーリーやタスクに紐づけて課題(Ｉｓｓｕｅ)やバグを登録出来ます。
「□□機能の要件定義をする」というユーザーストーリーに
- 「YYという機能の概要図に不備あり」というバグ
- 「XXという機能の仕様が不明確」という課題
があり、それぞれアクティブ(継続中)の状態である事が一目でわかります。
もちろんそれらを一覧表示したり、条件を絞って検索したり出来ます。
エクセル管理のWBS等でも作業の管理や課題の管理は出来ますが、それぞれの関連性を表すのが結構大変です。
上記の機能を使うと簡単にリレーションで関連性を表す事ができるので、プロジェクトの状況を感覚的に理解出来ます。
ソース管理はGitで
Gitのリモートリポジトリとして普通に使えます。
また、上記のタスクやユーザーストーリー、Issue、バグとGitの更新履歴をリレーションすることもできるので、どういう理由でソースを変更したのかも後から追い易くなります。
バグを新たに登録して対象となったコミットをリレーションするとこんな感じ。
Azureとの連携を最大限利用する
細かいところは公式ドキュメント等をみていただければと思いますが、Gitにプッシュしたコードをビルドして、自動的にデプロイしたり出来ます。
プロトタイプを開発している時とか、頻繁にデプロイ作業が発生したりする場合にめっちゃ便利です。
ちなみに、ASP.NETやPHPなどのWEBフレームワークを Azure AppService にデプロイする場合は AzureDevOps 側の設定なしで AppService側 の設定のみで自動デプロイが行えます。
例えば、WEB開発の場合、HTMLなどでプロトタイプ開発を行う場合があると思いますが、GitにプッシュされたHTMLが常に AzureのWEBサーバにデプロイされている状況を作ってしまえば誰でも簡単に最新のイメージを確認できるようになります。
さいごに
上記をポイントを意識する事で「プロジェクトマネジメント効率化」と「アウトプットの完成度を高める」という点についてかなり改善してきたように思います。これ以外にもここに書ききれていない機能やサービスは山ほどあるので、それらをもっとうまく使いこなせれば、更なる効率化が図れるかと思います。
個人的はAzureDevOpsのようなサービスを使ったプロジェクトマネジメントの概念や手法がもっと一般化していければ良いのにな〜と思います。
開発環境やシステム環境はどんどん進化しているのに、多くの現場ではプロジェクトマネジメント対する考え方はずっと昔から変わっていない様に感じます。さらに、現場でもプロジェクトマネジメントや開発手法に関する議論は圧倒的に少ないと思います。実際、そういったお話よりもゴリゴリ開発していく方がどう考えても楽しいからなんだろうなと思いますが。。。。。
ただ、当たり前ですがプロジェクトマネジメントや開発プロセスの方針によってプロジェクトの明暗が大きく分かれるので、もっと活発に議論すべき内容であると考えます。
取り急ぎ僕は今後も試行錯誤をしていきたいと思います。