‣
BIO
I’m Yuki Shinohara (篠原 祐貴) @shinofara
I was born in 1987. I’m Software Engineer since 2009.
I love Bouldering, Photography, Gaming, Snowboarding, Diving, Cooking and Programing.
87年1月大阪生まれ。2009年にY!新卒入社以降東京でWEBの世界で生きてます。
ボルダリング、 、ゲーム、プログラミング、写真 、スノーボード、料理を生きがいにしてます。
大体のSNSは @shinofara でアカウント作ってます。ダイビング
いま興味を持っている領域
何をするひとでありたいか
直近のふりかえり
2022年2月からSpirに関わり、5月に入社。詳しくは「 」。日程調整ビジネスカレンダーのSpir（スピア）、CRO(Chief Reliability Officer)に篠原 祐貴が就任
そして同年6月からCTOというタイトルに変更。CROって一般的にはRevenueを指すことが多いので、説明を毎回する苦労がありました。
向き合ってきた事を簡単に整理（注意：向き合ってきた＝僕一人の力では全く無いです）
- 開発の生産性
- 過去に「モジュラモノリス….」で書きましたが、成長の過程で増えてきた負債や、組織的な課題を解決する事はもちろんですが、生産性を高め続けていくというテーマでは、コードの品質や生産性、チームでドメインや業務に関する理解を高めて、開発の手戻りを減らしていくための、型の構築、型を用いることや、型のアップデートを継続的に行う運用などの体制・習慣化などの取り組みを進めるなどしてきました（注意：僕がではなく、組織で）。
- DevOps, ブランチ戦略などなどの技術的な生産性も含む
- プロダクトマネジメント
- 会社としてはまだまだBe Agileとは言えない状態でもあり小さく検証ができていない状況でしたので、型にはめていく事はもちろんとして、「小さく検証する大切さ」を浸透させていく事を始めました。（注意1: こちらも当然の事ながら僕がではなく、組織でみんなで、注意2: 一度出来た文化や思考は簡単には変化しないので、徐々に徐々にです。これからもまだまだ）
- セキュリティとクラウド
- GCPの構造を誰も完全に把握できていないなどの状態でもあったので、後追いのIaC化とアーキテクチャの課題を調査。インフラリソースと何が依存しているのかなど、アーキテクチャ全体を可視化することなど。
- 情報管理と透明性
- Notionを利用しているが、データベースが複数あったり、 というよりメモに近い情報があったり、誰が何をしているか分からない状態だったりなど、知りたい事をしるという事が難しい状態でしたので、Notionエンジニア的に組織としてのNotion管理の型をつくり、まず同じ場所に書かれる状態を作り、徐々に整理に関して取り組みを進めていくなど。ただそこにデータがあるだけでは「情報の透明性」が高いとは言えないので、ただドキュメントを書くだけく、 情報を正しく残す、情報を正しい状態に更新する、情報にたどり着けるように整理する、日常的に必要な情報をしぼるなど、「情報の透明性」を高め続けるための運用が組織的に回るように向き合い始めるなどドキュメント
- 採用設計と等級設計
- エンジニアの等級というより、全社的な等級を設計
- マネジメントかスペシャリストで分かれる設計ではなく、究極どちらも高められる設計。今の時代はRoleなども多様化していることもあり、マネジメントとかスペシャリストとかの言葉で簡単に決める事はできない考え
- データ
- xOps、プロダクトでデータを利活用してより正しく判断行動できるように
- GA、BQ、Lookerや、スプレッドシートなど何がどこにあるか分からない状態で、よくあのデータどこ？などのペインがそこにあった
- BQをデータ ウェアハウスとして、全てのSaaSやデータの中心になるように設計
- AirbyteでETL、CensusでReverseETL、プロダクトはAmplitude、カスタマーサクセスはHubspot
- GithubのPRサイクルなども同様の仕組みでBQに蓄えLookerで可視化
- データカタログとか、までは未着手。BQを中心にそれぞれのSaaSでそれぞれの課題を解決できる事とエンジニアがいなくても拡張できる状態が最初のゴール
仕事の歴史
| Date | Name |
|---|---|
August 1, 2023 | |
May 1, 2022 → December 31, 2023 | |
October 21, 2019 | |
August 1, 2018 | |
March 1, 2017 → April 30, 2022 | |
December 1, 2016 | |
December 1, 2014 | |
February 1, 2012 | |
March 31, 2009 |
自分の技術的なスキルを一度洗い出してみます。（最後のUpdateは2021年くらい）
スキル書き始めて思ったけど、結局それらをどんな風に使ってる？とかが大事だとおもうので、後半にいくつか書いてみます。いくつかは使ってるレベルなので、使えるとは別物です。
- 言語
- Go / Python / Typescript / PHP / Shell
- BackendでPHPが仕事で初期の頃使っていた言語で、ここ数年はGoが多い。会社とかではNode.jsが増えてきているが、まだまだ不勉強
- DevOpsという文脈ではShellやYAML多め、マイクロサービスやツール開発ではGo
- SaaS
- GCP / AWS / Azure
- SaaSとしてはAWSが入り口だけど、ここ数年はGCPがメイン
- GCP
- GKE(Kubernetes) / Run / Functions / DeploymentManager / PubSub / Tasks / GAE / SendGrid / Firebase
- GCPはGKEを中心として、徐々にServerlessや、AI周りが増えてきてる。ただしAI周りは自分が触ってるわけではないので、不勉強
- Zero Trust関連
- Google Workspace / Azure AD / Intune / JAMF
- Okta
- Zero Trsutにまとめたが、アカウント、端末などの意味合いで書いてます。端末の中央管理と配布楽しいですね。あと導入したい設定などを導入完了するまで自動なので楽で早い
- JAMF/Intuneを利用してエンドポイントのゼロタッチキッティング
- Googleが提唱するBeyondCorp取り入れたGoogle Workspace + GCPでのZerotrust概念導入
- IAPを利用してVPNが存在しない場合は、社内プロダクトを限りなくセキュアに社員限定に公開など
- Network
- Envoy / Cloudflare
- k8s内部のネットワーク関連で発生する課題に関してはEnvoyで吸収。PublicとGCP間でのネットワーク課題（例えば、CDNやWAFなど）は最近はCloudflareに任せることで、オリジンまで到達させない分離を検討しながら一部導入
- Secret Management
- Hashicorp Vault / GCP Secret Manager
- k8sだけではなくRunやFunctionsの導入も増え始めたあたりで、秘密情報の管理と配布方法を統一したくVaultを導入したが、Secret Managerが登場したタイミングで自前運用で発生するリスクやコストを軽減させるために、Secret Managerに統一するなど
- CI/CD
- CircleCI / GIthub Actions / Cloud Builder
- 最初は選択肢がCircleCIかTravisCIだったのでその時はCircleCIを選択。現在はCIはActionsで、CDはCloud Builderを選択。CI/CDを同じ物にすることで不要な権限がCI側にも渡る為権限をシンプルにする目的と、生産性向上の観点で分離。CIはActionsに統一することでGithubの中で完結することでネットワークコストを支払わなくて良くなる。CDはBuilderを利用することで権限がGCP内部に閉じる為IAMの管理も容易になり外部に権限流出するRisk低下とネットワークコスト低下につながる
- Test
- Autify / serverless-artillery / Mabl
- Data
- Airbyte, Census, DBT, Big Query, Apache Airflow, etc…