伊藤 浩一 (@koic) です。永和システムマネジメントでエンジニアリングマネージャーをしています。RuboCopなどRuby関連のOSSにも携わっています。
「OSS開発をしたいのに時間がない」
そう感じるとき、実際には時間そのものよりも、「終わっていないこと」に頭のリソースや心のゆとりが占められている可能性があります。そこで本稿では、私がOSS開発を365日続けるための習慣や姿勢の中から、3つのコツを「やらないこと」視点でまとめています。
この記事では主に以下の読者をターゲットとしています。
- OSS活動に取り組みたいが、日々の仕事が忙しくなかなか時間を捻出できないエンジニア
- 習慣化・継続のコツを知りたい成長意欲のあるエンジニア
私がメンテナンスしているOSSプロダクトの総ダウンロード数は、執筆時点で30億ダウンロードを突破しており、広く使われるOSS開発に関わってきています。そんな広く使われるOSSの開発はひとりで成り立つものではありません。
OSS活動を長く続けるには、自分自身の「心の余裕」「時間の余裕」に加えて、実は「コミュニケーションする相手の余裕」をつくるために、何をやらないか考えることも大切です。そんな知見を解説していきます。
1. すぐ終わるタスクを溜め込まない
まず簡単なタスクを溜め込まないようにしています。最初にこの原則を公式で表してみます。
覚えておくことの負荷 = やるべきタスク - 終わったタスク
さまざまなタスクを抱えていると、何をするかの選択に時間をとられてイマイチ進捗が出なかったり、終わっていないタスクに対するコンテキストスイッチに労力をかける必要が生じたりします。
難しいタスクならともかく、簡単なタスクに長時間のライフサイクルを与える必要性はありません。
一時代前に一世を風靡したGTD（Getting Things Done）という時間管理術があるのですが、この書籍は私自身も影響を受けた一冊です。
GTDでは「2分以内にできることはすぐに行う」と解説されていますが、私自身はもう少し拡張して「15分以内で終わることは早急に着手して終わらせる」という習慣をつけています。
やるべきことを覚えておくのは、存外にストレスにつながったりします。また自分がタスクを終えていないことで、周囲の人々もいつ終わるのか心配しストレスになる可能性があります。すぐに終わらせることで、自分だけでなく周囲の人々も覚えておく事柄を減らすことができます。
大事な点はタスクを溜め込まないことです。「すぐできるから後でやろう」から「すぐできるから先に終わらせよう」の心構えに変えるのがキーになります。さらに、本質は「何分ルール」ではなく、終わらせて頭の中から追い出すことです。実際に何分以内に終わるかは、本質と比べればそれほど重要ではありません。n分以内というルールは、タスクを終わらせるトリガー程度として見ておくくらいがちょうど良いと私は捉えています。
私がOSS活動で小さなイシューを素早く片付ける背景には、そういった習慣があります。終わらせられることは、どんどん終わらせていきましょう。「いま忙しいから」というフレーズは単に時間のみを示しているのではなく、往々にして心の在り方も示されています。OSS活動を継続的に行うには、時間的なゆとりが大切なのはもちろん、それ以上に心のゆとりが大切です。
2. やってもやらなくても良いことはやらなくて良い
やらないといけないこと、やるべきでないこと、やってもやらなくても良いこと。ソフトウェア開発における要件定義や仕事のタスクと向き合うとき、この3分類の思考フレームワークを適用可能なケースが往々にしてあります。
私はこの3つのうち、やってもやらなくても良いことを見極めるのが重要だと思っています。仕事になると、やってもやらなくても良いことに対して、やる側にフォースを働かせてしまうことを度々見かけます。プレッシャーや、カッコよく見せたい気持ちに起因しているのかもしれません。冷静に考えてみれば、それはやらなくても良いことだったりします。
例えば、本対応をすれば必要がなくなるワークアラウンドに必要以上に手をかける。時間が経てば解決することへのつくり込みを検討する。一般的なユースケースがない個人の困りごとに、必要のない抽象化の労力を掛ける。こういったことはやらなくて良い、あるいは手順を変えたり実施タイミングを変えることで、無駄な作業を省ける可能性があるものです。
依頼されたタスクを断るといった発想が弱かった駆け出しの頃は、押し寄せるタスクの量に押し潰されたものでした。「能力が足りていないのではなく、やることが多い」状態だったといえます。やる必要がないかどうかを判断する意思は、そういった状況になることを防ぐための第一歩にもなります。
やらなくてよくなれば、その分の時間が捻出でき、自分たちとして他に価値があると思うものに時間を使うことができます。そのひとつがOSS活動になるかもしれません。
日中の仕事においては、必要以上に参加者が招待される打ち合わせもあります。私の場合は、私が参加することでアウトカム（社会への価値）に繋がる確信がない打ち合わせは、常に参加すべきか否かを考えています。打ち合わせが多くて時間がないという人は、意外と参加しなくても良い打ち合わせが見つかるかもしれません。逆に参加する打ち合わせでは、アウトカムに繋げられるよう、メリハリが重要だと思います。
実は、始めることよりも終わらせることの方が難しい場合があります。必要のなくなった定例はなくす、開催頻度や時間を減らすなど、状況の変化に合わせて削っていく提案も考えるべきでしょう。打ち合わせは、多ければ良いというものではなく、打ち合わせからどんなアウトカムを出しているかが重要です。もちろん、必要な対話の時間まで減らすべきではありません。雑談を含めたコミュニケーションの時間も、人間関係の構築には大切です。
もしかすると、「やらない」という選択を悪のように感じる、あるいは背徳感を覚えるような人もいるかもしれません。ですが、実は真逆です。本当に必要なものだけに絞って活動するというのは、自分自身で考えて動くという創造的な活動への道の可能性があります。何を減らすかを考えることも、継続への工夫のひとつです。
もちろん、単なる反骨精神で打ち合わせに出ないわけではないという意思は、きちんと伝える必要があります。信頼関係が先にあることが大事ですね。
マネージャーという仕事柄、打ち合わせで一日が終わってしまわないようにすべきです。マネージャーこそ打ち合わせをコントロールし、手を動かす時間をつくるべきだという考えで働いています。
3. レビュアーに労力を負担させない
本稿で取り上げる最後の習慣として、レビュアーを特別な人として見ないといった点があります。
OSSメンテナーも人間なので、自分の使える時間には限りがあります。私自身メンテナーを行っていて一番嫌なものは、レビューコストが高いPull Request（以下、PR）です。言い換えると、レビューコストが低くなるように工夫されているPRは、著者のエンジニアリングスキルへの好感度が上がります。
GitHubでのレビュー文化の登場以降から現在のコーディングエージェント時代に至るまで、ボトルネックになりやすいのはレビュアー側です。レビュアーのコストを減らす工夫として、例えば事前のセルフレビューは必ず行う、その問題と解き方が妥当である説明をしっかりと書くといったことができます。
また、コミットメッセージをイシューのURLだけで済ませず、最低限のWhyを書き残しておくことも重要です。ソースコードの差分からHowは読み取れても、なぜその変更が必要だったのかというコンテキストは時間とともに失われていきます。これは人間だけではなくAIにとっても同様で、コミット履歴に文脈が残っていることは将来のレビューや調査コストを減らすことに繋がります。
これは日頃の仕事におけるPRでも同様のことが言えます。サッとマージボタンを押すことができるPRをつくることができるのはスキルですし、セルフレビューによって事前に情報が整理されたPRほど、レビュアーも先に進みやすくなります。
「よーい、どん」で始まったプロジェクトにおいて、いつの間にかレビュアーとレビュイーに分かれてしまい、日中はレビュイーが書いたPRをレビュアーがレビューして、終業後にレビュアーが自分のコードを書くという現象を幾度か見てきています。理想的にはレビュアー側になれる人が増えるに越したことはありませんが、そうでなくてもレビュアーのレビューコストを減らす工夫は常に考えておくと良いでしょう。
参考までに私のセルフレビューはClaude CodeからCodexにコードレビューを指示した上で、自身での最終レビューを行うといったフローを取っています。自分の側でできることもスキルや時代により変わっていくものです。常に自分の側で解決できることを増やせないか継続して考え続けることは、結果として自分のエンジニア価値を高めることに繋がっていくことでしょう。
最近は、AIの普及によって「作業としてのコーディング」を自分で行わない場面も増えました。一方で、コードを書くことだけがプログラミングではありません。コンピュータを使って問題解決を行うという本質的な部分に、限られた開発リソースを注力するようシフトしています。
OSSの世界ではAIの登場によって、ソーシャルコーディングの在り方も変わってきています。イシューをそのまま実装しただけでは、以前よりも受け入れられにくくなっているように感じます。OSSのイシューが未解決のまま残っているのには理由があります。イシューを額面通りに受け取るのではなく、本当の問題は何なのかを読み解く力は改めて重要になっているでしょう。
最後にエンジニアリングマネージャーとしての私の視点を添えます。これまでの歴史を踏まえると、OSSで起きたソーシャルコーディングの流れは、実務での開発プロセスに流れてきます。AIでコーディング速度を上げるだけではなく、AIを使って質を高める工夫も重要になってきています。AIを活用してレビューやセルフチェックの負担を減らせる環境は、開発者の心身の健康を支えるうえでも重要になっていくでしょう。もし、あなたが組織のマネージャーであれば、時代の変化に合わせて開発者を支える仕組みを更新し続けることも重要な役割でしょう。
おわりに
正直なところ、日々の業務での開発とは違い、OSS開発への参加は必須ではありません。一方で業務での開発は、数多くのOSSに支えられているという点も事実です。
ではOSSは特別なスキルを持っているからできるかというと、YesでありNoであると思います。たまに圧倒的なスキルを持ったプログラマーと会うと、自分との格の違いを感じますが、これがYesの部分。一方で、GitHubに毎日草を生やすというのは、それそのものは誰でも行えるものだと私自身は思っており、これがNoの部分。
もし自分に圧倒的なスキルがないとしても、継続するという努力はできます。それに向けて手を動かしてアウトカムに繋げるべきだというのが自分の考え方です。もちろん継続は惰性で行うものではなく、自分のキャリア形成として挑戦に繋がる形で続けていく姿勢が重要なのは本記事に記したとおりです。
本稿で挙げたものは、あくまで私自身のスタイルです。なにを引き算して価値を生み出していくかは読者の皆さんが「エンジニアとして余裕をどう設計するか」次第です。最後に、私が好きな『エクストリームプログラミング』の言葉を引用して終わります。
ーXPとは、あなたが自分の理想について考え、その理想にもとづいて行動するための方法だ。
OSSの世界も人々の営みで成り立っています。継続には、書く側にもレビューする側にもゆとりが必要です。そのためにやらない選択を見つけていけるキッカケに本稿がなれば幸いです。