エンジニアリングを楽しみ続けるために
もしも勤労が避けられず、しかも休息はこれと反対のものであるならば、「あなたは額に汗してパンを食べねばならぬ」という言葉は、全くの呪いの言葉であり、地上は実際、涙の谷であろう。
———カール・ヒルティ
いやぁお盆の連休も終わりですね〜。
そんなわけで休みが明けゆくサザエさん症候群に襲われながら、しこたまビールを飲みつつこれを書いております。
とはいえ、仮にも比較文学の修士を得た身、例え酔い潰れても筆致は落ちません。
落ちないはずです、いえきっと...、
がんばれ、儂、アルコールなんかに負けるな。。。
ではやっていきます。
エンジニアリングを楽しむ
お金さえもらえればいいという人。
仕事に情熱を求める人。
色々なワークスタイルが存在します。
しかし、いづれにしたって、誰しも心のどこかで仕事にやりがいを求めています。
それは「専ら銭のために働いています」というビジネスライクな人でも同じです。
もし仮に、エンジニアとして仕事をする代わりに、刺身の上にタンポポを乗せる仕事を与えられたとします。
しかも、それによってエンジニアとして働いていたときの倍かそれ以上の給料をもらえると仮定します。
このような高待遇にあっても、大半のエンジニアはタンポポを乗せる仕事をかなぐり捨て、今すぐにでもコードを書きたいと願うことでしょう。
つまり、エンジニアという種族はそのDNAにして根っからのホモ・ファーベル（工作人)であり、仕事の中に自身の能力を遺憾無く発揮する機会を求めています。
それに、言うまでもなく、やりがいは無いよりかはあった方が良いに決まってますし、仕事は退屈よりかは楽しいに越したことはありません。
そこで問題にしたいのは、如何にしてエンジニアリングを楽しむことができるか、そして、如何にしてエンジニアリングを楽しみ続けることができるかということです。
フォード生産方式
できれば仕事を楽しみたいものです。
しかし、回りくどい話を展開しますが、この"仕事"というのは、実に捉え難い存在です。
遠く昔、彼方はヨーロッパ、ギリシアの地で、仕事は奴隷が行う卑しい行為でした。
そこでは自由とは、奴隷を支配し人間生活の必要条件から労働を取りくことで得られるものです。
ところが、反対にキリスト教世界の道徳では、仕事は尊いこととされます。
聖パウロは「働きたくない者は、食べてはならない」と語り、聖書には「お前は顔に汗を流してパンを得る」とあります。
つまり、時代の変遷と共に”働くこと"の観念も移り変わり、一定ではありません。
昔と今の仕事は、別の物だったといえるでしょう。
しかし、それらを完全に別個の物として分断したのは、やはり産業革命になります。
ここでの象徴的な出来事といえば、フォード生産方式の出現です。
1910年、ヘンリー・フォードは、自動車の大量生産のために新しい作業方式を導入しました。
T型フォードなど少量の機種に絞り込んで製品を標準化し、部品を規格化し、製造工程を細分化してベルトコンベヤーによる流れ作業で生産を行うようにしました。
これにより作業員の作業が単純化して熟練工が不要になりました。
ソフトウェアも自動車と同じように作ればうまくいく。
そのような自然な推論をスタートに、ソフトウェア開発の歴史は始まります。
いうなればフォード式ソフトウェア開発。
ここではプログラマーは工員で、彼らの働くオフィスはソースコードの生産工場です。
ベルトコンベアのように上から流れてきた仕事を、機械的にコードに変換していく...
限られた業界では、確かにこのような方法が効率的ではあるかもしれません。
しかし、いわゆる変動の激しい「VUCAの時代」においては、変化に対応するためのより良い方法があるはずです。
それに、プログラムを書くというのは流れ作業にできるほど簡単なものでもありません。
また、フォード式ソフトウェア開発は、エンジニアのやりがいをも奪うものでもありました。
そこで、多くのギークたちは「プログラミングは芸術であり、ハッカーは画家である」を標語として、ただの工員となることを拒みました。
彼らが好んだのは、巨大なシステムの僅かな部分を担うより、新しいシステムを自らデザインすることです。
これに関して、ポール・グレアムの『ハッカーと画家』というエッセイは広く知られています。
次は、それを少し覗いてみます。
ハッカーと画家
ポール・グレアムが語るのは、自分自身を一人の工員とみなすのか、それともハッカーと見做すのかという問題です。
自分自身を一人の工員とみなす場合、仕事はコードを書くことです。
そこでは、ただ決められた手順に沿って、仕様をプログラムに直していくことになります。
溝を掘る作業者みたいに、端から別の端まで順番に仕上げていくことでしょう。
私はこのことにはごく最近になるまで気づかなかった。 YahooがViawebを買収した時、彼らは私に何をやりたいか尋ねた。 私はビジネスのことには全然興味がなかったので、ハックしたいんだと答えた。 Yahooに入ってみたら、彼らにとってハックするということは ソフトウェアを実装するということで、デザインするということではないということが わかった。プログラマは、プロダクトマネージャのビジョン とかいったものをコードへと翻訳する技師とみなされていたのだ。
どうも、大企業ではそれが普通らしい。 そういうふうにすれば、出力のばらつきを押えることができるからだ。 ハッカーのうち実際にソフトウェアをデザインできる能力のある人間はほんのひと握りであって、 企業を経営している人々が彼らを見つけ出すのはとても難しい。 だから多くの企業では、 ソフトウェアの未来を一人の素晴らしいハッカーに託すのではなく、 委員会によって設計し、ハッカーはそれをただ実装するだけという 仕組みを作るんだ。
反対に、自分自身を一人のハッカーとみなす場合、仕事はソフトウェアを設計することです。
そこでは、問題解決の一つの手段としてプログラミングスキルを用い、創造性を発揮して仕事に当たる必要があります。
ハッカーと画家に共通することは、どちらもものを創る人間だということだ。 作曲家や建築家や作家と同じように、ハッカーと画家がやろうとしているのは、 良いものを創るということだ。
ここで、ポール・グレアムは、かなりハッカーに肩入れした書きぶりです。
しかし、重要なのは、自分自身がどちらの生き方を求めているか、ということなのかもしません。
コードを書くのを純粋に楽しみたい人もいれば、課題解決の手段としてコードを書きたい人もいるでしょう。
ハッカー的に生きたい人が、決められた仕様をコードに翻訳しているのであれば、不満足を感じます。
反対に、工員的に生きたい人が、課題を発見することや解決方法をデザインすることを求められば、ストレスを溜めていきます。
自分自身はハッカー的に生きたい人間なのか、それとも工員的に生きたい人間なのか。
それを知っておくことがエンジニアリングを楽しむ秘訣なのかもしれません。
エンジニアリングを楽しみ続ける
ここまで、わりと抽象的な話をしてきましたが、もっと些末で卑近な理由で、エンジニアリングが苦行と化してしまうこともしばしばあります。
例えば、
- 多すぎる技術的負債
- 非生産的な組織や開発体制
エンジニアが企業を去るのは、こうした組織の問題に足を取られて満足に開発できないことが理由だったりもします。
表面上は祝福される門出であっても、その裏に負の想いを隠して去っていく人も少なくありません。
では、これらを乗り越えて、エンジニアリングを楽しみ続ける道はないのでしょうか。
順に見ていきます。
多すぎる技術的負債
技術的負債が多すぎるというのは、とてもありふれた問題です。
ありがちな問題でありながら、しかし、エンジニアリングが苦痛なものになってしまう原因のNo.1にこの技術的負債が鎮座していることと思います。
その背景の一つとしては、多くのスタートアップが、質とスピードをトレードオフだと考え、質を落とすことを正当化してしまいます。
せめて一人でもちゃんとしたエンジニアがいて、質とスピードがトレードオフでないですよ、と待ったをかけることができると良いのですが。
開発の最初期には、安全で変更のしやすいコードが書けるエンジニアが、一人も在籍しない場合もあります。
なぜなら、プロダクトが市場に受け入れられ、採用にコストをかけられるようになり、そこではじめて優秀なエンジニアを招き入れることができます。
必然的に、優秀なエンジニアほど、"とんでもないコードでなんとか動いている"事態に出会う確率が高くなります。
だからといって、新しく入った人が力まかせにこれを直そうとすれば、大抵の場合、ただ怪我をして終わりです。
彼には、まだドメインに関する知識もなく、そのスパゲッティにどんな毒が仕込まれているかも知りません。
負債が放置されているような企業では特に、コードにどんな罠が仕掛けられているか、それは長く在籍しているエンジニアのみぞ知る暗黙の了解となっています。
ドキュメント化などされている由もなく、機を伺って口頭で継承してもらうしかありません。
継承してもらう前に直そうとすれば、毒に当たって血を吐くことになります。
これに関して、『糞コードは直すな。』という記事は有名です。
個人的には糞コードは直してほしいですし、将来的には直していくべきだとも思いますが、この記事の「とりあえず落ち着け」というメッセージにはとても共感します。
あぁ！！このコードむかつく！！これ直しましょう！！
は大体死亡フラグです。糞コードが糞コードたる所以で、大体、1日、2日で直すことができないから糞コードなのです。こういう怒りに任せて、糞コードを若さのパワーで押し切るのは、大体みんな通ってきた道です。そして、日がたつにつれて、目は死んでいき、糞コードに目を向けるのが辛くなる。しかし、啖呵切った手前、直さないわけにはいかなくなり、精神的な重圧が強くなってくる。
一時の感情に任せるな。必要なのはやる気ではない。啖呵を切る男気でもない。根気と、それをやりきる戦略です。
(...中略...)
一旦引いた眼で状況を把握し、技術負債を解消するうえでどういう力学が働くのか、なぜ技術負債が発生してしまったのかを考え、やるべきことを1つずつ積んでいくのが大事だと私は思います。
まさしくその通りだと思います。
カッっとなって無理やり直そうとしても良いことありません。
必要なのは戦略です。
思うに、糞コードを直そうとする者は、それがなぜ糞コードなのかをきちんと説明できる状態になくてはなりません。
そうでなくては、孤独な戦いを強いられることになります。
また、そのコードがたまたま彼のセンスに合わなかっただけで、本当は糞コードではなかったという可能性もあります。
もし、技術的負債の言語化も不十分なままに「これは糞コードだ！」と決めつけてかかれば、せっかくリファクタリングの工数をかけた結果、負債がまた別の負債に変わっただけ...という悲劇に終わるかもしれません。
技術的負債が大きければ大きいほど、深刻であれば深刻であるほど、あなた一人の力で乗り切ることは難しくなります。
だから、自分だけが背負い込むのではなく周りを巻き込んでいくべきであり、エンジニアはそのための術を身につける必要があります。
その1st STEPが負債を言語化するということです。
糞コードはなぜ糞なのか説明を試み、どうすればもっと良くなるのかチームで策を練ることです。
言語化というと難しそうにも聞こえますが、幸にして我々は先人たちの残した多大なる恩恵に預かることができます。
書店に赴けば、コードの品質を図るための複数の尺度を提示し、それぞれの指標を細かく分析した本に出会うことができます。レガシーコードとは何かを明確に定義し、それを段階的に直していく方法について説明した本も見つかるかもしれません。
彼らの努力の成果を、叡智の結晶を、いつでも自由に拝借し、明日の業務に活かすことができます。
このようにして、一体何がどのように不味いのかうまく説明できるようになると、周りのサポートも得やすくなります。
もちろんそうした会社ばかりではないですが、運が良ければリファクタリングのためのちゃんとした工数だって確保できるかもしれません。
別の見方をすれば、大きな技術的負債を前に絶望したとき、それは改めてコード品質について学んでみる良いチャンスです。
糞コードにただ黙って耐えていても、開発者として下へ下へ落ちていくばかり。
妥協したコードを書くことだけが日課になると、本当はどうあるべきかということには次第に目も向かなくなくなります。
結果として、設計スキル向上は望めず、エンジニアとしての市場価値も上がりません。
ただし、もし糞コードと建設的な形で向き合う機会を得られたなら、それは別です。
糞コードを乗り越えた経験がやがて大きな財産となるかもしれません。
このことについては、後でもうちょっと考えてみます。
非生産的な組織や開発体制
開発組織や開発体制が正常に機能しておらず、ユーザーに迅速に価値を届けることができない場合があります。
プロセスが崩壊していて、まともに開発を進めるどころではない...
これはある意味、技術的負債よりもさらに厄介な問題です。
ともすると、組織や体制の問題が根っこにあり、技術的負債はその表出の一つに過ぎないことさえあります。
それはもう一人のエンジニアにどうこうできるようなことではないと、匙を投げたくなるのはわかります。
しかし、もし強い意志があれば、そこに楔を打ち込むことくらいはできるかもしれません。
ただ、そんなとき、いかに人が変化を厭うことか、いかに組織が現状にしがみつきたがることか。
立ち向かうことを選んだら、それを痛感せずにはいられません。
最大の障壁となるのは、問題の否認です。
組織や体制を少しでもマシなものにするためには、十分な知識をつけ、組織論やソフトウェア開発の手法についてチームの中で誰よりも詳しくなることが肝要です。
しかし、それでもなお、どんなに知識をつけても、解決できない問題もあります。
理屈を学ぶことは極めて重要ですが、理屈だけでは開かない扉もあるという世知辛い話、それが問題の否認です。
曰く、「今のままでも十分うまくいっているから変える必要はない」
曰く、「これは仕方ないことだから、我慢する他はない」
曰く、「ウチにはウチのやり方があるから」
まぁ、それで本当に上手くいっているのなら、何も言うことはないのですが、ね...。
つまり、正しい問題意識と合理的な改善案を有していたとしても、なお、反発はあるものです。
ケロッグ経営大学院の経営学教授ローラン・ノードグレンは、『The Human Element: Overcoming the Resistance That Awaits New Ideas』の中で、人や組織が変化を拒む理由を次のように分類しました。
「惰性」:自分が馴染みのあることにとどまろうとする欲求。
「労力」:変化を実行するために必要な努力やコスト。
「感情」:提示された変化に対する否定的感情。
「心理的反発」:変化させられるということに対する反発。
人は理屈だけでは動かず、こうした感情的な反発をも乗り越えていかなければなりません。
肝心なのは、小さく変化を起こし、現状を少しずつ変えていくことです。
例え、今がどれほど悪く、どれほど大きな変化が必要だとしても、「全然駄目なので抜本的改革が必要だ」と主張することが、いつも賢明だとは限りません。
嘘をつくみたいで気持ちは咎めますが、「今のやり方も良い面があるんだけど、こうするともっと良くなるのでは...？」などと、ほんの少し言い方を変えてあげた方がいい場合もあります。
そうすると、意外とすんなり周囲は受け入れてくれるかもしれません。
例を挙げてみます。
はるか昔、太古の世界には動物や聖霊を崇拝するアニミズムというものがありました。
そこでは、蛇の頭に鷲の翼といったような奇妙に合成したような動物がしばしば見られます。
一つの説に過ぎませんが、これは、次のように分析されています。
ある日、蛇を崇拝するA族と鷲を崇拝するB族が戦いをして、A族が勝ったとします。
彼らはAB族として共に暮らしていこうとしますが、そこでもし崇拝の対象として蛇を選ぶならば、B族からは不満の声が上がり、統治に支障を来たします。
新しいAB族として統合して生きていくためには、どちらの部族にとっても、納得のいく神が必要です。
そのために、蛇の頭に鷲の翼の神は、折衷案として都合の良いものとなります。
こうして、文化人類学の世界では、崇拝の対象として動物の合体したような神の姿が多く見られるというわけです。
開発組織や開発体制を変えるというのも、これと似るものがあります。
「鷲は駄目だ、これからは蛇だ！」と高らかに宣言したところで、訝しげな視線が投げかけられて終わりです。
抜本的に変えたい気持ちは胸にしまっておいて、「ちょっとだけ新しい開発手法を取り入れてみない...?」と言ってみるのもありだと思います。
まずは鷲に蛇の頭をつけてみて、だんだん蛇の要素を増やしていく...、
そんな小賢しいマネが必要になることもあります。
もちろん、開発チームが本当の意味で「アジャイルになる」ためには、「アジャイルを取り入れる」だけでは不十分です。
しかし、それもジワジワと毒を流し込むように、段階的に染め上げていかなくてはなりません。
ゆでガエルの法則ではありませんが、気づいたときには、いつの間にか抜本的な変化が起こっていた、という状態も策略の一つではあります。
手に余ること、手のひらにあること
ここまで読んで「いやそんな面倒な苦労をするくらいなら、転職した方が早くね？」と思われた方もいるかもしれません。それはそうです。
しかし、完璧な理想の職場というものは、どこにも存在しません。
ある程度は今の会社に留まって頑張ってみる必要があり、しかし、度を越して悪い環境は、なる早で転職した方が賢明です。
転職のタイミングというのはいつも難しいもので、留まりすぎて後悔することもあれば、時期尚早に辞めすぎて後悔することもあります。
「もっと早く辞めていれば」と「もっとあそこで踏ん張っていれば」の間で、時に我々の想いは揺れます。
その間の分別と見極めは困難ですが、少なくとも所属組織に対して日常的に不満を漏らす自分を発見したら、それは辞めどきかもしれません。
希望を伴った忍従は活動力を与えますが、憂を帯びた諦観は活動力を奪います。
...あなたは、今、どちらにいるでしょうか？
繰り返しになりますが、やはり完璧な職場はありません。
そういう意味では、本記事が設定した問い自体が欠陥を孕んでいたとも考えられます。
すなわち、職場には必ず問題があり、エンジニアリングは楽しいことばかりではありません。
今、我々の右手には安楽が、我々の左手には苦悩が握られています。
右手だけを使って食事をとろうとする者に、人生が微笑むことはないでしょう。
与えられた両の手を使って生きることが、生命のマナーです。
だから、今更強調するほどのことでもないですが、転職に当たって考えるべきは「どちらがより楽しいか」ではなく、「どちらがより成長できるか」「どちらがより自分の能力を発揮できるか」です。
技術的負債も、組織の問題も、どこに会社にだってある避けられないことです。
だから、この人生の岐路に際して、どちらの道に進んだって必ず苦悩を伴う...
そのことを予め織り込んで置かなかった者のことを、人はジョブホッパーと呼んで憚りないでしょう。
欧米には、"Every coin has two sides"という諺がありますが、これが正しくその通りです。
したがって、善く働くためには、"自分の星を追え"、そういうことなのかもしれません。
スーパーハカーなるすべての者は、会社に使われるのではなく会社を使いながら、それが楽な道なのか気にもかけないで、頭上の一番明るい星を追いかけていきます。
最後まで読んでいただきありがとうございました。
Discussion