仕事のうだつがあがらない問題に対処すべく、会社員技能について基本に立ち戻って見直そう、本でも読んで考えを整理したい、などと考える。

けれどプログラミングとかソフトウェア開発の本を読もうという気になれない。残念。なぜかと考える。たぶんコーディング能力をちょっとあげたらくらいでは仕事の難関を超えられる気がしないからだろうな。世の中にはコーディング能力がボトルネックになる仕事は割とあるし、圧倒的にコードがかければ多くの問題をその力で片付けることもできる。ただ自分の目の前の仕事はそうではない・・・つまり漸近的なプログラミング技能の改善が仕事の生産性に直結していない気がする。ドカーンと書けるようになれば別だけど、そういうことはおきないから。

それじゃジコケーハツでもしますか、というと・・・悪くはないだろうけど、自分は既にライフハック的なのはやってしまっているので、大きな期待ができない。復習がてら軽く古典的なやつを読み直してもいいかもは思う。達人プログラマ的なソフトウェア開発者向け読み物にせよ、GTD 的な一般ライフハック読み物にせよ。

自分が弱いなと思うのは「何をやるか決める」あるいは「なにをやり続けるかを決める」みたいな部分。最近 Sam Altman が書いていた Productivity という記事でもそれが一番大事と言う。自分は別に起業家でも経営者でもない会社員だけれども、そんな下っ端にも何をやるか/やらないかのオプションは結構あり、選択は成果に大きく影響する。

これは最初になにをやるか決める時だけでなく、プロジェクトを続けていくなかで予期しないことが起きた時に舵取りの判断をする話でもある。進みが遅いとき、大きな問題が起きた時、壁を押し続けるべきなのか、方向転換すべきなのか、諦めるべきか。それを誰に相談してどう決めるか。こういう判断は日々フラクタル的に発生してるけれど自分は良い舵取りの指針を持っていない。

あとは他の人と協力して何かやるのもあまり得意でないなあ。頼んだことをきちんとやってもらうとか、利害関係を調整してなんかやるとか。今のプロジェクトはそういう場面が多く、手こずっている。それだけじゃないけれど。

やることを決めるとか関係者との協力とかっていわゆる leadership の文脈で語られることが多いけれど、自分は別に lead ではない。世の中の leadership 愛好家は肩書とは関係なく leadership はあるというけれど、やはりチームとか組織の責任をもってる人と individual contributor では権力や戦力の量(立場があると強い)や身軽さ(立場がない方が高い)が違うので、個人として人々と協力しつつ価値のあることをやる手口は leadership とは別に議論してほしい。しかし世はなぜか個人の生産性の話を lifehack ぽい方向に向かわせがちで、そうじゃなくて・・・と思う。

「問題解決」みたいのは近いといえば近いけれど、なんちゅうか、製品開発は必ずしも問題解決ってわけでもないのだよな。そして問題解決とかいいだすとだいたいプロセスとかに手を出しがちで、しかしプログラマとしての自分はそういうので成果をだしたいわけではない。そうことやってると Engineering Manager とか TPM とかになってしまうよ・・・。

起業家や management ではない。Leadership でもない。問題解決コンサル/TPMでもない。スーパーハカーでもない。が、言われたことをやるだけの純粋末端というわけでもない。世間のよくある肩書の隙間にいるのがソフトウェア製品開発の IC なのだ・・・というのはいまいち納得がいかない。そんな特別なものじゃなくてみんなやってるはずだし何らかの方法論はできてるはずなのだが。みんな leadership 目指して頑張ってるの？そんなことないでしょ日銭稼ぐのだって多少は頭使うでしょ...

きっとそういう議論をしてる人はどこかにはいるのでしょう。自分が仕事のインパクトみたいな会社員的な語りから興味を失ったまま何年も過ごしてしまったから見えていないだけで。真面目にやります。はい。

つまり: 古典を読み直しつつ、弱点を補う話題の読むものを探す。考えを整理する。

なんか同じようなことを数年おきに考えてるなーとおもったら初出は 13 年まえだった。やばい。進歩してない。ていうか 13 年前のほうがちゃんと会社員だった気もする。