2024年エンジニアリングで感じたこと
2024年でプラットフォームエンジニアリングを実践して、特に印象に残った以下を思い出して書く。
- チームが成長するには時間がかかる
- 振り返りと学習文化は大切
- 自動化を文化にする
チームが成長するには時間がかかる
自分の感覚であるが、チームで仕事をこなせるまでには、6ヶ月から1年は必要になると思っている。タックマンモデルのように、チームの状態フェーズには形成期/混乱期/統一期/機能期/散会期がある。各フェーズで様々な問題が生じながら、同時並行して仕事を進めていくことになる。チームのメンバーが同じ方針・方向で仕事を取り組めるようになる統一期までに、6ヶ月から1年は必要だと感じた。
振り返りと学習文化は大切
チームで実施する振り返りと学習文化は大切である。これは、業務時間内にチームメンバー全員で実施することがキーポイントである。
週1で振り返りを実施することで、チーム内で生じた問題に対して、迅速に解決策を取り入れることができる。
学習文化を醸成することで、チームから属人性を排除し、チームのナレッジとして蓄積することができる。例えば、該当する技術の勉強会やポストモーテムの共有会を実施することで、チームのナレッジが溜まりやすくなる。
自動化を文化にする
あらゆる作業の自動化についても文化にすることで、上記の取り組み時間に余裕が持てる。作業を自動化をすることで、2回目以降の作業時間の効率化とIaCによるナレッジの共有が可能になる。
2024年を振り返る - 仕事編
気がつけば、年の瀬に来ていたので、2024年に仕事で学んだことをツラツラと振り返ろう。
ハードスキル
プラットフォームエンジニアリング
プラットフォームエンジニアリングは、今年1年で盛り上がった領域の1つであると思っている。これは、未だ定義されているものがないが、開発者の生産性を高めるために、組織内で使用されるツール・インフラ群とその体制を整備する取り組みと捉えている。
GitHub Actions
CI/CDプラットフォームのリプレースとして、GitHub Actionsを導入した。GitHub Actionsは、GitHubリポジトリ内で自動化されたワークフローを作成・実行できるCI/CDツールである。開発者たちは、コードのビルド、テスト、デプロイなどのタスクを自動化できる。
KubeVirt
昨今VM製品の問題が出てきて、その流れでKubernetes上で仮想マシンを動かせるOSSがあると知った。KubeVirtは、Kubernetes上で仮想マシン（VM）を管理するためのOSSの拡張機能である。これにより、コンテナと仮想マシンを統一的に管理でき、ハイブリッドなアプリケーション環境を構築可能になります。Kubernetesのリソース管理機能を活用し、VMのライフサイクルを簡素化できる。
ソフトスキル
デザイン思考
デザイン思考とは、人間に観点を置き、イノベーションを起こすための考え方である。イノベーションの内容は、技術的な革新のイメージが強いが、日常業務の改善も含まれている。利用者である開発者を中心に、プラットフォームを評価してもらい改善していくことで、より使いやすいプラットフォームに近づくことができると思っている。
オッカムの剃刀
オッカムの剃刀とは、「ある事柄を説明するためには、必要以上に多くを仮定するべきでない」とする指針である。ステークホルダーたちと折衝する中で、複雑なシステム全体を説明するのでなく、議論が必要な要素のみを取り出す。そうすることで、会議中は、不要な議論を避け、重要な要素のみを議論に集中することができる。
インナーソースを理解してみる
はじめに
本プログは、筆者なりにインナーソース(InnerSource)を理解して、まとめたものになります。インナーソースを知ったばかりで、理解が異なる箇所もあるので、ご容赦ください。
インナーソースを知ろうと思ったきっかけ
インナーソース活動を始めて、車輪の再発明を防ぐことができないかと思って、調べ始めた。筆者はプラットフォームを提供する側だが、開発者にプラットフォームの普及や学習の提供などしてきた。新しい機能や機能改善したパイプラインのソースコードを周知することが一番効率悪く感じ、なんとか改善できないかと調べていた時に、インナーソースの存在を知った。
インナーソース
インナーソースとは
InnerSource Commonsによると、
InnerSourceは、企業内のソフトウェア開発にオープンソースの実践と原則を適用したものです [1]
と定義している。つまり、世の中にあふれているOSSの活動で得た実践方法や原則を一般的な企業の組織内に適用してセルフサービス化を図ろうとするベストプラクティスと解釈している。
[1] はじめに
インナーソースの成果
インナーソースによる成果は、開発者体験と生産性の向上と思われる。
インナーソースの利点として、以下が挙げられている。
- 組織横断的なコードの再利用が飛躍的に進みます。各チームのプログラマーは、他のチームによって開発されたモジュールのコードとアーキテクチャを理解し、コードをコントリビュートできます。
- このようなチーム間のコラボレーションが、比較的摩擦の少ないものになります。受け取ったチームがコントリビュートされたコードを書き直すことはほとんどなくなり、上層部における議論も必要なくなります。
- プログラマーはユニットテスト、コードカバレッジ、継続的インテグレーションを使い、開発の初期段階でバグを取り除くことを学ぶことができるため、開発はより速くなります。チームメンバー間で交わされるコメントのやり取りには時間がかかりますが、新しいプログラマーがシステムについて早く学ぶことができるようになるため、それ以上の効果があります。
- プログラマーは自分のコードをより良くドキュメント化することを学ぶようになり、それは公式なドキュメント(コード内のコメントやドキュメント)や、非公式なドキュメント(ディスカッションリスト) に対しても効果があります。ドキュメントはプロジェクトの履歴を提供して外部の人間が理解する助けとなるため、より多くの人がプロジェクトへコントリビュートできるようになります。 [2]
[2] チーム間コラボレーションへの強力なアプローチ - InnerSource Commons 日本語コンテンツ
インナーソースへの取り組み
インナーソースへの取り組むについて、InnerSource Coomonsより日本語のパターンブックが公開されているので、以下を参照してください。
patterns.innersourcecommons.org
最後に
パターンブックで気になった点を1つだけ感想を述べたい。「正式なコミュニティリーダ」[3]について、いくつかの条件を達成した優秀なリーダを選択する必要がある。そのうちの経営陣と開発者に強いネットワークを確立できることは、なかなか厳しい条件になるのではないかと思う。最初は小さく初めて、インナーソースの効果が出始めたときに、上層部に社内活動としてアピールして認知してもらうなど一工夫が必要だなと思った。
プラットフォーム・エンジニアリングの概要を自分なりにまとめてみた
はじめに
近年のトレンドであるプラットフォーム・エンジニアリングが出現したため、自分なりの解釈を入れながら、概要をまとめてみました。本プログに記載している内容は、筆者の主観が入っているため、必ず正しいものではございません。
プラットフォームエンジニアリング
では、プラットフォーム・エンジニアリングとは何か。この章で、概要と自分なりの解釈を入れて説明します。
概要
ガートナーによれば、
プラットフォーム・エンジニアリングは、インフラストラクチャ・オペレーションの自動化とセルフサービス機能により、開発者エクスペリエンスと生産性を向上させます。開発者エクスペリエンスを最適化し、プロダクト・チームによる顧客価値のデリバリを加速させることが期待できるため、大きく注目されています。[1]
とのことである。
[1] プラットフォーム・エンジニアリングとは何か？ | ガートナー
成果
プラットフォーム・エンジニアリングの成果は、「 開発者エクスペリエンスと生産性の向上」である。ただ、これだと曖昧な定義だと思うので、CNCFのホワイトペーパーから紐解いてみたい。CNCFでは以下の記載がある。
製品チームの認知的負荷を軽減し、それによって製品の開発と提供を加速します。[2]
[2] CNCF Platforms White Paper | CNCF TAG App Delivery
近年、技術の発展により、プラットフォームとしてコンテナやKubernetesの普及であったり、TektonやArgoCDなどCI/CDツールの進化など、アプリケーション開発者は違う領域の技術のキャッチアップが必要になってきた。日々、プロダクトの価値をエンドユーザに届けるために、開発者はプロダクト開発する中、これらのキャッチアップを行い、実際にプラットフォームとして使い、価値をデリバリーしている。
このような状況下で、プロダクト開発者は本当にプロダクトの価値を届けるために、それらの技術をキャッチアップするために多くの時間を費やすことができるのだろうか。おそらく多くの場合は、キャッチアップに労力がかかっている状況だと思う。そのため、プラットフォーム・エンジニアリングにより、プロダクト開発者の認知負荷を下げることで、プロダクトの開発と提供を加速させることが成果になるのではないだろうか。
手段
では、プロダクト開発者の認知負荷を削減する手段は何があるだろうか。現在、認知され始めた手段としては以下である。
- Platform as Product
- プロダクトマネジメント
- セルフサービス化
- 内部開発者プラットフォーム (IDP: Internal Developer Portal)
戦略として、プラットフォームをプロダクトとみなし、それをプロダクト開発者に提供するPlatform as Productがあるようだ。戦略をとる手段として、従来のプロダクトマネジメントやセルフサービス化、多くのベンダーが提唱し出したIDPが含まれている。おそらく数ヶ月経てば、新たな手段が出現するのではないだろうか。
最後に
多くのIT組織がプラットフォーム・エンジニアリングをキャッチアップしている最中だと思う。ただ、私は特定の技術を使ったプラットフォームの提供やIDPのみ取り組むことだけは避けたい。プラットフォーム・エンジニアリングを始める組織が、プロダクトマネジメントの組織文化や組織体制などを検討し、実践していくことが大切なのではないかと思っている。
2023 Q4を振り返る
はじめに
四半期ごとに振り返りを書こうと思ったが、Q3の振り返り出来ていなかった。今回はQ4の振り返りを細々と書いていきます。
アジェンダ
- Q4であったこと
- 仕事
- 勉強
- プライベート
- まとめ
Q4であったこと
仕事
今期では、人生初となるハンズオン会を開催した。継続的インテグレーション(CI: Continuous Integration)のプラクティスが実践できることを目的としたものを作り上げた。構成としては、
| 項目 | 技術名 |
|---|---|
| プログラミング言語 | Jave SE |
| フレームワーク | Spring Boot |
| CIツール | Jenkins |
| 環境 | k8s |
| その他 | SonarQube |
といったものです。
良かった点として、ペルソナで受講者を限定したこととハンズオン資料の章の構成をピラミッド構成で念入りに練ったことである。悪かった点は、Webアプリのプログラミングを書くのが5年ぶりだったことである。Javaの基本構文や初めてのSpring Bootだったり、アノテーションってなんだっけとか思いながら、サンプルアプリの作成に時間を要した。初めてのことにトライすることに負荷がかかったが、成し遂げた後、達成感があって面白かった。
事前にハンズオンをどのような受講者を対象に、どうやって構成を立てたかは、別の記事で書いてみようと思ってる。
勉強
今期では、主にプロダクトマネジメント系とソフトスキルを勉強していました。読んだ本は以下です。
- プロダクトマネジメント系
- プロダクトマネージャーの仕事
- プロダクトマネジメントのすべて
- 正しいものを正しくつくる
- ソフトスキル
- 仕事を教えることになったら読む本
- 入門 考える技術・書く技術
- 技術
- エンジニアのためのGitの教科書
- Podman イン・アクション
プロダクトマネジメント系は、プラットフォームエンジニアリング(PF: Platform Engineering)に興味が出てきたため、学び始めた。PFは、まだ明確な定義がされていないが今年よく聞くワードとなった。これからCI/CDのプラットフォームの提供者として、開発者体験が良いプロダクトを届けいきたい。そのため、プロダクトマネジメント系の勉強を始めました。
プライベート
10月
友達夫婦と千葉の九十九里浜近くで、一軒家を借りてBBQした。台風が来ていて、天候が最悪だったけど、屋根付きでなんとか肉が焼けた。
11月
11月は野球とソフトボールをしていた。野球では、万年ビリのチームだったが、まともに投手ができるように今年からトレーニングを開始していた。そのため、7勝することができ、4位まで上り詰めた。
ソフトボールは、最終戦サヨナラホームランを決めて、気持ちよくシーズンを終われた。
12月
初めての日向坂のライブに参加してきました。小坂菜緒の覇気が想像以上にすごかった。また次のライブも行ってみたい!!
2023/Q2を振り返る
はじめに
2023年も早いこと、Q2が終わり、後半年で今年が終わる時期になってきました。なので、Q2であった仕事とプライベートを振り返ってみたい。
アジェンダ
- 仕事
- プライベート
Q2であったこと
仕事
Q2では、仮説検証プロダクトのアーキテクトを中心とした役割を担っていた。初めての役割だったので、設計が遅かったり、メンバーには色々と迷惑をかけたかもしれない。タスクとして、以下のようなことを行なっていた。
- 仮説検証プロダクトの設計書の作成
- プロダクトに使う主要技術の勉強
- 仮説と成果の報告資料作成
- ステークホルダーとの調整
これまでの会社とは違い、アーキテクトとしての設計書作成や報告資料作成が求められ、多くのアドバイスを頂いた。作成しては、レビューしてもらい、さらにアドバイスを貰い、品質の粘度を上げるようなPDCAサイクルを回せていたのがよい環境だった(ただ、指摘され、作り直しを喰らっていたというのは内緒で....)。特に、アドバイスして意識していたことが
- 凡例をつける
- ピラミッド構成から練り直す
になるかなと思っています。
Design itより"良いデザインには凡例がある"とあり、システム図や概念図がある箇所にはとことん作り配置した。
ピラミッド構成に関しては、スライドから作り始めず、構成を練るところから始めて、少しでも違和感があれば練り直す。そして最後にスライド作成を始めるフローに変えてみた。習得しきれないところもあるので、今後もこの点は意識して改善を図りたいと思っている。ちなみに昔からスライドがよくわからないという指摘(う!!...大学院時代の古傷が...)をよく受けていたのはいい思い出。
勉強
Q2での勉強としては、GCP ACEの資格を取ったり、ソフトスキルを中心に勉強をしていた。
ハードスキル
ソフトスキル
- Design It! ―プログラマーのためのアーキテクティング入門
- 入門 考える技術・書く技術――日本人のロジカルシンキング実践法
- プロダクトマネジメントのすべて
- 正しいものを正しくつくる プロダクトをつくるとはどういうことなのか、あるいはアジャイルのその先について
プライベート
4月
草野球シーズンも始まり、去年から肩の調子が戻ってきたので、筋トレの成果を発揮する時がきた。1試合目は、完投7奪三振で試合に負けたが、完投できるまで体の調子が戻ったと実感できた。2試合目は、完投14奪三振で今シーズン初勝利を飾った。ちなみだが、我がチームは万年リーグ最下位の1勝できるかどうかのチームだったので、今年は2,3勝目指して体をスケールアップしていきたい。
5月
GWの後半で、大学の後輩とともに4泊5日で東北周辺旅行に行った。
動けるうちに、全NPBのホーム球場観戦制覇をしたいから、近々行っていない球場にも観戦予定するつもりです。
6月
一昨年引っ越してから、寝る部屋にエアコンがなかったので、やっとエアコンを買う決意をした。隠蔽菅の太さが施工基準ではないか何かでビックカメラやヨドバシで対応ができなかったので、管理会社紹介の施工業者に依頼するしかなかった。依頼から設置まで１ヶ月ぐらいかかったので、少し面倒だったな。
GCP Associate Cloud Engineer 合格しました
タイトル通りでGCP Associate Cloud Engineerを合格しました。初パブリッククラウドの資格を取得しました。
受けようと思った背景
いつものように、仕事でGCPを扱うことになったからである。これまではパブリッククラウド時代に、GCP含めAWS, Azureなど触っていないとと心のどこかで思っていたが、逃げていました。この度、GCPの知識がないと仕事にならないため、基本知識が取得できるようAssociate Cloud Engineerの資格を受けました。
受験前のスペック
著者のスペックは以下である。
勉強時間・方法
今回行った勉強方法と費やした勉強時間は以下である。
勉強時間
GWから2週間で、毎日30分~2時間程度なので、合計約20時間。
勉強方法
勉強方法は以下二つの教材を使って、重点的に周回した。
1. 図解即戦力 Google Cloudのしくみと技術がこれ1冊でしっかりわかる教科書
1周目は理解しているところは、スキップして、知らないところだけをサラッと読んだ。2周目は、模擬試験をやったあとに復習として、重点的に読み込みました。3周目は試験受ける前に全体的にサラッと読み込んだ。
2. GCP：Google Cloud Associate Cloud Engineer模擬試験問題集（4回分200問）
模擬試験を受けて、不正解ばかりだった。わからない専門用語だけを押さえて、メモに特徴をまとめていた。最終的には、95%の得点率になるところまで行って、4周しました。
https://www.udemy.com/course/gcpgoogle-cloud4200-y/
結果
タイトルにもありますが、無事合格しました。知識つけることに注力してたので、Courseraで無料のハンズオンを使って、実体を理解していきたいと思ってます。それが終われば、 Professional Cloud DevOps Engineerをチャレンジしていこうかな。
