はじめに 恥ずかしながらスクラム開発の開発チームへの導入を何度も経験しているのだけれど、どうしてもチームの成熟レベルが高い位置までもっていくことができませんでした なぜうまくいかないのか？ これを深掘りする過程で教科書どおりに実行するには組織の構造がスクラムガイドで書いてある構造と根本的に異なっているのではないか？と考えるようになりました。 よくあるエンジニア組織の構造 大きめのWebソフトウェア企業の内製型エンジニア組織の構造はだいたいどこもこのような感じになっています この組織構造の問題点 スクラムを導入する場合、リーダー自身かあるいはメンバーの一人がスクラムマスターとなります リーダー自身がスクラムマスターになる場合でもアンチパターンと言われる開発者との兼任になります。 スクラムマスターの最も重要な職務である「観察」が行えなくなります。 スクラムマスター自身が観察を行わない場合、各メ

開発と運用の理想的な関係とはどんな姿か。すでに「DevOps」という言葉は浸透しているものの、理想的な形で実践できているかとなると、話は別だ。現場ではどんな障壁があり、DevとOpsが分断されているのか。打開していくにはどうしたらいいのか。DevOpsという言葉が生まれる前から、その本質を実践してきたAmazonのカルチャーにヒントがありそうだ。AWSジャパン 塚田朗弘氏に聞いた。 今回お話を伺った、アマゾン ウェブ サービス ジャパン株式会社 ソリューションアーキテクト 塚田朗弘氏 ペアで語られてしまいがちな「マイクロサービス」と「コンテナ」 Amazonには「DevOps」や「マイクロサービス」という言葉が生まれる前から、DevとOpsを統合し、システムはAPIでやりとりするという原則がある。それを長年追求するなかで、開発カルチャーを育んできた。そんなAmazonから開発と運用の理想の

ということをいつも心がけている、という話です。 僕が組織のマネジメント職を20年ほどやらせてもらっている上で、いつも意識しているのは権限移譲とセルフマネジメントです。この辺の話は過去のブログにも書きました。管理職のためのエンジニア組織構築マニュアル管理職のための役職引退マニュアル現場に口を出さないマネージャーの作り方つまり「権限と裁量を同時に移譲し、責任感を持ってプロアクティブに仕事をしてもらいながらも、メンバーの良いところを更に引き出して高いパフォーマンスを出してもらう」ことこそが、マネジメント職のやるべきことだと思っています。 そのために僕がいつも権限移譲の際に伝えるのは、ルールではなくガイドラインです。ルールは規則や規定といった決まりごとなので「やること」「やってはいけないこと」が書かれたものです。ガイドラインは大まかな指針なので「方向性」「やったほうがいいこと」「やらないほうがいい