開発者として、私は2年以上同じ仕事を続けた事がありません。
転職することは私にとって良いキャリアとなりました。私達の業界では転職を繰り返す事はごく一般的なことです。ところが、以前私が働いていた会社は、私の離職に難色をしめしました。中には、私を必死で引きとめようとする人もいました。しかし、私は仕事に飽きてしまっていたため、残ることはできませんでした。
（免責事項：私は多くのプログラマーよりも楽しいプログラミングの仕事をしていたと思います。仕事を変えることが常に最善の選択とは限りません。）
現在私はEnkiのco-founderで最高技術責任者（CTO）です。会社ではエンジニア文化の構築も行っています。つまり過去に私が陥ったように、エンジニアが仕事に飽きないようにする事も重要な仕事の一つなのです。
私たちは、チームの力を借りながらこの問題に対する対策を会社に打ってきましたので、その取組を共有したいと思います。
幸いなことにもEnkiは日々困難な問題にとりくんでいます。たくさんの実装したいコードと解決しなければならないパズルのような課題が十分にあります。つまり飽きるという事が緊急の課題になることは今はありません。しかし、最初からそうだったわけではありません。しかも、退屈というのは時間とともに蝕んでいき、最悪のタイミングであなたを襲います。
だから我々は早期に退屈しない文化づくりに取り組むようにしているのです。
長過ぎ。学ぶものがもう無い。
エンジニアが一番退屈するのは、長期間同じプロジェクトにいることです。
初めてついた仕事がまさにこれでした。私が入ったチームでは金融データを整形し、配信するAPIを作る仕事をしていました。データのスケールは大きく複雑でとてもエキサイティングでした。私は高性能なデータ分析APIの設計の技術を学びました。しかし、一年後も同じようなデータセットで同じような技術を使って仕事をしていたのです。まるで何かすごく限られた分野の専門家になったようでした。もう学ぶものが無くなってしまったのです。
長くいてしまったこともあり、私はチームにとって重要な人物になってしまいました。会社は私を他のチームやプロジェクトに移ることを許してくれなくなってしまったのです。世の中のデータやテクノロジーが速いスピードで進化している事は私も知っていました。私は会社に不満と飽きを表明しましたが受け入れてもらえなかったので、転職するしか無くなったのです。
退屈の種を紡ぐことはできるのか
我々は同じコードや同じ製品やデータセットを３ヶ月以上同じ人がさわり続け無いようにしています。これはちょっとやりすぎで、もしかすると大きな企業においては難しいかもしれません。しかし我々は速いスピードでローテーションすることの効果を信じています。
これを実現するために、我々はフルスタックの文化を促進しています。弊社のエンジニアはコードのどの部分でもいじることができます（もしくは迅速に学ぶことができます）。
そしてもう一つの要因が、この問題に対して常に議論する点です。私たちは毎週、一対一で直接話し合う機会を設けています。もしエンジニアが仕事が簡単すぎると感じていたり、もしくは専門的過ぎると感じていたら、それがプロジェクトをローテーションするタイミングなのです。
レガシーコードは触りたくない
バグ修正の時間が90%を超え始めると、公式に宣言しているかは別として、そのプロジェクトはメンテナンスモードに入ったと言えるでしょう。 メンテナンスを避ける事は出来ないという意見もあります。古いコードにはサポートが必要だと。ソフトウエア開発は家を建てるのと似ている。時とともに古い家はメンテナンスして改装していく必要があるという意見です。 この意見はYESであり、NOです。大事なのは態度なのです。
私はかつてこの問題に対してシニカルなメンターがいました。彼は何もできる事は無いと、これがソフトウエア開発なんだと言いました。人生なんてそんなもんさ、慣れるしかないよと。 本当にどうにもならないのでしょうか？
メンテナンスモードは低い技術力と勇気のない決断が原因になる事が多いです。 複雑な依存関係を持つ巨大でモノリシックなコードはメンテナンスコストを増大させます。これとは対照的に良く設計されたマイクロサービスはもう少し柔軟です。マイクロサービスに障害が発生した場合、対象部分を交換する事が出来ます。新しい言語や技術を使ってスクラッチで書き直すことも出来ます。この方法なら新しい学びを得ることができるでしょう。そしてもし、現在の設計がそうなっていないなら、少しづつ設計を変えていく事でDevopsのスキルを身に着ける事もできるでしょう。
マイクロサービス戦略はエンジニアの「飽き」に対処できる唯一の方法です。賢いビルドツールを作ることで効率的で楽しくメンテナンスしようと試みている所もあります。例えば大量のPHPのコードを抱えるFacebookです。かれらはPHP上に独自の片付け言語を構築しそのコンパイラを作ることでメンテナンス効率を上げ、また技術的なやりがいを作りました。私はこれが本質的な問題を解決したとは思いませんが、仕事をより楽しい物にしたことは確かだと思います。
コピペは退屈
それはコーディングで、そしてこれもコーディングなのだが。。。
私は過去に実りの無いコードを書いていた時期もありました。例えば、データを統合させるためにGroovyやPythonのスクリプトを書いていました。データは複雑で、数十の一貫性の無いスキーマで構成され、自動化する事は出来ませんでした。沢山のコードを書く必要があったので、社内では私が沢山の学びを得ていると思われていました。
しかし現実は違いました。
コードの50%はStack Overflowからのコピペ。残りの40%はその他のソースからのコピペ。自分で書いたコードや同僚が書いたものからでした。 それの繰り返し。 ほんの少しの創造性と学びしか無かったのです。
我々はこの問題にどのように対処すれば良いのでしょうか？
他のチームメンバーが書いたコードを見る事が大切です。我々はこれをコードレビューと振返りを行う事で解決しています。もしも誰かが非クリエイティブなコードを一週間書いていたら、なぜそのような事になったのかを考えるようにしています。
時に、根底に技術的な問題が潜んでいる場合もあります。ちょっとした設定ファイルとスクリプトで解決できるかもしれません。自動化処理を追加する事で解決する事もあります。もちろんコピペをしなければならない状況もあるでしょう。そのような退屈な作業をしっかりと仲間で共有する事が大事なのです。
社内ツールはだいたいつまらない
我々は特別な課題を解決するためについつい社内ツールを作ってしまいがちです。新しいモノを作るのは楽しいですからね。それにきっちりカスタマイズされた製品のほうが既存の製品を組み合わせて使うより美しく見えてしまいます。しかしそのような独自のツールを学ぶことはオープンソースの技術を学ぶ事の10倍つまらないです。
なぜか？
それは、そのテクノロジーに関して友人に話すことができないからです。自慢もできません。Hacker Newsでそれに関して言及されることもありません。ハッカソンで使うこともできないし、家で作ってる秘密のプロジェクトで使うこともできないのです。
しかし、多くの企業はこの退屈で価値の無い物を作る罠にハマります。言い換えるなら、短期的なフラストレーションの解決をし、長期的なフラストレーションを産んでいるのです。
実際、以前の職場で直接経験しました。私は、大規模なデータ統合のために、その会社が独自で作っているDSLを使う事を強要されたのです。それはSQLの独自拡張のような言語でした。私にとってはSparkのようなオープンソースを学ぶ方がよっぽど良かったでしょう。もしそれなら私は10倍仕事に従事したでしょうし、コードは2倍冗長になってしまうかもしれないが、生産性は5倍になっていたでしょう。(数字は正確ではないかもしれないが、何が言いたいか、わかりますよね？)
どのような文化を形成すればこのようなことが防げるでしょう？
我々はオープンソースに強いバイアスをかけるようにしています。もし何か面白そうで利用できそうなものがあったら、我々は使います。最先端の技術を積極的に使うようにしています。我々のカスタムしたコードを置き換えることが可能なオープンソースが出てきた場合、すぐにオープンソースに置き換えます。また我々が作ったカスタムコードが十分にジェネリックなものになったら、オープンソースとして公開します。
もちろん失敗する時もあります。例えば、agenda.jsというバックエンドのジョブスケジュールを行うライブラリがモダンで面白そうに感じたので導入したことがあります。しかし作りがすごく複雑になってしまったので、古いツールに戻しました。より信頼性の高いツール（古き良きcron）に。しかし、貴重な学習体験になったので、我々は後悔していません。
コードモンキーにはなりたくない
ダメなマネジメントも、エンジニアを飽きさせる要因の一つでしょう。もう少し具体的に言うと、トップダウンで独裁的なマネジメントです。
優秀なマネージャーの場合、エンジニアに不満を抱かせずにそのようなスタイルの経営を実行する場合があります。特にプロジェクトが上手く回っていない時、もしくは納期間近の場合にうまくいきます。強いプレッシャーを受けている場合は、短い議論をカットし、ブレストの時間を減らし、ディベートや説明無しに何をやるべきかだけを伝えることは自然です。ただ時間を節約し、目的を達成するために。
理解力のあるマネージャーの場合、このぐらいはこなすでしょう。実際に一部の人々は（時々）シンプルに何をやるべきかを伝えられたほうが嬉しいでしょう。もちろんその内容が正しいと思っていると仮定してですが。
しかし、ここには隠れたコストがあります。
はじめから何を作るかを正確に知っている状態は、知的でクリエイティブな作業を、機械的な作業に変えてしまうという事です。つまり言われたものを作るだけのコードモンキーになるということなのです。
重要なのは、エンジニア自身が「理由」を知ることです。もちろんこれも極端なケースでワークさせるハックか、一時凌ぎの対策でしかありません。しかし、エンジニアが重要な意思決定やその背景にある理由を気にしなくなった時は、それは転職の準備が整ったという事です。
どうしたらこれを防げるのでしょうか？
最も大事なのはオープンな議論を推奨するカルチャーです。我々が定期的に開催しているフォーラムでは、チームが何をしていくかの戦略を議論しています。そしてこのカルチャーを維持するためには、チーム全員がこのカルチャーの維持を意識する事が大事です。
もし大変な時期(もしくは納期間近)の時は、メンティーは話したがっています。メンターは注意深く、その意見に耳を傾ける必要があります。
日常はいつだって退屈
大事なことを言い忘れてました。閉じられた環境でのルーチンワークが面白さを殺すという事です。
これはエンジニアやIT企業に限られた話ではありません。様々なバックオフィスの仕事にも言えることです。毎日同じ部屋、同じメンバー、同じ文化で同じ仕事… それは成長が速い環境で、これらの事が客観的に良さそうに見える場合でも、人々は良い部分を権利と感じ、悪い部分にフラストレーションを感じて行くのです。
どのようにこの問題に向き合えば良いのでしょう？
ここで重要となる成分に多様性があります(例えば我々のチームのうち6人はイギリス、フランス、ロシア、ギリシャの人です)。毎日同じメンバーを見る事も、それぞれが異なる文化を持ち込むと、より面白くなります。
また、我々は外の世界に出て行く機会も頻繁に作っています。
例えば、私たちはミートアップイベントやハッカソンに共に出かけます。またサイドプロジェクトを持ちオープンソースのツールに貢献しています。またテクニカルな仕事以外(雇用、マーケティング、流通など)も手伝います。これらの仕事に長けているわけではなく、変化を起こすためにやるのです。
また業務外で「どっきり映画鑑賞会」のような企画を組んだり、毎週アジェンダのない「enkithon」（訳注：enki社のハッカソンの意だと思われる）というものを開催しています。そこで時に何かをhackしたり、新しいアイデアをブレストしたり、League of Legendsをプレイするだけの時もあります。それか飲みに行くか。これの良さは、我々がみんなで決めるまで何も決まってないという事です。
このちょっとしたカオスが退屈に対するレシピの成分となります。そして、これらのどのレシピも、完璧になることはありません。何度も何度も微調整し、材料を調整することが大事なのです。
