contracted-development-agile.connpass.com
こちらのイベントに参加してきたので、会の様子と感想を書いていこうと思います。
BPさんが新しく入ってくる場合のオンボーディング
納期がある受託開発の中で、既にある程度関係性ができているチームの中にBPさんを入れるのがなかなか難しく、どうしたものか...という話をしていきました。
以下のような話をしていきました。
- 基本的には既存のチームに入ってもらってずっとモブ/ペアで仕事をしていくのが多い
- 最初にイネーブリングチームに入ってもらうというのは悪手だと思う。そもそもストリームアラインドチームの開発者とコミュニケーションが取れない状態でイネーブリングチームを作っても機能しなさそうなのと、イネーブリングチームでやっているんだからできようになっているでしょ？のような勝手な期待が渡される可能性がある
- BPさんだと、社員と違ってスキルに対しての期待値が一定高くなってくるので、面接などでチームに入れていいかの見極めることが非常に重要
- 数日だけチームに入ってもらって力を見極めるというのが鉄板。BPさんだと契約上難しいというのであれば、まずは単月契約でスタートしてみるというのもある
- スキルももちろん重要だが、チームがその人と一緒に働きたいと思えるか？というのも重要。
- スクラムマスターを業務委託で採用するときも、プロダクトへの愛着とかよりもスクラムマスターとしてのスキルを求めているという話が多かった。
受託でのstableチームって？
及部さんのThe Stable Teamの話を聞きながら、受託開発における安定したチームってなんだろう？という話をしていきました。
以下のような話が出ていました。
- 「得た知見を横展開してくれ」と言われてチームが流動的な状態になるパターンはよくあるが、横展開した結果どうなったか？のウォッチがされている話をあまり聞いたことがない
- 案件ごとに必要なスキルがころころ変わってくるから、チームを安定させることが不可能だという話がある。これは、仕事をとってくる人と仕事をする人が分かれちゃっているからこその発想だと思う。
- 発表後に流動的なチームでもうまくいったという話が出ていたのだが、この事例が面白かった。このチームがある会社は、会社全体で同じようなプラットフォーム、同じ技術を必ず使うようにしており、チームが安定していなくても技術という変数は安定しているので、チームの立ち上げがスムーズに行われていたのではないか？という話があった。
- すべてのものが安定していないなかでチームを安定させずにうまくいくことはまずないと思っている。技術も違うしプロダクトも違うしでチームを安定させることはまず無理。
- 安定しているチームって、成長しないチームとか変化が起きないチームではない。
全体を通した感想
熱量溢れる受託開発の実践者が集まる場で、今日もいい話が多数聞けました。
結局、モノづくりに対しての熱が重要で、受託開発/自社開発というのは全く関係ないなんだなあというのを参加者から実感する会でした。
