How IT Works

プログラマーやっています。技術よりも人間学的なところが好きです。

禅プログラミング

きっかけ

最近の仕事は難しい仕事が増えてきました。

例えば、あまり触ったことのないプログラミング言語のコードを読んだり、新しい機能のレビューを任されたり、新しいプロジェクトの開発環境の整備を1から作るなどです。

全く知識がないというわけでないので、頭をひねったり、多少調べれば解くことができるのですが、QCDが安定しないのでさてどうしたものかなと考えていました。

前の仕事では1つ1つのステップを設定し対策案を実施し、うまくいったら次に行くを繰り返す方法を習いました。

仮定を立ててそれを実証することを繰り返していればいいよというのは科学的で正しいとは思うのですが、時間がかかりすぎるので、このやり方には限界がありそうでした。

そういう問題意識を抱えていたところ、たまたま禅の本を読んでいて「自分を観察(=瞑想)すると仕事が捗るよ」という内容を見つけました。

面白そうだなと思って何気なしにやってみると意外とうまくいって、問題に冷静に当たれるようになってきたのでそれについて紹介します。

実務でよくあること

横道に逸れる問題

何か技術的な調査をしているときに、このツールをNPMで入れたらいいんじゃないか、という話を見つけます。

思考停止でそれをいれると、エラーで動きません。原因を調べると、さらに他のパッケージがないとエラーが出て動かないとか、バージョンが上がったら不具合があるよという様々な原因が見つかります。

そういう指摘を検証してやっと動いた!と思ったら、当初の問題を解決するものではなかったりします。そもそもうまく動けばいいほうです。

こんな風に技術調査をしていると別の問題がどんどん起きて、最初の課題ではないところに時間をとられて、時間が溶けていたりします。

また、業務で使っているSlackでレビュー依頼や別のIssueが挙がっていて、そっちを見ていると思考が流されたり、割り込みが入ったりで、気づいたら何をしているかわからなくなります。

検索がやめられない問題

こちらも技術調査でとにかく不具合があって直さないといけないということがあります。原因はとりあえずライブラリにありそうというケースを考えます。

最近だとStack Overflowに出てくるような問題の解法はあまりなく、どちらかというとGitHubのIssueにあることが多いです。

しかし新しいバグを踏むと、Issueで議論中で結論が出ているような出ていないような状態で放置されていたり、人によって違うことを書いていたりします。

こういう時に検索すれば答えがでるかもと思って調べていると、永遠に答えが見つからず辞め時を失うことがあります。

コードを見ればわかるといえばわかりますが、どれぐらいそこにコストがかかるのかを考えるといい塩梅というものがあるはずです。

禅の正式な定義は知らないので何となくで言葉を使っています。マインドフルネス、瞑想、ヨーガとの違いはこの際、聞かないでください。この記事についてはすべて同じ意味で置き換えてもいいと思います。

シンプルに「自分の考えていること、自分のやっていること、自分の体の状態をすべて正確に観察するように努める」という意味でとらえてください。

具体的に言うと、自分がいまどういう感情なのか、自分が何に集中しているのか、その時体に変化はあるのかということに意識を置きます。

もう少し細かいことについてはこれから書いていきます。

やっていること

『いかにして問題をとくか』を考える

いかにして問題をとくか
G. ポリア
丸善
売り上げランキング: 17,871

はるか昔に買ったはいいのですが、こんなの当たり前じゃないかと思って眠っていた本です。

本の詳細は書きませんが、問題を解くためのフレームワークのようなものが書かれています。例えば、

  • 未知なものは何か?
  • 与件(データ)は何か?
  • 条件は何か?

などです。

今、技術調査をするときはこうしたことを先に大きく目につくところに書くようにします。「この関数が偽を返すことが証明できれば、不具合は必ずこのスタックトレース内にある」とか、そういう具合です。

レビューの時も反復作業系なら「抜け漏れがないことを証明する」、新機能なら「既存の機能に影響がないことを証明する」という観点をぶらさないようにしています(もちろん、意図は複数ありますが)。

