人の問題を片付ける.then(コーディング)

ルーティンワークを自動化する技術を持っていても、そのスキルを活かす場を先に作る必要があるよね、という話です。

私の場合は、ひとりエンジニアなので、関係者に話を通すのも自分でやります。今日はそのへんのことを少し書きたいと思います。

ルーティンのある風景

昨日は、月一ぐらいでやってくるイレギュラー曜日ルーティン。

普段月曜日はルーティンワークなしで、おやすみの体（てい）にしており、基本は勉強の日にしてますが、ときどき週単位のスケジュールで変更が入るとそういうリズムを崩して対応します。

何年かかけてWeeklyのルーティンで、かつ、相手がいて時間帯が限定される作業は極力コンパクトにまとめるように努力してきました。

その甲斐あって今は、
i）午前中いっぱいを週に２回と
ii）数分程度の夜作業を週に１回
これをこなせばOKというところまでたどり着きました。

この固定ルーティンをこなすと、月間の固定収入の半分くらいを確保できます。これは結構大きいですよ。

手を離したいという野望

でも野望は尽きずで、いま時点では自分もオペレーションの流れの中にあるノーマルな作業をタスクとしてこなしています。それがあるので『時間を合わせて』という条件が組み込まれています。これをなんとか外したい ＝ イレギュラー対応だけに絞りたい、というのは前々から思っていて、去年（2018年）くらいからコツコツ準備を始めました。

準備のほとんどは『人の問題』の解決でした。プログラムを変更する前に、プロジェクトの在り方を見直す必要がある＋結局ハンドリングする担当者も一部は変えざるを得ないとわかりました。

そうすると、

・お金の問題

・契約／信用の問題

・リソースの問題

・モチベーションの問題

・知識／経験の問題

などなど、これ全部ひっくるめて『人の問題』と言いますけど、こういうのをとことん解決しないとコーディングにたどり着かないと覚り、去年アイデアを思いついた年末付近ぐらいから今年の夏前ぐらいまでは、関係者間の調整に重点をおいて動いてました。

いざコーディングへ

今年の夏ぐらいからちょこちょこアイデアをコードに反映できるようになってきました。例えば、顧客から新規の要望があったら、既存のコードに変更を加えるのは最小限にして、要望を実現するために必要なコンポーネントのうちの大部分を別リポジトリへ分離して作成するというようなことですね。すごい単純な話ですけど。

この秋から年末年始ぐらいにかけてはプログラマ的に「やったるぞ」というガンバリング期間に入ります。人間同士の話し合いは「別にもう話すことないでしょ」と個人的には思っているので、あとはがつがつコードを書くだけです。

でもね。いざ、「オペレーションが変更しますよ」「その仕事はこの人に渡しちゃってくださいね」というフェーズになるとポロポロと細かい問題が発生するんですよね。そんなことは重々承知のつもりなんですけど…。

がんばろ。