BASEプロダクトチームブログ

ネットショップ作成サービス「BASE ( https://thebase.in )」、ショッピングアプリ「BASE ( https://thebase.in/sp )」のプロダクトチームによるブログです。

私が愛した怠惰・短気・傲慢

BASE Advent Calendar 2019 Day 17

この記事は BASE Advent Calendar 2019 の 17 日目の記事です。

devblog.thebase.in

こんにちは。Platform Dev Section マネージャーの大窪(@bonnu)と申します。

BASE には 2018 年の夏に入社し、現在はバックエンド基盤や SRE(Site Reliability Engineering)、フロントエンド基盤を担う各グループのマネージャーを務めさせてもらっています。

今回のアドベントカレンダーでは実用的なネタを思いつくことができませんでしたので、ちょっとしたコラムのようなものを綴らせていただこうかと思います。

私が愛した言語・Perl

突然ですが、私がこれまでエンジニアとして仕事をしてきた中で一番長く書いていた言語は Perl です。

現在は日本のWeb業界においてのシェアを近代的な言語(※ Golang、Java、Scala、その他 LL 等)に奪われ、かつて Perl で作られていたサービスが別言語にリプレイスされた話を聞く事もあります。なのでよく採用されている言語とは言えませんが…

テキスト処理に対して強力なユーティリティが多く、また豊かな表現力(TMTOWTDI1)と低レイヤーへのアクセスの良さ2から機能実現力が高く、コマンドラインツールに限らず掲示板や小規模サイトからブログシステム、大規模ウェブサービスまで様々なシーンで利用されていました。 (かつては C や Java、C++ など、今もよく使われている言語に肉迫していたようですね。2000年代は頑張った…) https://youtu.be/Og847HVwRSI

Larry Wall が定義した「プログラマの三大美徳」

そんな Perl の生みの親、Larry Wall 氏はかつて Perl のラクダ本(プログラミング Perl3。Perl の実用的な解説書)でプログラマの三大美徳を定義しています。

laziness, impatience, and hubris
  • 怠惰(怠慢) Laziness
  • 短気 Impatience
  • 傲慢 Hubris

これは Perl に限らずプログラマ界隈においてとても有名でよく引用されている言葉であるため、現在エンジニアとして活躍されている方にとっては今更説明の必要もないかもしれませんが、今回は改めてこの美徳をテーマにしたいと思います。

それぞれの美徳について

怠惰(怠慢) Laziness

The quality that makes you go to great effort to reduce overall energy expenditure. It makes you write labor-saving programs that other people will find useful, and document what you wrote so you don't have to answer so many questions about it. Hence, the first great virtue of a programmer.


全体的なエネルギー消費を削減するために多大な努力を払う気質。他の人が役に立つと思う省力プログラムを作成し、あなたが書いたものを文書化するので、それほど多くの質問に答える必要はありません。したがって、プログラマーの最初の大きな美徳。

例えば繰り返し行われる作業、同一の処理を表現するコード、同一概念を扱う多数の関数など、それらの抽象度を見極めて適切な粒度・単位でカプセル化することで同じ事を繰り返さないようにしたり、再開発しなくてよいように工夫する気質と読み取っています。

さらにそれにはドキュメントを付属させることで、他者に伝えるための時間や手間といったものを省くことができるとまとめられています。

私はエンジニアであった当時よりドキュメントを書くのがあまり得意ではなかったので(現在も目下の課題です)、この点については片手落ちだったと反省があります。

短気 Impatience

The anger you feel when the computer is being lazy. This makes you write programs that don't just react to your needs, but actually anticipate them. Or at least that pretend to. Hence, the second great virtue of a programmer.


コンピューターが怠けているときに感じる怒り。これにより、ニーズに対応するだけでなく、実際にそれらを予測するプログラムを作成できます。または少なくともそのふり。したがって、プログラマの2番目の大きな美徳。

機械翻訳した上でですが、私の解釈として「怒り」という表現は「不便な事を思い通りにしようと直感的に思う」事を指すと考えています。

ビジネス要件、機能要件に対して先々も応えられる処理として仕上げるべく熱量をもてたり、すぐにロジックの整理に頭が向かう様がイメージできます。

また、短期的なニーズだけをただ満たすだけでは足りず、同一パターンの処理が想定できるならばそれらを予め想定しておけという意味合いがあるようです。小飼弾さんの記事ではテンプレート処理に関しての言及がありますね。 短気の裏に潜む焦りや不安から、先んじて検討して対処しておけ、というところでしょうか。(Impatience に「焦り」「苦痛に耐えられない」という意味を見つけましたため)

傲慢 Hubris

Excessive pride, the sort of thing Zeus zaps you for. Also the quality that makes you write (and maintain) programs that other people won't want to say bad things about. Hence, the third great virtue of a programmer.


過度のプライド、ゼウスがあなたを驚かせる(神罰のような)もの。また、他の人が悪いことを言いたくないプログラムを作成(および保守)できる気質。したがって、プログラマーの3番目の大きな美徳。

プログラマとして品質に妥協せず、またその品質を示すべく説明できること。 プログラムであればテストをはじめとして、その成果物の妥当性・正当性を担保する仕組みを整えることで、その自尊心を守りなさいという美徳と言えます。

これもまた小飼弾さんの記事を参考にしますが、傲慢さは他者に対して発揮されうる気質であり、互いに正当性を示し合うことで議論や競争を生み、それが結果として発展を促すという捉え方ができます。

何を「愛して」いたのか

美徳は必ずしも「態度」に表れることを指していない

広くインターネットでの三大美徳に関する議論を眺めてみると、それぞれの美徳についての定義と定義名(Laziness、等)について意味が対照的でなく、ひねくれていると捉えられる事があるようです。それら定義名はどれもネガティブな印象を持ってしまいそうなものばかりですが、その理由は Larry 氏のユーモアから来ていると私は考えます。

美徳それぞれの意味はどれも高い視座を表現していますが、そのまま定義名を厳格に表してしまっては極論、あまりついてくる人はいないでしょう。まずは「なんだそんな事でいいのか」と思わせるキャッチーなところから入り、その上で解釈が進むことで本来の定義が意識に刻み込まれるような、そんな美徳になっていると感じています。

なのでこの定義名をそのまま態度に表してしまうと… 特に組織活動において、様々なしくじりが生じてしまいます。私は自分の失敗の数を数えていませんが。

オープンソースの原点的考え方として捉える

今でこそどんなプログラミング言語でもソースコードを共有するエコシステム(CPAN、npm、Packagist、Golang+GitHub、etc…)が当たり前になりましたが、当時 Larry 氏が Unix のツールを開発していた時代は一体どんな状況だったのでしょうか。

ネットがそれほど速くない時代(そもそも商用 Internet がなかった)、今よりも手元だったり、企業や大学のイントラ内にだけコードがあることが殆どで、プログラムが人の目に触れる機会はとても少なかったのではないでしょうか。

そういった状況で開発された OSS が安心して使えて高い品質を保つ事を担保するためにも、草の根活動的な呼びかけの一種としてこの美徳があったのではないか、と私は勝手に考えてしまいます。

いま、マネージメント業務をする立場としてどう捉えるか

ここまで懐古厨として話を進めてきましたが、そろそろ現在の私の立場に話を戻します。

私がこれまでプログラミングを公私ともにやってきて美徳を正しく体現できたとはとても言えず、その視座の高さに打ちひしがれる思いがありますが、やはりこの美徳は改めて自分の内に秘めて持っておきたいと感じました。

マネージメント業務をする立場においては、各種業務改善や日々の運用をしていくにあたってこれら美徳を判断の参考にすることができます。会議量やフローの適切化やコミュニケーション・パスの整理など、怠惰短気の美徳に従えばどうすべきか…。

また今回挙げた三大美徳を一種の宗教だと捉えた場合には当然その他の宗教を持つ方もいると思いますが、各々がその教えや意志を大事にしながらエンジニアリングしていくことで、傲慢の美徳に従ってコラボレーションを活発にさせることができます。

最後に

日々の業務でこれらの美徳をそこまで意識する事はありませんが、たまにでも思い出してみる事で自身の振る舞いや判断を振り返るきっかけにできると感じました。

最近はコードを書く機会が減ったことで純粋にプログラマーとしての価値観や観点を忘れてしまうことがあり、今回は自戒の意味を含んで、この三大美徳をテーマとさせていただきました。

明日のアドベントカレンダーは Owners Marketing グループの栗田さんと Product Management グループの藤井さんです。
刮目して見よ。


  1. There’s More Than One Way To Do It:やり方はひとつじゃない

  2. XS:C のコード(または C ライブラリ)との間の拡張インターフェースを作るのに使われるインターフェース記述ファイルフォーマット

  3. https://en.wikipedia.org/wiki/Programming_Perl