開発チームの8つの課題と責任範囲

こんばんは、アジャイルは好きだけどスクラムは苦手なIwaoです。

生産性という言葉が好きで、開発チームの生産性を上げる仕事をしています。生産性を上げるためにはメンバーの心理的安全性と責任感が必要条件だと思ってて、生産性の高いチームほどプロジェクトの成功率は高いと思っています。

ただよくあるのが開発の責任範囲が不透明なままでプロジェクトが進んでいき、開発者が無駄な責任まで背負ってしまってパンクしてしまうことがあります。

今回は以下のように要件定義側と開発側を分けて、開発現場で個人的にあるあるだと思う課題とその責任がどこにあるのかを解説していきたいと思います。

要件定義側
プロダクトオーナー・プロダクトマネージャー・企画職
Why・Whatを決める人
開発側
プロジェクトマネージャー・スクラムマスター・開発職
How・Whoを決める人

僕は両方の立場を経験していて、基本的には経験則による分析ですのでお気軽にご覧くださいw

(1) むちゃぶりが不定期に飛んできて緊急度が高い要件であふれている

これはシンプルに要件定義側の責任です。

開発者はむちゃぶりほど怖いものはないですよね。徹夜しなきゃいけないとかストレスになることが多いので仲間であれば心情的にも放っておけません。これにより個々のセルフマネージメントができなくなってしまい開発は疲弊します。

ただむちゃぶりって単なる一つのタスクで優先度が高いだけです。タスクの優先順位づけは要件定義の仕事なので、合理的にNOと言えないのであれば存在する意味がなくなってしまいます。

そのためにブロックするための開発プロセスの仕組み化はあったほうが良いですよね。特にスクラムは強度強めなのでむちゃぶりを弾くには最適です。まさに要件定義側に開発プロセスの理解が求められますね。

(2) 開発中の案件がペンディングになりリリースされない

これはもちろん要件定義側の責任ですね。

結果的にコスト的な打撃はもちろん、開発者は成果が剥奪されるのでやる気を失うことになります。ゲーム会社では作品自体が消えるみたいな話もよく聞きます。

ペンディングになってきた事例を考えるとWhyの定義があまいことが多かったです。何のためにプロジェクト化するのかを関係者全員から共感を得ることからスタートするわけなので。ビジョンがない企業になってしまいます。

これは要件定義フェーズで要件定義者はステークホルダーと開発者も混ぜてしっかりディスカッションすることが大切です。また開発フェーズに入ってもステークホルダーと継続的にWhyの話をしたいですね。

(3) 少し違う仕様なら簡単にできるのに要件を忠実に守りカオスな仕様になる

これも要件定義の責任だと思ってます。アジャイル開発が前提ですが。

ちょっと仕様を変えればいいのにって結構あって、ステークホルダーもなるべくコストをかけないほうが嬉しいわけなので提案を待っています。それをサボると結果的に技術的負債が蓄積されることになり全員を不幸にします。

仕様を完全に固めてから進むのがウォーターフォールで、少しずつ不確実性を埋めていくのがアジャイルです。継続的に改善を繰り返すタイプの製品ならアジャイルを選んでいると思うのですが、それでも決まったことだからと頑なに仕様を変えないのは要件定義者に重要度の判断力が欠けている場合が多いです。

要件定義者は簡単だと思ってたけど想定外の工数を提示されたら別の案がないか開発者に相談するとよいかと思います。そして仕様が変わるようなアイデア（How）が開発者から提案されたら速やかにステークホルダーに相談しましょう。

(4) 開発者は何のために開発しているのかわからない

これはそのまんまWhyなので要件定義の責任ですね。

受託開発ならまだしも自社製品開発なのに、開発者は目的不明な作業が続くと会社にいる存在目的を脅かしてしまいます。自社製品の開発者はビジネススキルがつくことが大きなアドバンテージのひとつです。

要件定義する人はプロダクトマネジメントトライアングルを理解しましょう。ユーザ・開発者・ビジネスそれぞれにバランスよく要件を共感してもらう必要があります。「バランスよく」ですよ。

だらだらと長い無駄だらけの要件定義書を書くのは自由ですが、まずはWhyとユースケースを書いて開発者に相談しましょう。Whyが間違っているケースも結構ありますが、そのレベルになると要件定義者のスキル不足なので勉強してもらうしかないかなと思います。

(5) 聞いてないとか、知らなかったとか情報共有がうまくできない

これはコミュニケーションなので要件定義の責任です。

