プログラミングこの広告は、90日以上更新していないブログに表示しています。2014-11-03チームを分割する指針として何が適切かマネジメントはじめに現在、私は、とあるソフトウェアプロダクトを開発する数十名規模のチームに所属している。このチームに対して適切な組織と開発プロセスを適用したいと思い良いスタイルを探している。今日は、そういった事を考えている内に出てきた1つのアイディアについて書き留めたいと思う。先にどのようなアイディアなのか結論を書く。Scrumというスタイルがある。Scrumで重要になるのは、各チームをどのように分割するかだ。『単独で「ユーザーに届けるべき価値」を作れる独立したまとまりになる事』を指針としてチームを分割するのが良さそうだ。この指針には、チーム内のコミュニケーションをシンプルで密にし自己組織化を促進する効果がありそうだ。Scrumの良さ(うまくいけば)自己組織化が行われ、未知の状況に対する適応能力が高くなるのはScrumの良い点だ。Scrumの課題しかし多人数のチームにScrumを適用しようとすると色々問題も出てくる。デイリースタンドアップミーティングや、スプリント計画などを10名以上で行うにはかなりの困難だろう。数十名規模のチームで、これを実践出来ているチームを見たこともあるが(驚異的だと思う)、そういう事が出来るチームを意図的に作り出す事は難しい事だし、長期的な取り組みが必要だ。なにか、別の選択肢は無いだろうか。小さなチームの複合体にするこの問題について、DeNAのComm開発チームが面白い取り組みをしている。DeNA流ScrumとcommのチームビルディングScrumを行う小さなチームを複数用意して、それらのチームのPOで更にScrumを行うという方法によって、多人数のチームにScrumを適応しているのだ。Scrumと言うらしい)確かに、この方法ならScrumのスタイルを維持したまま、大規模な開発が出来そうだ。"小さなチームの複合体"を実現するにはこの"小さなチームの複合体"を実現するにあたっては、チームの分割方法が重要になると思う。Scrumについて書いたが、どのような開発プロセスであってもチームの分割は重要なテーマだと思う。今のところ、たぶんこう言う事が重要になるのでは無いかと思っている。(エンジニアだけ、とか企画だけ、では無い)高凝集、疎結合であればコミュニケーションパスはシンプルで密になる。これは自己組織化を行うにあたって重要な点だと思う。参考この本に『「創って、作って、売る」小さなチーム』というコンセプトが登場する。職能別の縦割り組織を、プロダクト別の"横割り"組織に変え、各プロダクトのリーダーに強力な権限を与えて自走性を高める事で、赤字事業部を見事に黒字化させる話だ。この本で語られているコンセプトを参考に、この指針を考えた。(3)検索はてなブログをはじめよう!Shinya_131さんは、はてなブログを使っています。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。