まじでこれはいい本だ
読み始めたきっかけは、クラウドワークスエンジニアブログにあったtmknomさんの 「無人化システム」を駆逐する組織マネジメントとエンジニアリング の記事だ。組織論の話なのかな？と思わせるタイトルだが、「システム思考」などの理論を説明している部分が主だ。
（まだ全部読み切ってない段階でこんな記事書くなよ！って感じだけど、とりあえず書くｗ）
自分は、↑「なぜあの人の解決策はいつもうまくいくのか？」を読んでから、学習する組織を読み始めている。いきなり学習する組織を読むと、かなり面喰らうんじゃないだろうか。どちらの本も似たようなことを書いてるんだけど、「なぜあの人の・・・」のほうが具体例が身近でわかりやすい。
読んでいて感じたこと
国語力が皆無な自分ながらも、感じたことをいくつか書いておく。
スナップショットで判断するのではなく、時間をかけてシステム理解をする
暫定対処を重ねたうちに、本当にやりたいことをやりづらくなり、身動きがとれなくなった。
みたいなことはまれによくある。
- 動きがよくわからないコードをベースとする機能改修で「とりあえずコピペ」してリリースした。
- しばらくしたらバグったので、if文を追加して今回の機能改修部分だけを特別扱いした。
- しばらくして別の機能を追加するときに・・・（以下略
ソフトウェア開発を仕事でやっていると、よほど意識が高い集団でもない限り、こういう現場を目にすることは多い。
この問題は多くの場合、要件をあらためて理解して、合理的な設計部分を少しずつ増やしていき、啓蒙を重ねていくことで解決に向かう。しかしながら、多くの現場ではそれがされないまま、コピペプログラミングとif文追加による複雑化という悪循環が10周20周と繰り返される。
本には色々書いてあったが、まず問題が複雑化するという1循環を認識できているかが１つ大きなポイントなのかなと思った。
たとえば、設計に無関心でも、とにかく動いてテストが通ればリリースができる某スマホメーカーのようなやりかたでは、なんとなく期を重ねるごとに開発効率が落ちているという感触は得ることができても、それに対する問題認識ができないだろう。
根本原因の本対処と暫定対処はセットで考える
自分がこれまで8年くらいソフトウェア開発をしていて、どうしても時間的制約などから暫定対処を考えないといけないことは多かった。そのときに、経験したのはだいたい以下のどちらかだ
- 実は時間的制約はあまりなく、暫定対処をやめて最初から本対処した
- 本対処を後回しにした結果、暫定対処のコードで3年以上運用されることになってしまった
「暫定対処したあと、後になって本対処をした」ということは、残念ながら数えるくらいしか無い。
本には書いてあるが、暫定対処は本対処に対する副作用を持っている。ソフトウェア開発であれば「暫定対処で乗り切った」→「本対処をし直す・・？まじで？」という心理的な障壁が、些細なものではなく割と大きい。つまり、暫定対処からの本対処という線形的な流れになることは非常にまれで、暫定対処と本対処の"二者択一" となってしまうケースが圧倒的に多い。
課題が認識できていて、本対処と暫定対処の両方が明確である場合にはまだいい。
問題は、「原因があまり認識できていないまま、本対処もよくわからないまま、暫定対処で乗り切る」というケースなのかなと。自分はわりと場当たり的な対応をしてしまうことが多いので、今後気をつけていかなければ、と改めて感じた。
進捗だめです...
なかなかのボリュームゆえ、まだ27%
お正月休み中に読み終われるかな...
