GWで「The Goal」を読んでみた | Dev Driven 開発・デザインチーム GWで「The Goal」を読んでみた | 働くひとと組織の健康を創る iCARE

BLOG

GWで「The Goal」を読んでみた

shogofukuden
2021/05/29
+1

はじめに

こんにちは、サーバーサイドのでんでんです。
5月も終わりに近づき、GWがはるか前の事のようです。

「外出もしにくい、仕事もない、GWが暇すぎる」と言っていたら上司が宿題を出してくれました
(一応言っておくと、前職は物流系サービスで、GWぐらいしかユーザー止まらないし、どうせ混んでるから別日で休もうというチーム文化だったんです)

そんなわけで、この宿題が出ました。
ザ・ゴール 企業の究極の目的とは何か

「技術書じゃない!?」と少し面食らいましたが、
読んで見ると「確かに今いる本だな」となりました。

The Goal

ネット上にたくさん書評もあるので全体の感想は置いといて、個人的に面白かったのは

  • ボトルネックを見極めること
  • ボトルネックをどう活用するか決め、他をそれに合わせること
  • そのボトルネックの生産性を最大限にすること

です。

工場の改善する本だったのですが、今回はiCAREの開発で考えてみます。
iCAREではRuby on Rails + Vue.js + GraphQLで実装を行っています。
細かな前後や省略はありますが、大まかな開発フローは以下です。

  1. POが機能の大筋を考える
  2. エンジニア/デザイナーで機能詳細を考える
  3. デザイナーがUI/UXを作成
  4. サーバーサイドエンジニアがDBなどの設計
  5. サーバーサイドがGraphQLのスキーマを作成
  6. サーバーとフロントそれぞれが処理を作成
  7. フロントがサーバーサイドとのつなぎ込み

1つのプロジェクトなので目標期限がありますが、遅れることもしばしばあります。
全てが少しずつ遅れるのではなく、どこかのボトルネックが原因で全体が大幅に遅れるパターンが多いように思います。

例えば、前述の4番(サーバーサイドの設計)がボトルネックだとしましょう。
その場合、それ以降の作業が進まなくなりPJとして遅れ、成果が出なくなります。

なので4番に集中する必要がありますが、悲しいことに別PJの1~3番や細かいタスクが押し寄せてきます笑
そうなるともう泥沼です。
設計のレビュー中に別タスクを同時進行。対応中に設計のレビューが返ってくるけど対応に遅れて全部がグダグダになる。
大体のエンジニアなら経験あるのではないでしょうか...

本書にも書かれてますが、この場合、

  • リソースを遊ばせてもいいから、1~3番のタスクをストップさせる
    • 4番に集中させる
  • 4番を実行する手段を増やす
    • ER図設計はリーダーにしてもらう
    • フロントにサーバーサイドもできる人がいたら仮で作ってもらう

する必要があります

正直、リソースを遊ばせても良いのは衝撃でした。
全員が最大限に動いていたほうが良いと思っていたのですが、ボトルネックで詰まってしまい、意味がないどころか全体のスループットを下げるとのことです。
が、言われ見てれば自分にも経験ありますね...ビジネス界隈でも「選択と集中」と言われますが、組織にも当てはまるようです。

ボトルネックを改善すると、そのうちボトルネックが移動していきます。前述の1番(POが機能を考える)がボトルネックになるかもしれません。
現場メンバーが頑張って「早く次を作りたい!」みたいな場合です。
この場合も、対応は同じで、

  • そのタスクに集中させる
    • POのすべきタスク以外させない
  • 実行する手段を増やす
    • 他のメンバーでPOレベルで仕様を考えられうようにする

です。
なので重要なことは、常に組織全体で

  • ボトルネックを探し
  • 他をそれにあわせ(ボトルネックの生産性が、全体の生産性なので)
  • ボトルネックを改善する

と本を読んで解釈しています。

最後に

...とカッコいい感じに締めたいのですが、
凄く悲しいことにiCAREでは今ボトルネックが開発リソースです!
POとデザイナーに「リソースがない、ちょっと待って!」とすでに止めています...
僕自身9月まで作るものが決まっている状態です。

iCAREではエンジニア、CS、セールスなど各職種、ポジションを絶賛募集中です!!
ご興味ある人はぜひ面談にお越しください!!

+1