[TOP](https://www.notion.so/shinofara-1a690b35713b45bf8ea599bfa73fb7df?pvs=21) - index BIO いま興味を持っている領域 何をするひとでありたいか 直近のふりかえり 仕事の歴史 自分の技術的なスキルを一度洗い出してみます。（最後のUpdateは2021年くらい） 🗞 登場した用語まとめ 🏷️ 関連タグ ## BIO I’m Yuki Shinohara (篠原 祐貴) @shinofara I was born in 1987. I’m Software Engineer since 2009. I love Bouldering, [[写真|写真]], Gaming, Snowboarding, [[ダイビング|ダイビング]], Cooking and Programing. 87年1月大阪生まれ。2009年にY!新卒入社以降東京でWEBの世界で生きてます。 ボルダリング、 [[写真|写真]] 、ゲーム、プログラミング、[[ダイビング|ダイビング]] 、スノーボード、料理を生きがいにしてます。 大体のSNSは @shinofara でアカウント作ってます。 [Github](https://github.com/shinofara) / [Twitter /](https://twitter.com/shinofara) [Zenn /](https://zenn.dev/shinofara) [Wantedly /](https://www.wantedly.com/id/shinofara) [Linkedin /](https://www.linkedin.com/in/shinofara/) [Meety](https://meety.net/matches/YnvdBhcYxjZG) ## いま興味を持っている領域 1. 人・チーム・組織の生産性を高めること 1. NotionやSlackのような使いこなせる人にとって便利ではなく、それのお陰で生産性が2x,10xすることに繋がる未来があること 2. 元々100点を出す人が200点を出せることはもちろんだけど、0点（未経験）の人でも100点に近いことが出来るようになる事で、これまで経験者しかできなかった業務を未経験でも比較的簡単にできるようになっていくことが本当の意味でのDXだと思っているので 3. 更に言えばそもそも人がより創造的な事に時間を使えるようにしていく事も大切。そのためには単なる自動化はもちろんAIなどを用いて、オペレーションを以下に行わず結果にたどり着ける状態をつくるかも最近は大切。 2. セキュリティ 1. このテーマは一つ前に内包されている、もしくは関連しているけど切り出してます 2. 働き方の多様化、クラウド化、AI活用などにより、これまで以上にデータは色々な場所に存在する状態になっていきます。何も問題が起きなければ何も無いですが、個人情報流出などの問題が起きれば組織全体の生産性を低下させるルールが生まれたり、業務改善命令を受けて厳しいセキュリティになり、なにかするにも申請とか工数がかかる状態になる可能性があります。つまりセキュリティという成果が見えづらいから投資されない領域は、何かイベントが起きるだけ生産性を低下、さらに言えば企業価値、提供しているプロダクト価値を低下させるおそれがあります。 3. 昔からセキュリティレベル向上と生産性低下はセットに見られる事も多いと感じています。しかし現代の技術ではどちらも低下させることなく共存して高めていくことができると考えてます。更に言えばセキュリティを高める事は生産性だけではなく、プロダクトや組織の信頼性や価値など外部からの評価向上にもつながると思います 3. AI 1. AIをただ使う、AIで楽をするとかではなく、AIにより数十ステップあるオペレーションが、1ステップにできるとか、未経験者がとても高い価値を出せるとか、そういうレベルでの変化を起こすことができると思っています。英会話のSpeakとかは、人と話すことは恥ずかしいけど、AIとなら超下手な英語でも話せるなど、英語で話す際の障壁を取り除くことに繋がっているので、こういった心理的な壁、これまでの開発の手間の壁、人間の処理速度の壁など様々な壁をいい意味壊してくれると思っている ## 何をするひとでありたいか - 強くやっていきたい＆やる価値が高いと思っていること - Engineerというキャリアで培った経験や知識、考え方などを活かすこと - 組織の [[Terminology/課題|課題]] （過去・現在・未来 ）をエンジニアリングやそれに関連する考えで解くこと（≠プログラミング） - Product EngineeringというよりはProductivity EngineeringやxOpsやCorporate(Security)Engineeringなど、組織全体の生産性をエンジニアリングで高めてていくことが好きですね - プロダクトを作る人達、プロダクトを届けたり、ユーザと向き合ったりする人達、そもそも組織に居る全ての人が生み出す価値を高めていくことは、SaaSの導入はもちろんだけど、AI技術の活用や従来の技術のり活用などエンジニアリングで出来ることあるかなと - 企業活動の生産性を高めるという視点で、文化や制度に向き合うこと - 組織の情報整理やマネジメント - 必要性は高く感じるので、そこに課題がある場合やると思っていること - VPoE、EM、PdM、SRE、Product Operationなど、プロダクトに関わるマネジメント業務や、顧客に感知を感じ続けてもらうために必要な信頼性に向き合うこと。ある意味プロダクト開発の歯車を合わせに行く事かな ## 直近のふりかえり 2022年2月からSpirに関わり、5月に入社。詳しくは「[[日程調整ビジネスカレンダーのSpir（スピア）、CRO(Chief Reliability Officer)に篠原 祐貴が就任|日程調整ビジネスカレンダーのSpir（スピア）、CRO(Chief Reliability Officer)に篠原 祐貴が就任]] 」。 そして同年6月からCTOというタイトルに変更。CROって一般的にはRevenueを指すことが多いので、説明を毎回する苦労がありました。 向き合ってきた事を簡単に整理（注意：向き合ってきた＝僕一人の力では全く無いです） 1. 開発の生産性 1. 過去に「[[より早く高いアウトカムを実現するために、ソフトウェアの状態に向きあった結果モジュラモノリスと向き合い始めた|より早く高いアウトカムを実現するために、ソフトウェアの状態に向きあった結果モジュラモノリスと向き合い始めた]]」で書きましたが、成長の過程で増えてきた負債や、組織的な課題を解決する事はもちろんですが、生産性を高め続けていくというテーマでは、コードの品質や生産性、チームでドメインや業務に関する理解を高めて、開発の手戻りを減らしていくための、型の構築、型を用いることや、型のアップデートを継続的に行う運用などの体制・習慣化などの取り組みを進めるなどしてきました（注意：僕がではなく、組織で）。 2. DevOps, ブランチ戦略などなどの技術的な生産性も含む 2. プロダクトマネジメント 1. 会社としてはまだまだBe Agileとは言えない状態でもあり小さく検証ができていない状況でしたので、型にはめていく事はもちろんとして、「小さく検証する大切さ」を浸透させていく事を始めました。（注意1: こちらも当然の事ながら僕がではなく、組織でみんなで、注意2: 一度出来た文化や思考は簡単には変化しないので、徐々に徐々にです。これからもまだまだ） 3. セキュリティとクラウド 1. GCPの構造を誰も完全に把握できていないなどの状態でもあったので、後追いのIaC化とアーキテクチャの課題を調査。インフラリソースと何が依存しているのかなど、アーキテクチャ全体を可視化することなど。 4. 情報管理と透明性 1. Notionを利用しているが、データベースが複数あったり、 [[Terminology/情報|情報]] というよりメモに近い [[Terminology/ドキュメント|ドキュメント]] があったり、誰が何をしているか分からない状態だったりなど、知りたい事をしるという事が難しい状態でしたので、Notionエンジニア的に組織としてのNotion管理の型をつくり、まず同じ場所に書かれる状態を作り、徐々に整理に関して取り組みを進めていくなど。ただそこにデータがあるだけでは「情報の透明性」が高いとは言えないので、ただドキュメントを書くだけく、 情報を正しく残す、情報を正しい状態に更新する、情報にたどり着けるように整理する、日常的に必要な情報をしぼるなど、「情報の透明性」を高め続けるための運用が組織的に回るように向き合い始めるなど 5. 採用設計と等級設計 1. エンジニアの等級というより、全社的な等級を設計 2. マネジメントかスペシャリストで分かれる設計ではなく、究極どちらも高められる設計。今の時代はRoleなども多様化していることもあり、マネジメントとかスペシャリストとかの言葉で簡単に決める事はできない考え 6. データ 1. xOps、プロダクトでデータを利活用してより正しく判断行動できるように 2. GA、BQ、Lookerや、スプレッドシートなど何がどこにあるか分からない状態で、よくあのデータどこ？などのペインがそこにあった 3. BQをデータ ウェアハウスとして、全てのSaaSやデータの中心になるように設計 1. AirbyteでETL、CensusでReverseETL、プロダクトはAmplitude、カスタマーサクセスはHubspot 2. GithubのPRサイクルなども同様の仕組みでBQに蓄えLookerで可視化 4. データカタログとか、までは未着手。BQを中心にそれぞれのSaaSでそれぞれの課題を解決できる事とエンジニアがいなくても拡張できる状態が最初のゴール ## 仕事の歴史 #### History |Date|Name| |---|---| |August 1, 2023|[[合同会社None - 技術顧問業\|合同会社None - 技術顧問業]]| |May 1, 2022 → December 31, 2023|[[株式会社Spir - CTO - CRO\|株式会社Spir - CTO - CRO]]| |October 21, 2019|[[株式会社Reboost - 顧問 - アドバイザ\|株式会社Reboost - 顧問 - アドバイザ]]| |August 1, 2018|[[株式会社メンバーズキャリア - 顧問\|株式会社メンバーズキャリア - 顧問]]| |March 1, 2017 → April 30, 2022|[[マネーフォワードケッサイ株式会社 - CTO\|マネーフォワードケッサイ株式会社 - CTO]]| |December 1, 2016|[[株式会社マネーフォワード - SRE\|株式会社マネーフォワード - SRE]]| |December 1, 2014|[[株式会社メドピア - 技術部長 - SRE\|株式会社メドピア - 技術部長 - SRE]]| |February 1, 2012|[[ドキュメント/Work/History/株式会社Schoo - CTO\|株式会社Schoo - CTO]]| |March 31, 2009|[[ヤフー株式会社 - Engineer\|ヤフー株式会社 - Engineer]]| ## 自分の技術的なスキルを一度洗い出してみます。（最後の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周りは自分が触ってるわけではないので、不勉強 - [[Terminology/Zero Trust|Zero Trust]]関連 - Google Workspace / Azure AD / Intune / JAMF - Okta - Zero Trsutにまとめたが、アカウント、端末などの意味合いで書いてます。端末の中央管理と配布楽しいですね。あと導入したい設定などを導入完了するまで自動なので楽で早い - JAMF/Intuneを利用してエンドポイントのゼロタッチキッティング - Googleが提唱するBeyondCorp取り入れたGoogle Workspace + GCPでの[[Terminology/Zero Trust|Zero Trust]]概念導入 - IAPを利用してVPNが存在しない場合は、社内プロダクトを限りなくセキュアに社員限定に公開など - Network - Envoy / Cloudflare - k8s内部のネットワーク関連で発生する課題に関してはEnvoyで吸収。PublicとGCP間でのネットワーク課題（例えば、CDNやWAFなど）は最近はCloudflareに任せることで、オリジンまで到達させない分離を検討しながら一部導入 - Secret Management - Hashicorp Vault / GCP Secret Manager - k8sだけではなくRunやFunctionsの導入も増え始めたあたりで、秘密情報の管理と配布方法を統一したく[Vaultを導入した](https://tech.mfkessai.co.jp/2019/08/next_secret_management/)が、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](https://github.com/Nordstrom/serverless-artillery) / Mabl - Data - Airbyte, Census, DBT, Big Query, Apache Airflow, etc… ## 🗞 登場した用語まとめ #### 用語 |Name| |---| |[[Terminology/課題\|課題]]| |[[Terminology/Zero Trust\|Zero Trust]]| |[[Terminology/クラウドネイティブ\|クラウドネイティブ]]| |[[Terminology/セキュリティ\|セキュリティ]]| |[[Terminology/情報の透明性\|情報の透明性]]| |[[Terminology/DevOps\|DevOps]]| ## 🏷️ 関連タグ [TOP](https://www.notion.so/shinofara-1a690b35713b45bf8ea599bfa73fb7df?pvs=21)