Build Insiderオピニオン：竹原貴司（1）
仕事とプライベートは分け「ない」方が自分らしく気持ちよく働けるという考え方
― 小さなチームのエンジニア・ライフスタイル論 ―
日々をどう過ごすか。仕事とは何なのか。小さなチームに所属するソフトウェアエンジニアが考える仕事とライフスタイルの関係、そして「アトムの世界をハックする」ために必要なこととは。
大きな企業、中くらいの企業、小さな企業、企業のサイズにかかわらず、ほとんどの人はチームで仕事をしているだろう。「チームと認識しているかどうか」という問題はあるにせよ、人と関わらずに達成できる仕事というのは存在しないのではないだろうか。それは筆者が所属する会社とて例外ではなく、やはり「チームで仕事をしている」という事実に間違いはない。
でも、そのサイズは驚きの最小人数体制だ。今現在、筆者の会社ではメンバーは社長含め全体でたった4人である。うちエンジニアが3人もいるという、いびつに思える組織形態で、自社プロダクトを作り、それを自社管理しているインフラに載せ、マルチテナントプラットフォーム（具体的にはECシステム）として提供することを生業としている。そう、こんなに小さいのに「ECプラットフォーム」という手の掛かりそうなサービスの提供を実現しているのだ。
われわれがこのように小さなチームで、どのようにフィーチャー定義から開発、インフラ管理、24H365D（＝年中無休）でのシステム運用を続けていけるのか。その手段や考え方について、これから本コラム連載の中で少しずつでも皆さまに伝えていけたらと考えている。
もちろん、本連載を読まれる方は、ECプラットフォームを提供しているわけでもなく、始めたいと考えているわけでもないだろう。だが、皆さんと仕事内容は違うにしても、日々行われている行為や、システム構成、開発スタイルなど、参考にしていただけることがあるのではないか、もしそうならそれを伝えていくことも筆者自身がエンジニア人生の中で成し遂げたいことにつながるのではないか、と考え、編集者から打診された本コラムを引き受けた次第である。エンジニアの中でも特に、「SIから脱皮して新たなプロダクトの開発をスモールスタートしたい」という方や、スタートアップですでに何かを作っている／これから何か作りたいという方には、より身近な先行事例として参考にしていだけるのではないかと期待している。
本コラム連載のバックグラウンドや始めるきっかけは、このようなことだ。次回から本格的に始動するが、今回はそのプロローグとして、筆者自身の仕事に対する考え方をつづりたいと思う。とりとめのない非技術の内容になってしまってはいるが、今回は「マインドセットを事前に共有する」という趣旨としてご容赦いただきたい。なお、次回以降で始まる本編で説明する予定の技術領域については本稿末尾で紹介する。
～ 本コラムを始動するためのプロローグ ～
仕事とプライベート
実は筆者は基本的に、仕事とプライベートというのを分けて考えていない。
それは、「職場が自宅」（いわゆるテレワーク）という状況がそうさせるのではないか？ という考え方もあるかもしれないが、必ずしもそういうことではない。どこにいても、いつでもアラートは飛んでくるし、土曜の夜にふと新しい機能を作ってみたくなり、そのままそれを作り上げて月曜にGitにpushすることは普通にある。
「では仕事漬けで遊んでいないのか」といわれるとそんなこともなく、「遊びすぎ」といわれてもおかしくない程度には遊んでいる。ほとんどはジムでの筋トレや、何らかのスポーツだが。映画も見るし、海外ドラマが好きでとてもよく観る。Feedlyには700くらいのFeedが登録されていて、毎日何かないかと、情報マニアなんじゃないかと思うくらいに読みふけるし、毎日読書もする（紙の本でもKindleでも）。
にもかかわらず、仕事とプライベートを分けて考えていない。
「それ仕事じゃないよ！」とか「おかしいじゃないか！」と思う方もいらっしゃるかもしれないが、全ては自分の価値観や知識欲、感情の赴くままの行動であり、仕事もプライベートも全てがひとつなぎの秘宝のようなもので不可分なのだ。
開発者っぽい表現をするなら、「コンテキストスイッチを極力しない」という感じだろうか。確かにそうやって、区切りのない同じ日常を繰り返していると、いろいろと行き詰まることはある。そして、「うぎゃー！」と叫びたい衝動に襲われたりもする。そんなときは、その感情や精神的なゆらぎをベンチプレスで解消させることもあるのだが、それでも、コンテキストをまるごと入れ替えて、頭の中を空っぽにしているイメージではない。ただ、少しSleepさせているだけ、という感じ。といえば伝わるだろうか……。
このような考え方をするに至った理由・背景は、「仕事」「時間」「エンジニアという職業」に対して筆者は以下のようにしたいと感じている／考えているからである。
「仕事」でやりたいこと、できること、やらなければならないこと
筆者には仕事としてやりたいことがある（その内容は今この記事の主題ではないし、どうでもいいことなのであえて公言したりはしないが）。たまたま、開発することが好きである。そして、それを行うことでお給料をもらえる環境にある。作りたいものもある。作ってほしいといわれるものもある。プラットフォームを運用することは会社の業務としてやらなければならないことである。
そして、何より、それら全てを自分でどうするかを決めている（仕事をする大人として、なんて幸せなことだろう）。
好きなことができて、社会とつながり、お給料がもらえ、たまに、ごくたまに感謝されることもある。「誰かのために」ではなく、あくまで「自分のために」そして「家族やチームのために」しているだけであり、その先にある人や社会にまで「○○のために」という気持ちを持っていくのは個人的に難しい。けど、たまに感謝されたり、褒められたりすると少し嬉しくなったりもする。そこは、狙っているわけではなく、あくまで人生のおまけ、お菓子についてくるおもちゃ、アイスの当たり棒のような、「おぉ、いいことあった！」という感じなのである。
「時間」の使い方と認識の仕方
仕事の次に時間も、筆者にとって仕事とプライベートを同時に充実させるための重要なファクターである。時間は全ての人にとって平等だ。だから、それをどう使うか、使っている瞬間をどう認識するかが大事である。
ただ「時間」を認識するだけでよい。それだけでも、「幸福」と感じることがたくさん増えるはずだ。「思考→言葉、言葉→行動、行動→習慣、習慣→性格、性格→運命とつながっている」とマザー・テレサは言った。ほんの小さな瞬間の思考が人生そのものを決定づけると説いたのだ。そうだな、と思う。一瞬・一瞬の時間を意識することが、結果的に幸せなエンジニア人生そのものへとつながっていく。だからこそ、遊びなどのプライベートの時間も含め、瞬間・瞬間を大事にしなければならないなと強く感じるのだ。
「エンジニア」として
上記の2節はあまりにも、個人ブログのような内容でコラムとして成立してないと、編集に怒られそうなので（編註：怒りませんて）、そろそろエンジニアとしての話も絡めようと思う。
エンジニアといっても、ここでいうのは「ソフトウェアエンジニア」のことだ。一般的にはSEとかプログラマーとかコーダーとか、そういう表現をする職種。そして何をしているのか認識されにくい職種。おばあちゃんに分かるように説明するのがとても難しい職種のことだ。
ソフトウェアエンジニアは、どのようなことを日頃行っているのだろうか。筆者が所属しているような小さなチームだと、まさに何でもやる必要がある（それが「苦になるか」と問われたら、「得意ではないが苦ではない」と答える。ただ、事務作業と会社経営は好きではない。嫌いといってもいいくらいだ。そこは、さすがに得意な人に任せたい）。では、筆者がエンジニアとして日々どんなことをしているのか。思い付くものを以下に挙げてみた。
- プロダクトの方向性にあった、ケーパビリティの決定
- アーキテクチャの設計
- 開発・運用を考慮したインフラの構築
- メータリングする機能と方法の設計
- CI／CD基盤の構築
- VPNは必須
- ADでの認証の一元管理とリモートデスクトップでのどこでもオフィス化環境の構築
- やりたいことができる外部サービスの選定と接続
- アラートの適切な対処
- プロダクトの開発
- 社内ツール・システムの開発
- 運動
- 読書
- Feedのチェック
- 食事
- 睡眠
- 泥酔
この1つ1つを取り上げて内容を説明するときりがないので説明はしないが、どれも誰かがやらなければならないこと、もしくは誰もがやっていること、というのは理解していただけるだろう。それを筆者自身もやっているわけで、特別なことは何もない。だけど、これらの中のどれかが欠けると、イメージ通りにチームや自分の仕事を回せなくなるので、やはりとても重要なことでもある。
エンジニアという職業は、そういう特別ではないが不可欠な日常をこなしていく仕事なのではないだろうか。そこでは仕事かプライベートかと明確にコンテキストを切り分けるよりも、シームレスに満遍なく個人あるいはチームとしてこなしていく仕事およびプライベートの進め方がより強く求められる。
ビットとアトム
少し脱線するが、ソフトウェアの世界（ビット）と物理の世界（アトム）をイメージしてほしい。ビットとアトムは全く異なる世界だが、ビットはアトムなしでは意味をなさないだろうし、アトムはビットなしでは能力を存分に発揮できないだろう。つまり、ビットにより成り立つ「コンピューター」と、物理世界に生きる「人」は切り離せないのだ。
アトムの世界において、誰かにとっての正しさが、唯一無二の正義ではない。人には感情もあれば、過去を否定したくない・されたくないという思いもある。それを蔑ろにしないよう意識しつつ、最善だと思う手を打ち続けることが人にとっては大事だ（その結果、もちろん失敗することもあるし、成功することもあるが）。アトムの世界から見ると、ビットの世界にあるコンピューターはただの道具ではなく、そうやって人に寄り添うための表現手段（具体的には今後の連載で説明するような技術やサービス）としても活用できる。そう考えると、「コンピューターはとても自分にあった表現手段だな」と筆者は感じる。
アトムの世界で、いかに自分らしく、気持ちいいライフスタイルを送るか。不具合に怯えたり、難しい問題から逃げ出したり、他者からの圧力に心を揺らさずに済むようにしたりするために、どうすればいいのだろうか。エンジニアとしてどう問題解決（＝ハック）していけばいいのか。
アトムの世界をハックするにはまず、身近なところからハックしていくのが近道で王道なのではないか。そのハックが、「仕事とプライベートを分けて考えていない」という思想であり、その根底にはここまでに説明してきた、
- 本当にしたい仕事に取り組むべし
- 使っている時間を認識し大事にすべし
- エンジニアとして不可欠な日常を満遍なくこなしていく仕事の進め方をすべし
という筆者なりの行動原則が存在するわけである。
そのハックのために、知識を集め、知恵を駆使し、作るだけにとどまらない、もっと大きな視点で開発というものを見つめることが必要だと考えている。
プロローグの総括と、今後の連載で予定する技術領域
さて、そろそろまとめに入ろう。
心の安寧を得るための、仕事とプライベートの全てが1つの時間軸に並んだ「小さなチームのエンジニア・ライフスタイル」について説明した。それを追い求めるのに必要な基盤を構築していくために、筆者のチームメンバーが取り組んでいることはどんなことなのだろうか。これについて紹介することで、次回以降で説明するテクノロジ領域について簡単に触れていきたい。
まず、システムが正しく動いているのか、無駄なことはしていないか、異常な動きをしていないかを知ることだ。それには、正常な状態を認識する必要があるだろう。正常な状態を知るのに必須なことはロギングであり、リソース監視である。
筆者のチームでは、サーバーには全てWindows Serverを使用し、ASP.NETを使ってWebアプリを開発して、それをIIS上で動作させている。使っている言語はC#、データベースはSQL Serverと、ものの見事にマイクロソフトのテクノロジスタックだ。もともとはオンプレミスで稼働させていたシステムを、今は全てクラウドで動かしており、Azureを基本として、その他のさまざまなWebサービスを活用している。
このWindowsサーバー環境を運用する上で欠かせないのが、
- イベントログ
- IISのアクセスログ
- アプリケーションログの収集
- ハードウェアリソースの利用状況の監視
といったロギングやリソース監視である。複数台のマシンを効率よく管理して、アプリを改善するにはこれらが非常に重要になってくる。
「効率よく管理」は、特に小さなチームでは大切だ。マシンの1台1台にリモートデスクトップでログインしてログをチェックしたり収集したりすることに、パワーはかけられない。また、小さな会社でもあるので、お金をたくさんかけることも難しい。いかに少ないコストで、最大限の成果を出せるのかをとにかく意識している。
そういった運用・監視を中心とした、小さな会社・小さなチームならではノウハウや教訓を今後のコラムでは書いていく予定だ。
「運用・監視」と聞いて「わたしには関係がない」と思われた方もいるかもしれないが、よりよいアプリ、よりよい顧客体験を提供するためには、運用・監視を含めたALM（アプリケーション・ライフサイクル・マネジメント）は全ての開発者が意識した方がいい。なぜなら「問題がないわけではない。問題を見てないだけだ」となってしまわないためだ。そうならないための環境作り、システム作りを、今後のコラム連載を通して考え、実践していっていただけることが、本コラム連載の最終目標である。
竹原 貴司（たけはら たかし）
2014年9月より株式会社CommerbleにてECプラットフォームの提供に従事。
コンピューターと向き合い始めて四半世紀。
ゆかいな仲間たちと、素晴らしいプロダクトを提供し続けていきたい。
1. 【現在、表示中】≫ 仕事とプライベートは分け「ない」方が自分らしく気持ちよく働けるという考え方
日々をどう過ごすか。仕事とは何なのか。小さなチームに所属するソフトウェアエンジニアが考える仕事とライフスタイルの関係、そして「アトムの世界をハックする」ために必要なこととは。
2. “小さな会社”が選択したログ管理の手法 ― バランスの取れたテクノロジ選択をしよう
ちゃんとやるけど、やりすぎない。そんなバランスの取れた「運用技術の選択」とは？ 小さな会社が開発・運用するシステムでは、どうログ管理しているのか。Logentriesというサービスに全ログを集約した筆者の事例を紹介する。
3. 殻を破り、傾聴しよう ― ログの収集・可視化・監視はリスク管理である
ビジネスモデルの観点からサービスの安定提供が求められる場合、サーバーの“わずかな悲鳴”を聞き逃さないためのリスク管理が必要になる。なぜそれが大切なのかを示し、.NETでログ収集する方法を説明する。