多くの現場で聞く課題です。特にすぐに共有してくれないと怒るような開発者や、メンションが漏れるなどの凡ミスが大きなロールバックを引き起こすなんてケースもあります。

要件定義側はディレクションつまりコミュニケーションハブの機能を持っていて、しっかり情報を共有する仕組みから考える責任があります。なぜなら仕様を実現するためのコミュニケーションですから、その仕様の責任者が管理したほうが効果的だからです。

仕様がわからないのはディレクション側、ソースコードを読んでも仕様がわからないのは開発側が責任を持つように考えれば簡単ですね。インターフェース設計と同じ感覚でチーム間の情報の鮮度と集約を両軸で考えて、仕様実現の最短ルートを考えましょう。

(6) 誰が何をやっているのか、誰に聞けばいいのかわからない

これはWhoの話なので開発側マネージメントの責任です。

新しく入った人が長く働いている人に仕様を聞く構図をたまに見かけますが、その人が休みだったり忙しいと業務のボトルネックになります。そのボトルネックを引き起こすのが属人化を排除できていないからです。

属人化は辞められた時のリスクヘッジとして、また権限委譲を進めるためにも解消しておくことが求められます。これだけ転職が当たり前の時代なのでメンバーの入れ替わりを想定しておきましょう。

かんばんボードを見れば誰が何をやっているかはわかるし、役割・責任が分担されていれば体制図を見れば誰に聞けばいいのかわかります。

ただ聞くコストすらも勿体ないので、開発者はコードを見れば仕様がわかる状態にはしたいです。別のエンジニアでも仕様を探せるコードを書けるような品質を上げるためのリファクタリングができる開発組織であってほしいです。

(7) マイクロマネージメントで一つ一つの行動を指示・管理している

これはそういうマネージメントをせざるを得ない状況になっている開発マネージメントの責任です。

開発者にとってコマンド＆コントロール型いわゆるマイクロマネジメントがよくないのは10年以上前から言われていて生産性が下がることは明確です。

これはアジャイルが生まれている理由の一つにもなっています。つまり開発プロセスを改善して、要件定義側が指示を出すのではなくタスクを出してもらい、開発側でそのタスクをとるだけでコミュニケーションコストは下がります。

逆も同じで要件定義側がその指示に対してどんな成果を出したかを管理するのは時間が勿体ないです。そのタスクのチケットを見れば進捗がわかるように工夫しましょう。

それでも要件定義者がデイリーの状況を知りたいなら日報を書いてもらうようにお願いすればよいかと思います。開発者も面倒くさいですがセルフマネージメントが苦手なうちは書くと良いでしょう。

(8) 特定のメンバーの時間的負荷、精神的負荷が上がっている

これもWhoなので開発マネージメントの責任です。

限られたリソースで生産性を最大化するためにエースに負荷をかけがちです。しかしエースが離職が発覚したときに採用しようとしてもヒーローはすぐに現れず人材難の打撃を受けます。

理想論ですが誰かが辞めてもスムーズに後継者にシフトできるようにしたいわけですから、不確実性の高い採用活動は定常的に取り組みましょう。一方でリーダーは1on1で各々の状況をヒアリングして負荷を軽減させるための環境づくりをする責任があります。

いっぽうで海外ではジョブディスクリプションの明確化をして、役割と責任範囲が定義されたポジションが用意されている場合が多いです。レイオフが許容されているから成立するのかもしれませんが、移籍リスクと補強のバランスをとるマネージメントはいずれにしても必要です。

まとめ

要件定義側が非エンジニアで開発プロセスを理解していない状況ってのはよくありますが、過去のプロジェクトと振り返ると答えはシンプルに責任が明確になっているかどうかでほぼ決まっています。そもそも責任って何？って話は長くなるのでまた別の機会にでも。

「エンジニアリング組織論への招待」にも書かれているこちらのマトリクスがわかりやすいです。「心理的安全性」だけでなく「責任」は、日本の開発組織における生産性に影響の大きい属性である旨が書かれています。

開発の内側だけでなく外側との責任範囲を明確にするだけで生産性は上がるよってお話でした。

最後に僕が提案するのは、要件定義をエンジニアとデザイナーがペアになってディレクションすることが効果的だと思っています。要件定義に必要なWhyとWhatに対して、経験のあるデザイナーはWhyを考えることに優れていて、経験のあるエンジニアはWhatを考えることに優れているからです。これがプロダクトマネージャーとプロダクトデザイナーの二頭体制であり、製品開発の領域では最近よく聞くようになりましたね。