最近、社内で関わるプロジェクトが移り、当然と言えば当然だが生産性が低下している。ついでに、長いビルドの暇な時間に、プログラマの生産性ってなんだろうな、ってなことをぼんやり考えたりしている。
スーパーエンジニアは凡百なエンジニアの数十倍とか数百倍という生産性があるという。数十倍かはわからないけど確かにものすごく生産性の高いエンジニアというのはいる。いるのだけど、何故彼らは生産性が高いのか。っていうか、そもそも生産性、ってなんだろう。
一般的にプログラマの生産性というとコーディングスキルだと思われている気がする。だけど、それだけなんだろうか。そりゃ優れたコードを書くのは才能だし、スピードも才能で、ぼくにはそんなものはない。ただ、言語も開発環境も大同小異なプロジェクトのメンバー同士でも、かなり生産性には差がある。この差がコーディング能力だけでつくとはとても思えない。
高林さんの文章で、プログラマの生産性についての考察があった。いちいちうなずくこと然り。レスポンスが異常に速いとか、フットワークが軽いとか、終わらせるとか……。と読みながら、ひとつ付け加えることがあるとすれば "コンテキストスイッチ力" があるんじゃないかと思った。コンテキストスイッチのコストが低い人は総じて生産性が高い。
プログラマの仕事というのは、意外と待ちの時間があるものだ。ビルドに費やしている時間、データをダウンロードしたりアップロードしたりする時間。解析プログラムが巨大なデータを処理している待ち時間。レビューやメールの返事待ち。その他もろもろ。
そういう細かい空き時間をどう使うかというのは生産性に大きく寄与している。複数の作業を効率良く並列に進められるか。関連するコードを読んでみたり、論文に軽く目を通してみたり、メールの処理時間に使ったりもできる。
私はコンテキストスイッチのコストが高めなので、ビルドのログが流れていくのを眺めながら、比較的どうでもいいこと（プログラマの生産性ってなんなのか、みたいなこと）をあれこれ考えたりしてしまう。
ビルド中にメールでも書こうか、とメールの画面に移って、書いていたら意外と手間取ってしまって送信してほっと一息ついたら実はとっくの昔にビルドが終わってて、本当はその後にテストを実行させないといけなかったのだが……みたいなあるあるネタを実際にやっちまったりして。……あるよね？
コンテキストスイッチのコストはどうやったら下げられるのだろう。
そんなことが分かっていたら、こんな文章を書いているはずがないので（笑）、私にもよくわからない。だがひとつ仮説として考えているのは、自分の作業フローを見通す能力なのではないかということだ。今からメールの返事を書くのにどれぐらいの時間がかかるのか。ビルドはどれぐらいの時間で終わって、その間にできることは何か。作業時間の予測とか、比較的短いスパンで何ができて何をどの順番でやるか、というのを把握していれば、テンポよく作業を進めることもできる。
レスポンスが速いというのもそういうことだ。メールやチャットで連絡が来たときにプライオリティ付けがきちんとできないと、連絡したのにいつまでも返信ができない。逆に、チャットで相談に乗っていてひととおり解決したところでさっきまで何をしてたっけ……とならずにすぐ復帰できる人は生産性が高いし、自分はすぐ復帰できるからこそ連絡にきめ細かく対応できる。
また、こういう知識や優先順位づけは一般化しづらく、プロジェクトやチームによっても往々にして変わるから、プロジェクトが変わると生産性がいったん落ちたりするのだと思う。
プログラマの界隈ではよく「フローに入る」という表現がある。それがどういう意味なのか正確に把握している自信はないけど、少なくともコンテキストスイッチをよしとしないということだ。人間、コンテキストスイッチのコストは決してゼロにはならないので、それを減らして作業に集中するというのもひとつの作戦だ。だけど、それが全てでもないのでは、と思う今日この頃。
たぶんきっと、このへんはプロジェクトの性質にも関わっている。ビルドにどれぐらいの時間がかかり、テストの実行やレビューや各種のプロセスがどうであるか、というのにもよる。個人プロジェクトに近いものほどフローが重視され、大きなプロジェクトではコンテキストスイッチは避けられないものとして対峙する必要があるのかも。
いずれにしても、コードを書くパワーだけが生産性ではない。だけど何しろコードを書いて生活しているように思っているので、そこを頑張ってしまいがちなのではないか、とちょっと思っている今日この頃です。
スーパーエンジニアは凡百なエンジニアの数十倍とか数百倍という生産性があるという。数十倍かはわからないけど確かにものすごく生産性の高いエンジニアというのはいる。いるのだけど、何故彼らは生産性が高いのか。っていうか、そもそも生産性、ってなんだろう。
一般的にプログラマの生産性というとコーディングスキルだと思われている気がする。だけど、それだけなんだろうか。そりゃ優れたコードを書くのは才能だし、スピードも才能で、ぼくにはそんなものはない。ただ、言語も開発環境も大同小異なプロジェクトのメンバー同士でも、かなり生産性には差がある。この差がコーディング能力だけでつくとはとても思えない。
高林さんの文章で、プログラマの生産性についての考察があった。いちいちうなずくこと然り。レスポンスが異常に速いとか、フットワークが軽いとか、終わらせるとか……。と読みながら、ひとつ付け加えることがあるとすれば "コンテキストスイッチ力" があるんじゃないかと思った。コンテキストスイッチのコストが低い人は総じて生産性が高い。
プログラマの仕事というのは、意外と待ちの時間があるものだ。ビルドに費やしている時間、データをダウンロードしたりアップロードしたりする時間。解析プログラムが巨大なデータを処理している待ち時間。レビューやメールの返事待ち。その他もろもろ。
そういう細かい空き時間をどう使うかというのは生産性に大きく寄与している。複数の作業を効率良く並列に進められるか。関連するコードを読んでみたり、論文に軽く目を通してみたり、メールの処理時間に使ったりもできる。
私はコンテキストスイッチのコストが高めなので、ビルドのログが流れていくのを眺めながら、比較的どうでもいいこと（プログラマの生産性ってなんなのか、みたいなこと）をあれこれ考えたりしてしまう。
ビルド中にメールでも書こうか、とメールの画面に移って、書いていたら意外と手間取ってしまって送信してほっと一息ついたら実はとっくの昔にビルドが終わってて、本当はその後にテストを実行させないといけなかったのだが……みたいなあるあるネタを実際にやっちまったりして。……あるよね？
コンテキストスイッチのコストはどうやったら下げられるのだろう。
そんなことが分かっていたら、こんな文章を書いているはずがないので（笑）、私にもよくわからない。だがひとつ仮説として考えているのは、自分の作業フローを見通す能力なのではないかということだ。今からメールの返事を書くのにどれぐらいの時間がかかるのか。ビルドはどれぐらいの時間で終わって、その間にできることは何か。作業時間の予測とか、比較的短いスパンで何ができて何をどの順番でやるか、というのを把握していれば、テンポよく作業を進めることもできる。
レスポンスが速いというのもそういうことだ。メールやチャットで連絡が来たときにプライオリティ付けがきちんとできないと、連絡したのにいつまでも返信ができない。逆に、チャットで相談に乗っていてひととおり解決したところでさっきまで何をしてたっけ……とならずにすぐ復帰できる人は生産性が高いし、自分はすぐ復帰できるからこそ連絡にきめ細かく対応できる。
また、こういう知識や優先順位づけは一般化しづらく、プロジェクトやチームによっても往々にして変わるから、プロジェクトが変わると生産性がいったん落ちたりするのだと思う。
プログラマの界隈ではよく「フローに入る」という表現がある。それがどういう意味なのか正確に把握している自信はないけど、少なくともコンテキストスイッチをよしとしないということだ。人間、コンテキストスイッチのコストは決してゼロにはならないので、それを減らして作業に集中するというのもひとつの作戦だ。だけど、それが全てでもないのでは、と思う今日この頃。
たぶんきっと、このへんはプロジェクトの性質にも関わっている。ビルドにどれぐらいの時間がかかり、テストの実行やレビューや各種のプロセスがどうであるか、というのにもよる。個人プロジェクトに近いものほどフローが重視され、大きなプロジェクトではコンテキストスイッチは避けられないものとして対峙する必要があるのかも。
いずれにしても、コードを書くパワーだけが生産性ではない。だけど何しろコードを書いて生活しているように思っているので、そこを頑張ってしまいがちなのではないか、とちょっと思っている今日この頃です。
