【まとめ】プログラマーが愚直に仕事を進めるための方法

最近、精神的に大変な仕事とか、プライベートでやっているイベントとか、いろいろ重なってしまって大変でした。

私は全く器用なタイプではなく、複数いろいろやっていると、例えば「他の仕事のことが気になってこっちの仕事もなかなか進まない」というような負のスパイラルに陥りがちでした。ただ、大変だった中で他の方からのアドバイスで学んだことや、「これじゃいけない」と思って諸々の本を学んで、多少マシな状態にはなりました‥いや、多分なったと思います（笑）。そこで、最近似たようなことで悩んでいる人もよく見かけるので、軽くまとめておきます。

私を実際に知ってる人が見ると、「いやいや、お前言うほどできてないじゃんｗ」って思われるかもしれませんが、後でこっそり教えてください。

すべてを実験だと捉える

プログラミングの仕事を進めていると、どうしても仕様が明確でない、後から修正しなくてはいけないことがあります。 100%想定通り進むことは絶対にありません。また、チームの他メンバーと常に認識を合わせることも、ほぼ不可能だと言っていいでしょう。

それなら、我々には「想定外のことが起きませんように」と祈ってるしかないのかというと、そうではないはずです。

確かめたいことに対して、「サーバーが突然落ちないかどうかは負荷テストの段階で（可能な限り）チェックしよう」とか、「（非プログラマーとややこしい仕事するとき）用語についての認識の齟齬が起きやすいので、定例ミーティングで確認するようにしよう」とか、できるだけ早い段階で実験して拾えるように工夫しましょう。

ありがちなのが、他の人に渡すドキュメントをまとめる際に、「すごく詳細にまとめてるけど、これって欲しい情報じゃないんだよね」って言われ、複雑な割に「使えない」ドキュメントになってしまうことです。こういうのは、「目次」を作った段階で相手にそれとなく「今こういう方針でまとめてます」って相手にチャットして、大まかな方針レベルで問題が無いのか「実験」しておくようにしましょう。プログラムの場合は実装方針とかクラス図とかのレベルですかね。

ちょっと余談ですが、知り合いのデータサイエンティストが「開発先とのやり取りで多目的最適化のソルバーを使っている」「最初に出てくる仕様だと最適化問題の目的関数がちゃんと決まらないことがある。その時に多目的最適化で考えられる解を実際にいくつか出して議論すれば、何を優先するのか決められる」と言っていました。私は今まで単に「多目的最適化は解が一つに決まらないので自動化するプログラムで使いづらそうだな」と思っていたので、専門知識を活かしてうまく『実験』していたことに驚きました。

タスクを実験だと捉えると、いきなりうまくいく方法が見つからなくても、

1. 「こうすればうまくいくんじゃないか」という仮説を見つける
2. 「仮説が正しい」を証明するための実験（テスト）計画を作る
3. テストを実行する

ことで愚直に進められるので、少なくとも全く身動きができなくなることは無いと思います。仮説が正しい場合、安心して実装していい範囲が広がり、間違っている場合でも仮説を修正してリトライすればいいだけです。

タスクを全部書き出す

私のように「他の仕事が気になって進まない」という状況になりがちな人は、ツールに頼って、「ここを立ち返ればとりあえず見落としがない」ような状況を作って、頭の中から一旦全部追い出してしまうことです。おそらく理想は、一人ひとりに『秘書』がいることだと思いますが、少なくとも現在ではそれなりに偉い人でないと難しいでしょう。

最近私が「いいな」と思っている方法は、以下のやり方です。

1. 自分が「気になってること」をとりあえず全部箇条書きにする（例えば「毎朝」くらいの頻度で）
2. そいつの中から「今日やるべきこと」をピックアップする

これだけで、「とりあえず今やるべきこと」に集中しやすくなると思います。また、書き出す前には仕事の把握だけで無限の時間がかかるように思われる場合でも、実際にはひとつずつ潰していけばなんとかなることが分かることが多いと思います。

ところで、最近発売した『エンジニアの知的生産術』で紹介されていたGTDという方法が、これをもっと詳しくしたようなやり方だそうです。ただ、自分自身の性格や特性は人によって違うので、いろいろと実験して修正していく必要があるはずです。

エンジニアの知的生産術 ──効率的に学び、整理し、アウトプットする (WEB+DB PRESS plusシリーズ)

全面改訂版 はじめてのGTD ストレスフリーの整理術

『エンジニアの知的生産術』を見ていて一番面白かったのは、「やる気の出し方」として「タスクを分割する」ことがまず書かれていたことです。 こういうのは（自分でも他人でも）本人の努力の問題にしがちですが、できるだけシステマティックにやってしまったほうがお互いに安心できると思います。

インターフェイスを取っ掛かりにする

プログラミングのアドバイスを受けているときに「先輩が言ってる方針ってうまく行きそうにない/そもそもよく理解できないけど、なんでこういうこと言ってるのかな？」って疑問に思い、さらに質問してもよく分からない返答が返ってくることも多いと思います。後から考えると、それは大きく2つ理由がありえると思います。

1. 自分が「当然伝わってるだろう」という前提が伝えられていない
2. 相手が対象について深いレベルで理解していない（更にそれを自覚できていない）

この辺の違和感を感じた時は、100%ではないにしても、実際に何か問題があることも多いので無視しないほうが良いです。なんとか対処しましょう。調べてみるとしょうもない思い違いや勘違いであることも多いですが（笑）。

①については自分の問題なので、「前提条件で伝わってない部分があるのか」を愚直に確かめていけば大丈夫だと思います。まあ大変ですががんばりましょう。

