人が増えても速くならない ~変化を抱擁せよ~を読んだ drc#55

デッドライン読書会第55回の課題図書は「人が増えても速くならない ~変化を抱擁せよ~」でした。

https://amzn.to/3XQjsBK

読書会として55回目。続きますなぁ。技術書の積読がなくなることはないので、しばらく終わることはなさそうです。この会のおかげで(いわんや、締切のおかげで)継続的に本を読めていることは良いことです。

課題図書

ソニックガーデンの倉貫さんの「人が増えても速くならない ~変化を抱擁せよ~」です。副題も大事ですので一緒に載せます。プログラマー・エンジニアではない人(主に経営者)に向けて書かれた本のようです。ソニックガーデンは今年で13期目とのこと。干支一周分ご活躍され、日々考えられていることのエッセンスを本書に込めんで頂いています。

ソニックガーデン13期目 | Social Change!
今月からソニックガーデンは13期目になります。12年続けてこれたことで干支一周して、今期から改めて本業の「納品

感想文

メタファーがたくさん

各章はとある事業開発を実施している職場での会話からはじまります。6章では「こちらの機能ですが、ざっくりと見積もると、どれくらいですか?」。これに対してエンジニアとのやり取りがあり、この会話が行われている背景にはソフトウェア開発ではどういった事情があるのか、またそれを例え話(メタファー)で解説しています。メタファーがたくさん出てくることも本書の特徴の一つです。

  • プログラミング(ソフトウェア開発)は、料理のレシピを作る仕事にあたること
  • 使われない機能は、小売業で言えば売れない在庫を抱えておくようなもの

他者とツーカーでコミュニケーションを取れない場合(認識にギャップが有る場合)は、良いメタファーを繰り出せることはかなり大事だと思ってます。「ようはあれですよ、○○○」というやり取りを通してお互いの認識を揃えることに大きな効果があります。

分かっていて出来ていることも出来ていないこともある

自分もプロジェクトを運営しているので、特に気をつけているのが、

  • 本書のタイトルの「人が増えても速くならない」こと
  • チームを大きすぎないようにする
  • 仕様を把握する人間とプログラミングする人間は同一人物であるべき

ってところです。特に人が増えるタイミングはとても気を使います。感覚的にはまだギャンブルに近い。一時的にチームのパフォーマンスが下がり、そのあとその分を挽回できるかが気がかりになるわけです。また私の仕事はプロジェクト型の受託開発、納品もあり、チームの解散もあるわけです。どうしたら理想のチームに近づけるか受託開発のあり方から自分でも答えを探していきたいです。

おわりでの主張

これがむずい。分かっちゃいるけどむずい。

「変化に対して管理やコントロールをしようとするのではなく、あるがまま受け入れつつ柔軟につきあっていくこと」

おわりに

どうしても脳裏にはQCDという単語がよぎります。それらを満足するためにマネジメントスタイルをとっちゃうのですよ。でも所詮PMやリーダーでコントロールできる範囲には限りがあるものです。ウォーターフォール型の開発においても場面場面では柔軟に適応的に実施するほうが良い場合も多いです。QCDがすぐ脳裏に浮かぶのはきっと「(設計)在庫」が多いからでしょうね。大量の在庫を無駄なく使うことを意識してる。在庫は減らして価値に変換することにフォーカスできれば、自然にあるがままを受け入れつつどう対処するかに集中できるようになるのかもしれません。いや、それだな、たぶん。あと在庫意外にも、稼働率(リソース効率性のこと)も脳裏に…

これの背景は、アジャイルマニフェストでしょう。リンクを貼っておきます。(改めて読んだら最近は「契約交渉」もよくやっているなぁ。解脱には時間がかかりそうです。)

アジャイルソフトウェア開発宣言
私たちは、ソフトウェア開発の実践 あるいは実践を手助けをする活動を通じて、 よりよい開発方法を見つけだそうとしている。 これらが私たちの価値と原則である。

次の本

次は何にしましょうか。私としてはここらが候補です。

  • スタッフエンジニアリング
  • 失敗しないシステム開発のためのプロジェクト監査

コメント

タイトルとURLをコピーしました