自分の働き方の「ブループリント」をつくってみた
ブループリント
- Shopifyで働いていたときに、いく人かが「自分のブループリント（Blueprint）」というものを社内の自己紹介用につくっていました。
自分の働き方を知ってもらうことで、よりよい仕事環境のマッチングを図ろうというものです。
https://note.com/kenzan100/n/n83cd4dafe9b8 に書いたのですが、最近フリーランスエンジニアになったので自分の働く上での価値観を言語化してみました。
私のブループリント
(v0.1)
Data is like a wine, Code is like a fish.- コードは魚のように腐り、データはワインのように醸成される。
(https://www.flickr.com/photos/psd/52965054397)
ウェブアプリケーション開発の中で、コードは本番環境にできるだけ早くリリースされるべきものです。仕掛かり中のPRは、それを取り巻く状況が変わる中で、すぐに「魚のように」腐ります。PRが何週間も放置されることで、コードベース上でのコンフリクトも増えるでしょう。ビジネス仮説も変わってしまうかもしれません。
本番環境にリリースしてこそ、はじめてコードは価値を持ちます。みんなでレビューを優先し、PRのリードタイムを短くしましょう。
一歩で、データはワインのように時と共に育っていくものです。
ゆえに、データの取り方がとても大事です。データに基づく意思決定に役立てるよう、またデータそのものがビジネスの競争力になるよう、そのアプリケーションを取り巻くデータは積極的にとり、その構造化が意思決定に耐えうるものなのか、定期的にレビューをしましょう。
Choose Boring Technology.- チームにとって「こなれた技術」を選ぶ。
Photo by Sylvester Sabo on Unsplash
ともすれば新しいサービスや技術スタックを学習のために使いたいと思いますが、それは「トイ・プロジェクト」という学習のスコープにとどめておくべきです。ハッカソンとか。
ビジネスで価値を持つのは、そのチームがこなれた技術スタックで、スピード感と安心感をもって機能開発が進められることです。そのためにも、革新的な技術は、現在のスタックが解決できないと明確に証明できた時点で、導入を検討しましょう。
How I work.- PRの区切り方。
Photo by Dan Cristian Pădureț on Unsplash
上記のことから、PRは可能な限り1日よりも短い時間帯でレビューできる状態まで持っていきます。
複雑なプロジェクトを「いかに1日単位でレビューできるPRに変えていくか」に対して、自分は情熱を燃やしています。
たとえば：
- WRITEだけはじめておいて、READは後から（新機能の場合）
- READだけ変えておいて、WRITEは後から（リファクタリングの場合）
- 社内専用のパスワード管理下でリリース（リリースフラグ）
- トラフィックのN％（最初は社員のみ）だけを振り分ける
などなど、本番環境で障害を起こさずにリリース単位を小分けにすることがとても大事だと信じています。 それを実践できる https://martinfowler.com/bliki/StranglerFigApplication.html パターンなども好きです。
Observability matters.- 本番環境の監視・データの民主化が大事。
Photo by Luke Chesser on Unsplash
本番環境をQAの場所とするには、SREのプラクティスが必要不可欠です。
本番環境に類するステージング環境を作ろうとしたことがある方なら分かると思いますが、ステージング環境はセキュリティリスクを増すだけでなく、データが古いことからの「偽りのQA」を生みます。
本番環境以上に、リリースの確度を上げる場所はないと現在自分は思います。そのために、オブザーバビリティはとても重要です。
本番環境がリリースやピーク時にどういう振る舞いをしているのか。レイテンシ、スループット、データ量の増加具合などをほぼ全てのメンバーが主体性を持って確認できる状態にしておくことが、アウェアネスを生み、結果的にスピードを落とさずに障害を防ぎます。
ブループリントを書いてみた
いざ言語化してみると、まだここには出てこない価値観などたくさんありそうだなと思いました。定期的にアップデートしていけたら。ではまた、近いうちに！
Discussion