ただ、②の場合も、相手がかなり優秀な方でもけっこうありえるので困りますよね。自分自身を振り返っても「ちゃんと分かってないことが分かってない」ことは滅茶苦茶あったと思います。その場合は自力で勉強するとか、同じ質問を他のもっと詳しそうな人に質問するとか、なんとか工夫して勉強する必要があります。（だから、私は相手がわけわからない質問や、「それって当たり前じゃね？」と思うような質問をしてきた際にも、少なくともバカにしたり「デキないやつ」みたいなレッテルを貼らないようにしようと思っています）

特に、技術関連だと「オブジェクト指向」とか「設計のベストプラクティス」とか「静的型/動的型」の話題とか、その他だと「人事制度」とか「技術教育」とかの話は、相手が自分の経験したことのある範疇の話しか話ができないことが多く、割と地雷が多い（他人に頼って知識をつけるのが難しい）と思います。もしそういうところまで、自分の知識の限界を知りつつ論理的に話できる人がいたら大切にしましょう。

自分で勉強する場合は、以下の2点のどちらかに注目して調べていくと良いと思います。他人に教えて貰う（質問する）場合でも、ここをとっかかりにして議論を始めることができるでしょう。

1. その技術を使うときのインプット/アウトプット
2. その技術が作られた目的や経緯

ここに調べていくと、「〇〇は××という目的のために作られたでライブラリある」ということがわかり、××について調べると「他にも△△というライブラリがある」「実は自分の目的のためにはそっちのほうがいい」みたいに調べられて、最初の取っ掛かりはつかめると思います。

インプット/アウトプットが同じで、自分の目的に合っていれば、「他のツールやライブラリ差し替える」「どちらが良いか検討する」というような発想ができるようになると思います。こういうのってちょっとポリモルフィズムっぽい気もしますね。技術以外でも、同じような発想で「普段かかわらない相手と仕事するのでその分野を勉強しなきゃいけない」ような状況で、最初の取っ掛かりを掴めるかもしれません。

知識が足りずに身動きのとれない状況が減る（少なくとも勉強しなきゃいけない箇所や、質問すべきことは分かる）と思います。

多少は強引に進める

最近、「必要以上に全員の合意を取ろうとしてブロックしていることが多いのでなんとかしてほしい」と先輩から言われて反省しています。問題が無い場合でも全員にOKもらわないと先に進めないので、単純に効率が悪いと言われ、その通りだなと思ってしまいました。

単に「（チームメイトが）問題が無いので静観している」ような場合もあるので、「とりあえず今出してる案で問題あれば出してください。無ければ○月×日までで一旦出しちゃいます」。もしそのときに無茶なことを言ってしまっても、周りから「いや、それじゃあ期限がカツカツすぎるから後3日くらい欲しいよ」みたいにツッコんで貰えるはずです。

もしかすると、自分がすごく偉い立場で、周りを萎縮させている場合には「え？リーダーが○月×日までって言ってるなら間に合わせなきゃ」って無理させてしまうかもしれませんが、今の所私はそうではないので考えていません（笑）。

他に、私の場合は「（割と慎重すぎるタイプなので）もうちょっとスピード重視で進めちゃっていいよ」と言われ「じゃあちょっとクオリティ下げて進めるか」と思って、ちょっとプログラムが雑すぎると怒られることもありました。その時分かっていれば良かったのですが、実際にはスピード重視 OR クオリティ重視の二者択一であることはあまり無く、上のように「チェックしてもらう期間を決める」みたいにどちらも担保できる方法は割と考えられます。

ただ、試行錯誤している間（つまり人生のほとんど）は、多少痛い目を見るのはしょうがありません。こういうときにちゃんと仮説を持って「これは実験だ」という意識があると、後に活かせるので多少前向きになれると思います。

自分自身の特性を知る

自分自身の特性を知って、苦手分野をシステム的に、もしくは周りのチームメンバーとのやり取りでカバーする方法は身につけておくべきです。

例えば、大勢と交流するとエネルギーを貰うタイプとか、逆にストレスを感じるタイプとかいます。例えば、私は社内行事で集団行動すると正直かなり疲れる（一応言うと苦手な人がいるわけではありませんｗ）のですが、違うタイプの人が多い環境にいると、自分の性質が分からずに無理してしまうことが多いように思います。そういう性質と対処法を知るために、次の本が役に立ちました。

片づけられない人のための仕事の本

プログラマーという世界だけに限ると、（きれいに分かれるわけではないし、他人へのレッテル貼りにもなりかねないので危険ですが）ADD/ADHD的な性質を持つ人が多いように思います。

この本では、3つのタイプに分けて、ADD/ADHDについて3つのタイプに分けて、それぞれの性質や対処法について説明しています。私は割と②のタイプが参考になりました。

1. 多動が目立つタイプ
2. 内部で混乱してるタイプ
3. 枠組みに頼って生きてるタイプ

もちろんADD/ADHD的な性質の人だけじゃないし、この本のタイプ分けもざっくりしているので、これだけで自分や他人を分かった気になるのは危険だと思います。

ただ、世間一般を見ると「この人、特定の枠組みに頼りすぎてるな」とか、自分自身の性格や性質に合わないやり方を無理にやろうとしている人が多いようには思います。私の場合は「物覚えが良い方じゃないのに、（すごい知り合いのエンジニアのやり方を無理に参考にして）タスクの管理方法を考えずに仕事に着手してしまう」ようなことがありました。人それぞれ、自分自身に合ったやり方を身に着けていく必要があります。

まとめ

一番危険なのは「現状を把握できてなく、どこから着手すればいいか分からない」ような状態だと思います。上の考え方なら、とりあえず試行錯誤して先に進め、少しずつ改善できるようにはなるはずです。少しずつ改善できるなら、まあ数年後にはそれなりのものにはなっているはずです（なっているといいなあ！）。

それでは、お互い無理せずがんばりましょう。