エンジニア自身がテーラリングに参加することがチームの状況を適切に把握するための近道
ウォーターフォール型のシステム開発手法は、極論を言えば労働集約型の特性を持っているプロジェクトに適用するのが適切です。一方、プロジェクトの要件が曖昧であったり、市場の反応を捉えながら要件を変えていく要件を持っているのであればアジャイル開発の手法の中から選択するのが適切です。
さて、どちらの場合でも共通的に起きることがチームの状況を適切に把握できるかという観点です。この観点に対し、前述した2つの開発手法はどのような性質を持っているかを知った上で、さらに、いくつかの切り口を与えるとどうなるかを考えてみることにします。
チームの状況の適切な把握について
上述したとおり、ウォーターフォールは労働集約型のシステム開発に向く特性を持っています。それは局面を区切り、要件から局面毎に実現仕様を詳細化することで部品の仕様を決定し、製造工程で一度に生産し、試験工程で品質検証を行うという、スコープ確定型の製造システムだからです。
この製造システムは局面毎に作業か確定しているため、機能分担では単機能となるのでリソースの割り当てでは単機能工を手当てすることが可能となります。組織構造的には、プロジェクトマネージャやサブシステムリーダと単機能工の組み合わせとなります。
プロジェクト上でのチームの状況把握は労働集約型であること、プロジェクトは単機能工からの情報吸い上げの形態になるので縦割りや作業範囲のみしか情報を持っていないという情報の分断化についてもプロジェクトの性質として潜在的に持っていることになります。
これを踏まえて、プロジェクトチームの状況を適切に把握することはとても労力がかかることは想定されることです。
アジャイル型システム開発は、顧客やそれに相当するPOが要件を提示することができない、または、作り、マーケットにリリースすることで得られるKPIの数字をみながら模索したいという要件を具体化しながらシステムを開発したいという性質に向いています。
やはり、システム開発手法としての特性に短期間の開発を繰り返し、都度、リリースするという考え方にマッチするからです。この短期間で開発を繰り返すという性質を生かすためには、同じメンバで、同じ場所でとコンテキストの高い状態を作り上げることが必要です。同じメンバではもちろんですが、同じ場所でチームが揃うことができない場合は、同程度のレベルの情報共有ができる手段で代替することと、代替する手段をチームの行動様式の中に組み込むことが必要です。
状況を把握するための可視化について
メンバが置かれている、若しくは、メンバ自身が自ら置いているプロジェクトでの状況は、何かしら外部にある手段を使わなければ他のメンバに伝えることはできません。
炎上するプロジェクトでは、こうした基本的なことを後回しにして炎上してから朝会やホワイトボードによる情報共有を始めます。最初からやっていれば炎上もボヤ程度にすむはずですが。
情報を伝達する手段はデジタルならチケット管理システムが代表でしょう。アナログであれば、付箋紙やホワイトボードに直書きです。
これらの情報共有のデジタルとアナログも別の切り口、例えば、リモート開発のメンバがいるとか、オフショアニアショアを使うとなるとデジタルとアナログの特性はメリットデメリットが出てくるのは容易に想像できることです。
重要なことは、プロジェクトの特性を踏まえた上で、チームの活動を制限する制約事項を捉えてから情報共有の仕組みを選択することです。
つまり、闇雲にチケット管理システムがいいとは言い切れない、ということです。
さらにチームのコンテキストの高低のレベルや適用するシステム開発手法の習熟度により、選択できる手段が制限されることを理解しておく必要があります。
メンバの意識について
適用するシステム開発手法により、メンバがどれだけ意識的に行動できるかの差が出るのであれば、それは採用するリソースとして不適切であると言いたいところですがエンジニアの意識は個々に依存するためそれは踏まえた上で、どのようにチームとしての意識的な行動や判断基準を揃えるかという観点に絞ると、少し捉え方が変わってきます。
メンバの意識がクローズアップされるのは、チームとしてというよりはプロジェクトマネージャとしてのプロジェクト運営の指針に対してどれだけメンバが方向性と適合しているかどうかということができます。
採用するシステム開発手法に対してメンバの慣れ不慣れはプロジェクトマネージャの運営指針とずれやすいもので、そうした状態でもチームとして一定の行動様式をさせる必要から、何かしらの対策が必要となります。
それが作業のプロシージャの可視化と実績の可視化なのです。
- チームの状況の把握＝共有
- 行動様式の統一
- コンテキストの底上げ
- 成果の可視化
- 言葉の統一
おまけ
実際、チームに慣れないシステム開発手法で開発をしてもらう必要があったり、無意識に隠蔽されてしまうメンバが持つ情報を可視化するのであればこのスライドの対策は1つの実例として適当でしょう。
コメントに若干局所的にネガティブなコメントがついていますが、これまで述べたことの制約事項を踏まえて自らテーラリングすることを忘れているのではないかと思うのです。
そのテーラリングはエンジニア自身が行う範疇なのですから。自らしようと行動しないのは単なるオペレータです。
