2章 パターナリスト症候群

2.1　安全装置ではなく障壁を作ってしまう

これは本当にあるあるなんだけど、気づかないことが多そう。。。

運用だけの話じゃないよな。。。って思ってきた。。。

どんなテクノロジでも、優先順位付けのプロセスにある問題の解決はできません。

これ金言だな。

そう思います。ヒトの問題でもAIとか使いこなせていけばなら、組織的に比較的マシな順番とか出来ないでしょうか。

CAMSモデル知らなかった…。

2.2　ゲートキーパーの導入

事故が起きると、責任者作りたくなるのかな。

後天的な慣習だとおもうんですが、先天的に日本人やアメリカ人に刷り込まれているんじゃないかって疑いたくなるレベル。。。

2.3　ゲートキーパーの分析

問題を防ぐことを優先して、他の組織の迷惑かかるとかありそう

監査対応とか

この辺の話いろんな管理者に読んで欲しいと切実に思った。システムだけじゃなくていろんな業務でおきているなー。

2.4　自動化によるパターナリスト症候群の解消

一度にすべてに取り組む必要はありません。もし簡単に解決できる問題が見つかったらすぐにそれを解決しましょう！

この精神大事だよな。意味のないことをやっているってとらえられないように、ROIの高いことに注力するのが大事なんだと思う。

監査しかり、必要だけど儲からないは理解されづらいですね

こういった要求を上層部に伝える際には、チームが期待する効率の向上だけでなく現在のプロセスの不十分な点も強調するようにしてください。

こういうアドバイスめっちゃ有用だな。

良さそう

2.5　承認の目的を把握する

承認者は孤独だから、いろんな視点のドキュメントを要求するのか。

不安だっていうのはあるでしょうね。自分で手を動かすわけでもないし。

2.6　自動化のためのコードの構成

変更のリスクが許容範囲ってのも承認者（１人）の責任になるの？

JIRAは高機能すぎて、見た目が…。

プロセスを一貫化すると監査役にランチが奢ってもらえる。やっていきたいw

ログをのこしておいてそれはチケットにはられていくっていうのは大事だなーっておもった。

Python？のコード例がうまくようやくしてくれている感じがした。完全な実装？のサンプルコードってGitHubで公開されていたりしないのかなぁ。今回の例だと例えば、GitHubでPRに対してReviewがOKとついているとかをチェックするみたいな感じだと思うんだけど。

2.7　継続的な改善に向けて

2.8　本章のまとめ

みんなからのコメント

実践する/伝えるためのハードルはなにか？

ツールを作る？

承認者を悪くしない組織？

最初に自動化を考えるっていう癖がないとか？

一緒に使うと良さそうなプラクティスやマインドセットはなにか？

スクラムの完成の定義とあわせると、自動化しやすくなるっていうのはありそう。

ハードルの乗り越え方はなにか？実践/伝える方法はなにか？

1日くらいで実現できそうな簡単な事例の紹介

ハッカソンの開催

どれくらい効果がありそうか？

同じように承認プロセスの具体的な改善を考える人が増える

社内で改善したいという動きが経営陣に伝わる

２、３年後にはうまく変わるかも？