2020/03/16

増やす仕事、減らす仕事

仕事には増やす仕事と減らす仕事がある。減らす仕事は時間とコストを節約し、余白をつくる。増やす仕事は新たな仕事を増やし、可能性を広げる。

増やす仕事は減らす仕事がなければ成り立たない。時間に空きがなければ考えられず、作れず、生み出せない。減らす仕事は余裕を作り、自動化し、効率を上げる。

増やす仕事は効果が指標になる。効果的でなければやめてよい。増やす仕事は実験的であり、不確実であり、今までにないことを試す。増やす仕事がなければ何もパイが大きくならない。減らす仕事は地味だ。できることは変わらない。今できていることを、もっと簡単にできるようにする。変化を簡単にする。

---

一日の仕事を考えるとき、増やす仕事と減らす仕事の割合を考える癖が昔からある。いつからかは忘れてしまった。この仕事は価値を増やす仕事で、こっちは片付けの仕事だと考えていた。増やす仕事に費やす時間を増やさなければエンジニアとしての価値はないと思い、ひたすらにできることを増やした。

次第にシステムの面倒をみていくと、自他問わずつくった機能が期待しない動きになっていたり、変更がしづらくなってくる。溜まったデータも使いづらい。新しい機能を足すには複数箇所を直す必要がある。そうしたものを空いた時間で直す時間が次第に増えていく。既存のものを読み解き、理解し、再構築することはパズル的な興味深さがある。

自らの仕事を振り返るとき、増やす仕事と減らす仕事は2対8程度の割合になってきた。8割が準備である。8割は次の動きを早くするために時間を費やしている。コードを書くだけじゃなく、プロセスを変えたり、ルールを変えたり、やることを自体を減らしたりする。それによって明日の時間を捻出し、ようやく増やす時間にあてる。

---

チームを構成する上で、増やす仕事と減らす仕事は個人のなかで回るとよいと考えている。自らの工夫が自らの時間を作り出し、新たな増やす仕事に当てられるようになる。そうすると信頼が集まり、より大きな増やす仕事に踏み出していける。個人個人の単位でこれが回るようになっていると、日々の洞察力があがっていく。

この状態になると、明日はこれを改善しておき、三日後には別部分に時間を投資できる、といった判断につながる。自分の時間を投資する判断を毎日することは、自分の効率を知ることだ。仕事をしていると言って作業をしているだけであるのと、自ら投資効率を考えて増減の何を制御してるのかを見ながら作業するのとでは効率の改善具合が変わってくる。

ここ1ヶ月弱のリモートワーク環境下においては特に、これが個々人で回り続けているかどうかで効率が特に大きく変わってしまっていると感じている。減らす仕事によって生み出された時間で、増やす仕事をするサイクルにはいれているかどうか。今日は何を減らし、何を増やせたか。自分でも改めて振り返る機会になっている。

2020/01/15

事業におけるソフトウェアエンジニアリング

最近自分のやっていることはなんなのだろうか?と思い返す機会が増えた。次のことをやっている。

* 広告に関連するWeb周辺技術の動向やらリサーチをしつつ
* アプリケーションが長期に渡って安定し拡張可能になるように設計するのを手伝いつつ
* サブシステムの分割がいい感じになるように相談にのりつつ
* 事業で中長期に渡って伸ばしたい領域を決めて技術的観点からコミットする

基本的には事業がうまくいけばよく、そのために採用やら面談やらチームづくりやらツール選定やらが紐付いてくる。働き始めて3,4年ごろはもうちょっと自分の市場価値を強く意識していて、あまり自分の価値を伸ばさなさそうな仕事には手を出すのをためらうふしがあった。今はそれよりも必要なことを必要な仕事としてやる、というスタンスになっている。

特定技術領域には当然弱くなっていくし、どれも深く入り込んでいくよりは他の代替手段を効果的に使っていくほうがレバレッジが効くことも増えた。中にはどうしても性能要件を超えるために細かなチューニングが必要になる場面も発生するが、案外単体のソフトウェア性能だけではなくて事業上の制約を変えることでこれを解決することもある。単体のソフトウェアで解決すべき課題はスコープを絞り、難易度をなるべく下げて解決可能な課題に落とし込む。そういった工夫のほうがうまく事業を回すためには効果的なことが多い。

ソフトウェア単体を堅牢に書く技術は年々ついてきた。これは単体テストを書こうとか、Observabilityを高めて複雑なシステムの故障に早く気付けるようにしようとか、技術的なアプローチに習熟している面もある。ソフトウェアにおける堅牢さとは読みやすさであると思う。読みやすさはTestabilityに繋がり、何が起こっているかをチームに理解させる力になる。読みやすいコードは自明であり、そのソフトウェアが何をすべきかをわかっていないと生まれない。リファクタリングが別の工程になるとうまく行かないのは 感覚的にも正しく、思考のループの中で洗練されたコードになる。これがチームで生み出せるとどんどんよい方向にソフトウェアが改善されていく。

事業におけるソフトウェアエンジニアリングとは細部でみれば上記のような観点があり、これらはすべてリスクコントロール手段である。良いソフトウェアがかけるならばトライが増やせる。トライをする意思決定がしやすくなる。ソフトウェア、あるいはWebサービスが長期に渡って動くために、CI/CD・Testability・Observabilityへの投資は常に効果的で、高速に変更を重ねる文化はすでにできている。チームのScaleを確保するのはいつでも難しいが、同じ人数でもスループットが増えていくのは自分たちもまたソフトウェアの力によって加速が可能な構成になっているからである。

日々の仕事がリスクコントロールであることは、ソフトウェアに限らない。すべての仕事は決めることを決めることだ。それが当たり前になってしまっていて、なかなか言葉にするのは難しい。

2020/01/06

2020年に読んだ本

2020年に読んだ本をまとめておく。随時更新。

2019年
2018年
2017年

最終更新 2020/01/06

小説

失われた地平線 (河出文庫) (日本語) 文庫 – 2020/1/8 James Hilton (原著), ジェイムズ ヒルトン (著), 池 央耿 (翻訳)
* アンドロイドは電気羊の夢を見るか? フィリップ・K・ディック (著), 浅倉 久志 (著), カバーデザイン:土井宏明(ポジトロン) (イラスト), 浅倉久志 (翻訳)

技術書

その他

* 5Gワールドへようこそ! Kindle版 日経 xTECH  (編集)
考える旅人 世界のホテルをめぐって (わたしの旅ブックス) (日本語) 単行本(ソフトカバー) – 2019/5/22 山口 由美 (著)
最後の秘境 東京藝大―天才たちのカオスな日常―(新潮文庫) Kindle版 二宮敦人  (著)