この何を解いているのかということを基準に思考を観察していると、いつ思考が横道にそれたか、今どこまで調査が完了しているかが把握できるので、思考が散漫になることが減りました。

また、レビューでも自信を持って、問題がないということを言えるようになった風に思います。

他の優秀な方たちはどうしているのかはわかりませんが(脳内で整理できているのかな)、自分は紙に頼ることが今でも多いです。

感情を観察する

問題が解けずに2,3時間たつと、イライラし始めます。レビューで指摘されて感情的になることはありませんが、同時に修正が大量に来ると頭がかっとなることがあります。

できる限り客観的に対応しますし、外にも出しませんが、かといって仕事中に感情を消すことは少なくとも自分にはできそうにないです。

ただ、感情を観察するようになって、いつそれが出てくるのかがわかるようになってきました。

そうやってメタ的に見ていると、「あ、今頭に血が上ったな」「胸から上に重心が上がった気がする」という兆候がわかるようになってきます。

さらにそれを深めて「普段の状態はどんな状態だろう」「どこから血が上がったのかな」「この状態で思考するとどういう思考になるのか」という観察を進めていると、気が付いたら冷静になっています。

また、今自分は問題についてではなくて、相手によく思われることに注意を向けていたなということがわかると、自然に問題のほうに思考を戻せます。

つまり言い方を変えると感情を観察することで、問題と感情を整理つけてとらえることができるようになったと思います。

これはノートに書くよりも、適当にSlackで自分にDMを打つようにしています。そうやって外に書いていると何となく傾向が見えてきます。

Vimを使う

今はVSCodeVimバインドですが、Vimは禅にとっていいエディタです。というのも、自分が今何をしているのか、何をしたいのかを正しく認識しないと、操作できないからです。

Emacsでもなんでもいいですが、Vimが顕著な気はします。

選択肢はどれだけあるか、今使うべきキーは何か、設定を変えることで最短を更新できないかなどを考えて作業することで、より禅の世界に近づけるという風に思います。

この分野は自分が語るほど強くなくて、周囲の人は、キーボード、画面分割、エディタの改造、シェルの改造、ブラウザの拡張などをかなりやりこんでいます。

いいエンジニアはそもそも自分のやっていることを把握しているものなのかもしれません。

やってみた感想

何かを考えるとき必ず他の人はどうしているか、ベストプラクティスは何かを探る癖がついています。

それも前職の思考のトレースに近いものですが、そうではなくて自分の軸を作ってそれに従う場面も必要なはずです。そこの優先順位が低いなぁと自分の思考をたどりながら、思ったりします。

そして感情が表に出ているときはパフォーマンスが悪いです。

悲しいはそもそもあまり思わない質ですが、怒りであったり、恐れ、焦り、あるいは愉快さであっても、明瞭に問題を解くときには役に立っていません。

「仕事は 楽しいかね」と最近色々な人に聞かれるのですが、うまく働けているときは問題のこと以外に注意が向いていないのでよくわかりませんという答えになります。

そのための環境は提供できていますかという意図の設問だと思うのですが、そこに入る過程は自分の注意力の向け方が正しいかどうかなので、自分自身の問題だよなぁと感じてやはり回答が難しいです。

自分は満員電車でもあまり苦に思わず、電車の揺れ、人の動き、体にかかる力などを味わうのが最近は気に入っているので、やはり心の持ち方次第ですとしか言えないです。客観的にみて、満員電車の環境がいいとは思いませんし。

今後

いかにも悟りましたという感じで書いていますが、実際は相変わらずSlackに注意をとられたりしますし、自席で仕事をしていれば紙やメモで頭を整理できますが、会話や会議になるとちょっと難しいところがあってまだまだです。

そういう問題に対しても深く観察して整理することで挑める部分もあると思うので、もう少し禅プログラミングを頑張ってみたいなと思っています。