新しい仕事に着手する場合は、
前任者がいれば、その方から、引継ぎを受け
引継ぎ期間中にメモを書きまくって、前任者の後を
金魚の糞のようにつきまとい、仕事を覚えます。
１W弱で、引継ぎ期間が終わり。
「XXさん、あとは、よろしく！」で前任者は去る。
（銀行なんかでは、引継ぎがたった二日という話も聞いたことがある。）
メモを何度も見たおして、実際に前任者といっしょにやった
記憶を掘り起こしながら、一人で進めることになります。
業務手順を書き出し、読み返す。
実際にやると最初は、必ず”抜けがでる”ので、
業務手順書にチェックしながら進める。
それでも人間なので、１００％ノーミスでやりきれません。
ミス／抜けもれがあれば、
POST＿IT「XXやるときはYY忘れるな！」と書いて
壁に貼り、次の業務の際に、目を通すようにします。
何とか業務がこなせるようになってきたら、
次は、この業務は、いま、やるべきことか？
時間のスキマを使って後でやっても問題ないのでは？
といった形で、業務の手順を最適化していきます。
業務がこなせるようになるまでは、
ちょっと早めに会社に入って、
・記録ノートを見ながら手順通りに１つ１つ業務を進める。
してましたが、１カ月２か月経過して習熟度が上がってくると
・これは、今、やるべき業務か？
すき間時間や業務の終わり間際まで
後ろ倒ししても問題ないじゃないの？
という自問自答を繰りかえすと
少し早めに会社に出勤して段取りしていた
業務を開始する時間をあと１５分２０分遅くしても
別にどーってことねーだろう。。
前倒しした１５分２０分に対して会社は給料払ってくれないし。。
そーやって、地道な時短作戦をやっていきます。
昔さんざんやっていたプログラムの最適化
＜最初のプログラム＞
・まずは、ちゃんと１～１０まで動き、
目的とする結果が出るようにする。
＜プログラムの改善、リファクタリング＞
・その処理は、今やる必要があるのか？
今やると処理コストがかかり速度低下を招く。
後回しでもいいんじゃないか？（処理の後回し検討）
ー＞プログラムのプロファイリングをして
ー＞全体を俯瞰して：
ー＞どこに時間がかかってるのか特定
ー＞呼び出し回数が多い関数をリファクタリング
ー＞関数のネストを浅くする。
ー＞関数をINLINE化して、そもそも呼び出しコスト削る。
ー＞そこでやってしまうと、速度低下を引き起こし、
ー＞わざわざ、くそ真面目にやらなくてもいい処理は、
ー＞極力、時間の合間や、ぎりぎりまで後回しにする。
プログラムは、構想設計・詳細設計という段階を踏みます。
仕事の引継ぎは、手順を教えてもらい、ひたすらメモを取るという段階を踏みます。
分野の違いはあれど、、実行手順の初期段階がFIXした後の
効率化・最適化という観点では、あまり、差異がないような。。感じもします。
結局、「はやっているDX（Digital Transformation」
（このキーワードは、”何かっこつけてんやーー”と気に入りませんが。）
業務手順等でパソコンで実行できるものは落とし込み、時短を
狙うものでないのか？（個人的見解）
今やっている仕事は、パソコンに落とし込むことはできませんが、
プログラムの時短化、効率化という発想自体は、応用できそうな気がします。
プログラムをがりがり書いてた時の経験してきたことは、
業務の効率化と似たものがあり、経験は、無駄ではありませんね。。
では・・また・・：＿；）／
