インナーソースを理解してみる
はじめに
本プログは、筆者なりにインナーソース(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をチャレンジしていこうかな。
「技術書」の読書術を読んだ個人的感想
なぜこの本を読もうと思ったか
3-4年前から気になったことは、本を買って読書するようになっていた。しかし、ここ最近物覚えも悪くなってきたり、集中力がなくなったりして、本を読むことについてもやもやしてきた。ある日、ちらっとブログを眺めていると、「技術書」の読書術という「今の私の欲求にピッタリな本があるじゃないか！」ということで即購入したのが経緯です。 本記事では、これから3つのことを取り組んでみようと思うことだけ書いてます。
「技術書」の読書術 達人が教える選び方・読み方・情報発信&共有のコツとテクニック | IPUSIRON, 増井 敏克 |本 | 通販 | Amazon
取り組むこと
1. 時間制限読書法
一定の制限時間を決めて、一気に一つの本を読破する読書法。筆者は、本を読む際に、全部の内容に目を通すと気がすまない(もったいない)という気持ちで読んでしまう癖がある。読んだとしても、仕事で使わない限り１週間以内に忘れてしまうので、時間がもったいないと思っていた。この読書法を実践して、今必要な内容だけを取捨選択できるようにしたい。
2. マーキング読書法
マークをしながら、本を読む読書法。今まで、本を汚すともったいないとか、売る時に値段が下がるのではと思っていた。結局、技術本などはほとんど売らずにいたり、何度も読み返して、本が折れてたりする。なおさらマーキング読書法をつかって、重要なポイントをすぐ読み返せるようにしていきたい。
3.Notionでの読書記録と読書メモ
読書記録をつけて、モチベーションを高めていく方法の一つ。私の場合は、読書記録をつけてなかったので、Notionを使って、記録を残し、簡単なメモを本ブログに書いてみたいと思う。
終わりに
今回は、読書術に関わる3つのことをメモレベルでまとめました。本の内容では、他に英語の技術本についてや本の探し方、アウトプットなど多くの内容を取り扱っているので、ぜひ読書術に困りだした方は一読してみることをおすすめします。
2022年、締めくくり
2022年、締めくくり
2022年なぜか、短く感じた1年になったなとふつふつと感じた。年齢のせいか、仕事が忙しかったのか。
TL;DR
- 転職して、残業時間がなくなった
- DevOpsを基礎から学び始めた。
- Containerの基礎がちょっくり理解できるようになった
- EXIN DevOps Foundation/OSベンダー資格3つ合格した
- 英語9か月頑張ったが、やはりスピーキングが伸びない
- あ、高尿酸血症治した
- ゴルフを始めた(スコア120切れず...)
- 草野球/ソフトボール、ほぼ全試合いった
- 30歳になった
- 彼女できなかった
ここからは長いかもしれないので、適当に読んでくださいmm
仕事編
転職して早1年、現リーダーの協力もあり、残業が圧倒的に少なくなった。リーダーあざす(見てるかもしれないのでw)。仕事面では、DevOpsのCI/CDの領域を主に取り扱ってきた。Helmだったり、Ansibleだったり、Jenkinsのおじちゃんだったり色々活用できてよかった。k3sを使っていることもあり、containerdの基礎を理解することもあったり、面白い一年になった気がする。あとは、Infrastructure as Code (IaC)を取り入れる上で、すべてのインフラをコードで状態がわかるようにするというのは理解できるが、現実的にどこまでコード化できるのかなど葛藤もあったな。実装しているものも成熟度的には「管理された」状態が終わり、「最適化された」状態のステージで来年頑張りたいと思う。
勉強編
勉強...勉強...園児ニア界隈には、エンジニアはプライベートでも勉強すべき論争があるが、自分はこの圧に負け、勉強しなきゃ圧力に弱い。でも。今年は社会人歴で一番勉強する時間が短かったかもしれない。とはいえ、仕事に必要なDevOpsだったり、技術スキルもいい塩梅で勉強した気がする。あれこれ、多方面に手を出さず、必要最低限の領域に対して、勉強するスキル？考えた方も大切だなと思った。これは過去これまで勉強したり、経験で得たものが日常的に理解できるようになったという理由もあるかもしれない。
あとは英語...君はもうあれだよね...癖強いよね...。スピーキング能力に関してはやり続けるしかないので、留学しとけばなという後悔もあるが、後悔しても仕方ないので、継続的スピーキング改善していこうと心のすみっちょに置いておこう。
プライベート
今年からゴルフを始めるようになり、運動不足気味になっていたので、習慣的に練習していい運動不足解消になったと思う。
草野球では、ようやく肩が治り、6回9失点10奪三振3四球ぐらいでひどい結果になった。社会人以降まともに投げれた時がなかったが、ようやくいい整体と出会えて、肩回りの硬さをほぐすアプローチが取れたのが良かった。
ソフトボールでは、7本ホームラン打てた。来年はチームでホームラン数、打率1位になれるよう思考錯誤していきたいな。
終わり
今年で30歳になり、体力の劣ろえが非常に気になり始めたが、来年も頑張っていこう!! (夜型のはずが、眠すぎる)。年末休暇は「LeanとDevOpsの科学」と「継続デリバリーのソフトウェア工学」読破すっぞ。
