失敗の科学　失敗から学習する組織、学習できない組織
https://amzn.to/3C2WNJd

かなり面白い本だった。
How to 本ではないところがいいところだったのかも。

大小様々「失敗」はあるわけで、それをどのように扱って次につなげていくか。

仕事をしてれば単純なミスや漏れ、ヒヤリハット的なものや、それこそ報告書レベルのものから色々あるわけだけど。
それをどう共有・察知して、どのように捉えて、そこから改善していくといったところかな。
なにかしらの手順を決めたり、システムを作るなり。

確証バイアス的な、原因の決めつけとかが改善するための足かせになることもあるだろうし。

失敗は何かしらあるという前提で、検証と改善を繰り返すというのは、アジャイル的な発想なんだろうと思うのだけど、それを普段の仕事にどのように取り入れたらいいのか？を考えるきっかけになった気がする。

受託開発だけどアジャイル的な進め方。
契約で言うと準委任的な感じなんだろうけど、依頼側はそれだとなかなか判断しづらいとかあるのかもしれない気がするけど、どうなんだろうな。

あらかじめ検証をしておきつつ開発をすることで、懸念点を把握・解消しておいて効率よく開発ができたり。
リリース検証を複数回こなすことで、より確実に本リリースをできたり。

どうしても仕事だとミスはできないので、安全策をとったり。
責任を負わないための言質をとるとか、進行上仕方ないところもあるのかもしれないけど、もっと広い視野で見たときにそれが最適な進め方だったのか？とかは再度考えてみてもいい気がした。

仕事だから仕方ない所もあるのかもしれないけど、何かしら目的があっての仕事なわけだから、そこの認識をクライアントとかと共有してやれるといいんだろうなぁ。

ウォーターフォールよりアジャイルというわけではなくて、アジャイル的な考え方を取り込みつつ、進め方を小さく改善しながら、いい成果物を作っていくような。

ある程度の道筋の参考は探しつつも、自分のスキルアップも失敗の積み重ねだろうし。

自分たちのチームのやりやすいやり方と、他のやり方を参考にしていきたいところ。

日々の経験で得る物もあるだろうけど、まだまだ経験できていないこと、知らない方法の方が遙かに多いから色々と試してみるなどしていかないとなぁと思えた。