GWで「The Goal」を読んでみた
はじめに
こんにちは、サーバーサイドのでんでんです。
５月も終わりに近づき、GWがはるか前の事のようです。
「外出もしにくい、仕事もない、ＧＷが暇すぎる」と言っていたら上司が宿題を出してくれました。
(一応言っておくと、前職は物流系サービスで、GWぐらいしかユーザー止まらないし、どうせ混んでるから別日で休もうというチーム文化だったんです)
そんなわけで、この宿題が出ました。
「技術書じゃない！？」と少し面食らいましたが、
読んで見ると「確かに今いる本だな」となりました。
The Goal
ネット上にたくさん書評もあるので全体の感想は置いといて、個人的に面白かったのは
- ボトルネックを見極めること
- ボトルネックをどう活用するか決め、他をそれに合わせること
- そのボトルネックの生産性を最大限にすること
です。
工場の改善する本だったのですが、今回はiCAREの開発で考えてみます。
iCAREではRuby on Rails + Vue.js + GraphQLで実装を行っています。
細かな前後や省略はありますが、大まかな開発フローは以下です。
- POが機能の大筋を考える
- エンジニア/デザイナーで機能詳細を考える
- デザイナーがUI/UXを作成
- サーバーサイドエンジニアがDBなどの設計
- サーバーサイドがGraphQLのスキーマを作成
- サーバーとフロントそれぞれが処理を作成
- フロントがサーバーサイドとのつなぎ込み
1つのプロジェクトなので目標期限がありますが、遅れることもしばしばあります。
全てが少しずつ遅れるのではなく、どこかのボトルネックが原因で全体が大幅に遅れるパターンが多いように思います。
例えば、前述の４番(サーバーサイドの設計)がボトルネックだとしましょう。
その場合、それ以降の作業が進まなくなりPJとして遅れ、成果が出なくなります。
なので4番に集中する必要がありますが、悲しいことに別PJの1~3番や細かいタスクが押し寄せてきます笑
そうなるともう泥沼です。
設計のレビュー中に別タスクを同時進行。対応中に設計のレビューが返ってくるけど対応に遅れて全部がグダグダになる。
大体のエンジニアなら経験あるのではないでしょうか...
本書にも書かれてますが、この場合、
- リソースを遊ばせてもいいから、1~3番のタスクをストップさせる
- 4番に集中させる
- 4番を実行する手段を増やす
- ER図設計はリーダーにしてもらう
- フロントにサーバーサイドもできる人がいたら仮で作ってもらう
する必要があります
正直、リソースを遊ばせても良いのは衝撃でした。
全員が最大限に動いていたほうが良いと思っていたのですが、ボトルネックで詰まってしまい、意味がないどころか全体のスループットを下げるとのことです。
が、言われ見てれば自分にも経験ありますね...ビジネス界隈でも「選択と集中」と言われますが、組織にも当てはまるようです。
ボトルネックを改善すると、そのうちボトルネックが移動していきます。前述の１番(POが機能を考える)がボトルネックになるかもしれません。
現場メンバーが頑張って「早く次を作りたい！」みたいな場合です。
この場合も、対応は同じで、
- そのタスクに集中させる
- POのすべきタスク以外させない
- 実行する手段を増やす
- 他のメンバーでPOレベルで仕様を考えられうようにする
です。
なので重要なことは、常に組織全体で
- ボトルネックを探し
- 他をそれにあわせ(ボトルネックの生産性が、全体の生産性なので)
- ボトルネックを改善する
と本を読んで解釈しています。
最後に
...とカッコいい感じに締めたいのですが、
凄く悲しいことにiCAREでは今ボトルネックが開発リソースです！
POとデザイナーに「リソースがない、ちょっと待って！」とすでに止めています...
僕自身９月まで作るものが決まっている状態です。
iCAREではエンジニア、CS、セールスなど各職種、ポジションを絶賛募集中です!!
ご興味ある人はぜひ面談にお越しください！！
