はじめに
- 受託スクラムでPO/SM/DEVのチームを作るときに考えるポイントをまとめました。
- 有名なアジャイルコーチの意見
- 自分の体験談
- 今回はDEV編
DEVは誰がやるんか問題
誰がと言われても
開発者がやる。あんまりここで悩むポイントはない。
DEVというかチームの要素でよく言われているポイント
基本的には以下から抜粋。あくまで教科書的な定義です。
クロスファンクショナル/機能横断的
ざっくりいえば、インフラもアプリもいるチームを組成します。
1チームだけで1機能を構築できることを求められます。
ネットワーク設定などはできませんというのはNGみたいなイメージです。
自己組織化
細かいところは以下を見てもらう。
いくつかの段階はあれど、ひとまず「自チームの進捗をメンバーが把握しており、目標到達に向けて適切なアプローチを選択できる状態。」を目指す。
自律的
以下に書いたとおり、日本の法律上「自律的」ってのは重要なポイントになります。
発注者と受注者の関係性が対等であること
受注者側が発注側の提案に従う必要がない関係性であること
心理的安全性
まずは以下を読んでからになります。
ざっくり言えば「現場のまずい部分を報告しても、個人の責任にされず、むしろ課題報告を褒められ、チームとして対処すべき課題として前向きに取り組んでもらえるという確信をみんなが持っている状態、もしくはそれに近しい状態」を指す。
理想と現実(どれも個人的な意見です)
クロスファンクショナル/機能横断的
キャリアの方向性とのズレ
現実問題として、アプリ開発者を調達するとインフラの知識はないことが多いし、インフラ要員を調達するとアプリの知識がないことが多い。あと、そもそもフルスタックエンジニアはいない。（どこにいるの・・・？）
それでもそういうチームを組成しましょうというのが教科書的な話としてはある。
ただ、調達したインフラ要員がアプリ技術を身につけたいと思っているのか、アプリ要員はインフラ技術を身につけたいと思っているのか？など、個人のキャリアの方向性にも大きく関わってきており、そういうのはちょっと・・・という話になりやすいのも実態としてある。
雇用しているわけではなく調達している以上、永続してこの現場にいてもらうことを保証できるかというと、それも難しい。
調達側が譲歩してないのに、開発メンバーが譲歩する理由はない。
キャリア：ジェネラリストとスペシャリスト
ある程度なんでもできるジェネラリストというのは重宝される部分はある。
ただ、「どうしてもこの人が欲しい！」となるのは特定領域に特化したスペシャリストであることが多い。
ジェネラリストは体制を考える上で「穴埋め」的に使われるケースが多く、本人の希望するポジションやキャリアを主張していくのでればスペシャリストを目指した方が生きやすいところはあるのでは、と思ってる。
当然ジェネラリストでも「まじでなんでもできる人」レベルなら、引っ張りだこだろう。「うっすらある程度できなくはない」ってのは結構ツラい。
いわゆるフルスタックエンジニアだが、誰もが「まじでなんでもできる人」レベルになることは稀だと思っている。
凡人の戦略的にはある程度特化させていく方が良い気がしてる。
そう考えると、キャリアの方向性とクロスファンクショナルなチームがハマらないと感じてしまう人もいると思っている。
成長を待てない実態
都合よく噛み合ったとしても、フルスタックエンジニアなんて調達に引っかからないし、いたとしても数はほとんどいない。
そうすると現場の中での成長に期待するしかない。
ただし、インフラ要員がプログラミングを学ぶのに時間はかかるし、アプリ要員がインフラ知識を身につけるのにも時間はかかる。
また、受託開発という現場は、プロジェクトの達成のために必要な要員を集めるスタイルである以上、今から育てるというスタンスではなく「できる人を連れてくる」というスタンスでやっていることが多い。
顧客としても開発メンバーを育てるメリットがない（育ててもすぐいなくなるなどの理由から）ので、成長を待てないことが多い。
無理矢理クロスファンクショナルしても機能しない実態
クロスファンクショナルなチームは、自分の職能と異なるタスクであろうと、チームとして対処すべきなら対処することが求められる。
ただ、前述の問題があり、職能を跨げないという制約が現実にあったとしよう。
その状況下で同じチームにインフラとアプリを混ぜたとしても、自分の職能の外には手を出さないだろう。
同じチームといいつつ、ただ個人個人の作業をやっているだけになりやすい。
なぜクロスファンクショナルが求められるかというと、二つの観点がある。
- 職能ごとに分割したチーム体制では、依頼授受などのリードタイムが発生して、フロー効率が落ちる。
- 職能ごとにタスクを分担すると、どちらかの職能がボトルネックになるなどの状況が生まれ、タスク全体のフロー効率が落ちる。
無理矢理クロスファンクショナルしても、どちらも解消されない。ただ形だけなぞっただけで課題が解決できない。
一つのアプローチとしての職能分担
受託開発やある程度大規模な開発をやっている現場だと、職能で部門が分かれていることも多いと思います。
そうなると、短期的にはクロスファンクショナルなチームを組成するには課題が多すぎます。
なお、将来的にはクロスファンクショナルなチームを組成できるように、組織を改善していくべきだと思っています。
そういった現実的な状況を踏まえつつ、フロー効率が許容範囲に収められるのであれば、職能ごとにチームを分割してもいいと個人的には思っています。
（というか、フロー効率は今まで通りというだけだと思うので、だいたいの場合許容できると思っている。）
公式としてのアイデア
SAFeと呼ばれる大規模アジャイルフレームワークでは、チームごとに多少の役割づけをすることもアプローチの一つとして紹介しています。
（なお、クロスファンクショナルが良いよね、という前提の上でですけど）
実際の現場
SAFeで表現されているくらいの役割づけはやってます。
まだ完全なクロスファンクショナルとはいいづらいけど、PJを遂行する分には問題ないと思っています。
自己組織化/自律的/心理的安全性
そんなことは求められて来なかった歴史
どちらも最初から備わっているものではなく、身につける必要のある振る舞いです。
ただ、受託開発ウォーターフォールの現場は、割と上位下達な文化が多い印象。
特に調達した外部要員はこういうのは求められませんでした。
偽装請負のリスクを懸念して、指揮命令系統を無視したコミュニケーションは排除されることが多く、現場から意見をあげるのは非常に難しい状況にあったからだと思っています。
そこで、急に今日から「自律的になってください！」と言っても、なれるはずがありません。
また、ここら辺は言ってできるなら苦労しないんすよ。
命令ではなく相談をする
発注側としてすべき振る舞いとして、「命令」や「伝達」ではなく「相談」をするようにしています。
要は、何かを決定するところに一緒に参画してもらうようにしています。
そして、その場で各自に意見を聞くようにします。
「本人に考える機会を与え、意見を言ってもらい、それを取り入れる」を繰り返すことで、自然に意見を言ってもらえる文化を作っていきます。
ここで難しいのは高圧的にならないように、心理的安全性を確保しながら本人の意見を引き出すアプローチです。
こちらはフランクに聞いてるつもりが、相手には高圧的に聞こえてしまうケースもあります。
そのためにも重要なのは日頃の関係性の構築です。
発注者＞受注者という関係性でしか関わっていないと、どうしても高圧的に伝わってしまいがちです。
契約などの場面があるので、どうしてもそういう関係性をゼロにはできません。
でも、なるべくそれ以外の場面ではフラットな関係性を示すために、相手を尊重していることを示していく必要があります。
そうやって、関係性を作っていってようやく、相手が自律的になっていきます。
受注側に自律的になってもらうために変えるべきは、発注側の振る舞いです。
従来の役割との違い（私見）
あくまで実体験ベースでの差異なので、他の現場から見た時と比べると間違ってる場合はあるかと思います。
ウォーターフォール案件における開発者との比較
同じであって欲しいけど難しいよね
- WBSを元に指示されたタスクの遂行ではなく、PJ目標を理解した上で、自分の意思をもった上でのタスクの遂行。（自律的な遂行）
難しさ
- ベテランほどこういう振る舞いができない。（今までの文化が染み付いている）
- ハマる人とハマらない人がいる。（すぐに理解して振る舞いを変えれる人と、理解に苦しんで振る舞いを変えれずにいる人がいる）
まとめ
「アジャイル人材はいない」という現実に立って調達を行う
悪いけど、受託開発の現場にはなかなかおらん。
それは今までの歴史が悪いのであって、開発者が悪いわけじゃないと思う。
変わっていることをちゃんと伝えつつ、発注側の振る舞いをちゃんと変えていくことで、実際今の現場の人材は変わってきています。
今いないのだからこそ、自分の現場で育てて増やしていくスタンスを続けていきたい。
アンチパターンは踏み抜くもの
他でもいいましたが、受託アジャイルをするのであればアンチパターンは必ず踏みます。なるべく避けるべきですが、踏まざる得ないものは、周りの理解を得た上で対策を立てた上で踏み抜いていきましょう。
地雷原の先にしか受託アジャイルの未来はないです。
後続の受託アジャイルが少しでもやりやすくなるように、地雷を踏み荒らしていくのだ！という気持ちで進みましょう。
次回予告
次は大規模開発編。大規模の時に悩むポイントをいくつか書いていきます。