業務フロー

単純化では限界までsimpleになっていることが大事

米国海軍発祥。Keep it simple stupid「シンプルにしておけ！この間抜け」の略語。

You ain't gonna need it「機能は実際に必要となるまでは追加しない」という原則

コードをすばやく実装するために最も良い方法は、あまりコードを書かないことである。そして、バグを減らすために最も良い方法も、あまりコードを書かないことである

標準化しないと…どうなるか？

人、タイミングなどによって、業務にかかる時間にばらつきが生まれる

人によって、成果物の品質にバラツキが生まれる

その作業ができない人が生まれる

業務フローでしっかり整備した方がいいところ

実施頻度が低いものほど、しっかりマニュアルを整備する（月一・週一だったら、絶対）

人の記憶を信じない業務設計を。

週一。であっても「前言われた注意事項」を忘れていることがあります。

月一ならばなおさら。

「前も注意しましたよ…！」というのが多発する

マニュアルを整備するときは、「イレギュラー」は絶対想定しておく。

想定外はほぼ100％起こる

「人が行うこと」「社外の人と協力して行うこと」「自然現象に合わせて行うこと」はまあイレギュラーが起こる

イレギュラーを想定しきれないので、「問い合わせ窓口」は必ず用意する。

一度作った業務フローが「そのまま使い続けられるもの」であることはない

関係者、ユーザーが増えると「突拍子もないやり方」をする人が出てくる

「予期せぬcost」を防ぐために、マニュアル・運用ルールを作る

対応者の集中力（思考resource, 注意力）を不必要に削がない

考えてもらう必要がないならば、「考えないで出来る」ようにする

対応者の時間を要さない

「意思決定」をさせたいのであって、「操作」をさせたいのではない

「承認」のために、10clickもしないといけないならば、問題

具体的にマニュアル・運用ルールで大事なのは

「最終成果物」を具体例で提示すること

申請書であれば、全部記載された状態をスクショで貼り付けると良い。

完成品をimageできると、人は動きやすい

注意点は最小限にする

独自ルールは避ける。必要なルールは最小限にする

インタフェースの2つの要素が互いに矛盾あるいは不明瞭だったときに、その動作としては人間のユーザやプログラマが最も自然に思える（驚きが少ない）ものを選択すべきだとする考え方

ルールではなくモラル・ポリシーを設定。記載する

https://gyazo.com/0cf9e2a1623a6c82d38bfab37f27c70b

https://gyazo.com/626ae7c11f46b147b2856a6fa9ac6ea2

「よくある間違い」は理由と一緒に記載しておくと良い

（自然にやった時の間違いパターン2,3個だけで良い。）

業務フロー作る上で意外に大事なのは

マニュアルを作る前に「運用フロー図」を大きく作成し、「各システム・担当者にかかる負担が適切に分散しているか？」を先に見る（数が10倍,100倍になっても対応できるか？）

十分「業務フロー」「そもそも必要な業務か？」がしっかり検討されていないものが、そのまま利用されているケースも多い

今の状況に合わせてupdateしないと負債になる

個人的には「業務フロー」は細部までしっかり検討した上で「王道（基本的なやり方）」は定義してあげるべきだと思っている。

定義しないと…品質・対応スピードが担保されないことが多い

担保されない分…「最後に無理くり頑張る人」に負荷がいく。

「最後に無理くり頑張る人」は、その領域のキーパーソンである確率が高い。

えてして、そういう人は他の領域でもキーパーソン。つまり、多忙になりやすい。

多忙になっても…業務フローがないため、他の人は「多忙な人の対応を待つ」しかできない。

「業務フローを定義する」のは面倒だし、一度定義すると「そのままやり続ける人が出そう」というのはわかる…が、

総コスト（定義後に発生するイレギュラー対応コストなど）で考えると、全然お得

業務フローになっていることで、「業務の可視化」はされているため、むしろreplace（変更）がしやすい。（フローになっていないと、「Aさんしかできない属人的業務」であることも多い）