本が出た当初に読んでいた本ですが、ブログに書いていなかったため記事にします。
サービスを開発、運営している会社であれば読む価値ありの必読本だと思います。
spotifyの組織の作り方や文化が理由も解説される内容で書かれています。なにが問題でどういう解決方法をとっているか。会社の取り組みは会社の文化にもよるため全てがうまくいかないと思いますが、事例を自社に適用できるかどうか考えるきっかけになるため会社の文化を読むことはおすすめです。
個人的には会社の取り組みを見ることは好きで読みますね.
本書で自分が意識した点を書いていきます。
権限
会社って権限を人に渡すことを渋るイメージですが、権限ってできるだけ渡した方がいいと思っています。
自律する組織を作りたい場合には必要なことだと思います。
個人的にはAWSのadmin権限で使えたためいろんなサービスに触れることができ、興味が大きくなったのはいい経験です。最初の会社ではAWSのサーバーを立てるためにインフラチームに申請書をだして、経費から使えるかどうか稟議を行い、通った場合にサーバーを追加できる状態だったためアプリチームにAWSの知識が得られない状態でした。まぁ、7,8年前の話のため現在は制度が変わっているかもしれませんが、インフラとアプリのチームが別れていることが今では足枷としか思えないです。
権限を渡しすぎて問題になることも見てきましたが、それより言われないと動かない人が増えるほうが個人的には好きではないため自分の頭で考える人が増える組織になって欲しいですね。
まぁ、小さい会社にいたからそう考えるのかもしれないですね。
中小企業になると、難しいことなのかな？？いろんな人がいますからね。そこは信頼してみるしかないですね。
ミッション
ミッションが共有できるとチームで仕事をする指針にできるのがいいですね。
チームで話をしていて、開発する機能の優先順位を決めたりする際の基準になったりしていました。
最近は「売上のみのミッション」ってどうなの？？とすごい感じます。経営層が提案する内容がこれだけの場合が多い気がします。たぶん自社のサービスを見ていないのでしょうね。
売上だけを目指す場合に、ユーザー視点って見えなくなると思います。それこそ営業を増やせばいいんじゃね。という考えの人が増えると思っていて機能にフォーカスした話が少なくなると思います。
個人的には売上目標自体はあってもいいと思っており、ミッションを達成する上での数値的な可視化につながることはいいと思っています。
具体的にはスイミングスクールのサービスを運営していた経緯があり、ミッションとして「子供が健全に育つ環境を作りたい」を個人的には掲げていました。
施設の人が楽になることで、スクールに通う子供のことを考える時間が増えるよう工夫するのは面白かったです。経営に関してもアプローチしたかったですが、あまりいい機能は作れなかったですね。
経営に関するアプローチは、スクール自体がうまく運営されないと通う場所自体もなくなるし、優秀な人から別の業界にいってしまうためなにかシステムで手助けできることを考えていた感じです。
逆にミッションが不鮮明な場合に、作ろうとする機能が固まらず色々と手を出して失敗するケースを最近経験しているので、チームで機会があれば話し合いができるチームっていいな。と思います。
トライブ
チームと組織としての両立をどうするか考える要素として、本書はサンプルになると思います。
どう横の繋がりを活かすか、チームで独立するわけではなく組織として強くしていくか。
参考にしてみるといいと思います。
ただ個人的にはあまり横の関係でよくなったケースはあまりないので、正直うまくできるのか謎ですがチームごとに課題が違い、解決してきた内容が共有できれば全体で良くなる気はします。
チームでの忙しさが違い、常に忙しい部門にいたのと自分の知識量が低かったので、取り組み方がよくなかったと思います。チーム以外の作業するとなぜか上司に怒られることが多かったなー。
理解度がある組織になると価値がでるのかな。
営業やインフラチームやできるエンジニアの人と話しているときは、すべてが勉強になった時期だったのでプログラマ以外の人との関わりで成長できた記憶はあります。旧来型のチームだったので、まずはチーム作りから考える必要がある組織だったのかな。
生産性向上に投資する
本当に重要！！
システム会社でシステムを提供しているのに自分たちはサービスを使わないで、手作業でミスを繰り返す組織。システム化したほうがいいと提案すると「私が作業すればその費用必要ないですよね」という社員がいた。あなたの人件費がかかっとるねん！！と本気で説教しそうになった時代がありますね。
5,6年は9時出社して夜11時まで働いていた時期。通勤を含めると7時 - 深夜1時。
手作業でのリリース、ソース管理はブランチが切れないツール、タスクは共有できず進捗が不明な状態、テスト項目書は数千件のテストを手作業で行いエラーが一つでもあれば全てやり直し、サーバーは壊れるリスクがあり壊れたら再度作り直し、開発環境は共用環境。
日常でしたね。
そこからの改善
- リリースはjenkins, github action, codedeploy
- ソース管理はgit ( ブランチもローカルで作成でき、ブランチ切り替えも早い )
- タスクはtrello, backlogで共有
- テストは開発環境が変わり、テスト項目書を作らなくなった（テストコードを書いているわけではないため今後の改善）
- サーバーはaws
- 開発はdockerでローカル環境
- 連絡にチャット
もっと改善できることはありそうですが、数年前から比べるとすごい進歩だなー。と思いつつ、作るスピードが上がったかは謎。手作業や周りへの影響という心理的なリスクはものすごく減ったため、開発はしやすいですね。
ただ会社の中で改善が定期的に行われていたわけではなく、きっかけをだれかが作って自分の作業時間を削って取り組んでいた。
会社で生産性向上に投資することを意識してくれた場合、どれぐらい変わるのか見てみたい気持ちがかなりあります。
会社って最初にお金を使うことを突破するのは大変だけど、使い始めて便利だと理解すれば気にしなくなるのが不思議で、最初のきっかけをもっと簡単にしてほしいと思っていたが、どれぐらい使っていいよ。みたいな指針を見たことないし、改善を推奨するから。みたいな時間をもらったことはない。
逆に改善するために頑張ってた時間で、なにしてるの？仕事してよ。とか言われたこともあったり、別チームを参考に行くと「そんなことしてないで仕事をしろよ」って言われたこともあったなぁー。会社って難しいって思ってた時期ですね。そのため毎日昼の後の１時間ぐらいは情報収集と改善に充ててましたね。お昼後は結構会議とかしてる人多いし、自分の作業してる人多いからやりやすかった印象かな。
まとめ
さくっと読むだけなら1時間程度で読めるページ数です。
システム会社の人は一度読んでみて欲しい本です。企業によりできることは違うと思いますが、小さい企業で動きやすいところは「生産性向上に投資する」だけでも取り組んでみて欲しいですね。
組織作りってむずかしいですよね。ただ色々な取り組みを知るだけでもなぜこういう仕組みにしたのかを知ることができ、課題をどう解決したかを知ることができます。
「自社は特別だから。他とは違うから」と思う前にいろいろと知ることで、すでに同じ課題で悩んだ人はかなりいることがわかるし、取り組みも参考にできます。
学習は「教えをうける。繰り返し真似をする。」です。（学：教えをうける、習：くりかえしまねをして身につける。）
真似をすることは悪いことではないと思い、いいことは取り入れていきたいですね。
