こんにちは、バックエンドエンジニアの霞本です。
Sprocketでは、エンジニアの成長に投資するため、業務時間を使って定期的にカンファレンスに参加しています。私は、Developers Summit 2022 Summerに参加しました。参加したセッションをピックアップし、学習したことを書いていきます。
Developer Productivity 20年物語
Jenkinsの開発者である登壇者の川口耕介氏が、約20年間の経験をもとにDeveloper Productivityの進化の歴史を説明されていました。
昔も今も変わらない計算機の量の重要性
川口氏が勤めていたSun Microsystems社では会社に計算機が余っていたため、それを利用してクラスターを構成していたそうです。今後の展望としても、より一層のクラウド化が進む中、多数の計算機をどれだけ見えないところにて使っていくかに焦点が当たっていくというお話をされていました。
アジャイル開発が進んでいる日本
日本とフランス以外の国においては大規模に外部の会社へ開発を委ねることが少なく、そのため各企業にて独自に文化が発展していき、一般化されづらいということでした。日本においては外部の会社が大規模に開発を請け負うため知識が形式化され、結果として世界に比べて日本はアジャイル開発が発展しているということです。アジャイル開発をリードしているのは日本なので、日本から世界に発信していけるところがあるという見方をされていました。開発プロセスに投資してエンジニアを確保する必要があるという点において、Developer Happinessが重要となっているという点も興味深かったです。
Developer Happiness
Developer Happinessとは何かについて、セッションにて特に説明はなかったため、独自に調べました。確認したところ、Stack OverflowがDeveloper Happinessについて調査しています。この調査では、業界において離職率が高い一方で開発者の多くが積極的に新しい仕事を探していないという事実がデータから判明しました。それに伴い、重要なことが開発者自身の満足度であると述べられています。このことに基づき、HappinessとUnhappinessの差を生む要素が何かについて調査されていました。
「Developer Productivity 20年物語」における学び
Developer Productivityの歴史的な変遷とこれからの展望を学び、開発プロセスについての視野が広がりました。また、Sprocketでもスクラムによるアジャイル開発を実践しているので、Sprocketの開発プロセスについてさらに発信していきたいです。
入門 メトリクス
メトリクスとは何なのか、どのように扱うかを紹介するセッションでした。
メトリクスとは何か
メトリクスは何が起きているか、特定の時間間隔にて測定された統計値を表すものという説明がありました。ログ、トレースとあわせてオブザーバビリティの3本柱とされています。Sprocketの業務においても、プラットフォームを運用する際にメトリクスを重視しています。
メトリクスをどのように扱うか
カーディナリティ、保持期間と時間的解像度、リアルタイム性という3つの尺度にてメトリクス処理基盤の性能を測ることができるという説明がありました。また、メトリクスのみによって何故そうなったかといった状況を把握することは限界があり、ログやトレースなど他のデータをあわせて利用する必要があるという点も勉強になりました。
カーディナリティ
splunk様がカーディナリティについてのブログ記事を作られていました。数学の講義においては集合の要素の数がカーディナリティですが、モニタリングにおいては、メトリクスのユニークな値の数であると述べられています。たとえば、モニタリングしているアプリケーションに含まれるHTTPメソッドがGETとPOSTの2つしかないとき、カーディナリティは2です。アプリケーションが追加のメソッド(HEADなど)を含むようになると、カーディナリティは3となります。
「入門 メトリクス」における学び
オブザーバビリティとメトリクスについては、『Kubernetesで実践するクラウドネイティブDevOps』の15章にて事前に学習していました。今回のセッションを通じて、メトリクスについての概観と具体的な部分と合わせて理解を得られました。
チームの生産性を上げるファシリテーションとコーチングの活用法
チーム開発における課題の解決のために、ファシリテーションやコーチングをどのように使っていくかについてのセッションでした。
必要な情報をやり取りできていないという課題に取り組むケース
課題に取り組む際は、まずはコーチングにより課題を深堀りして確認することが重要というお話でした。また、「関係性ができていないときにチームにて話しても効果が出づらい」という言葉が印象に残っています。個別のヒアリングを行い、ファシリテーターが問題を解決するのではなく、話し合える関係性に再構築して、問題にはチームにて取り組むべきという点も勉強になりました。私が所属するチームでも定期的に1 on 1を実施しており、改めてチームにおける関係性構築の重要性を学びました。
タスクの担当者が決まらないという課題に取り組むケース
課題の例として、属人化や、「忙しいから」というチームの風潮、他の人が何をしているのか分からないという点が挙げられていました。これらの問題に対し、見える化やチーム全員が参加するミーティングの重要性を説明されていました。課題を認識してもらうためには、ヒアリング・コーチングが必要ということです。また、「やったこと」をミーティングで述べるのではなく、「分かったこと」を中心に話すことが重要ということでした。これを通じて、各メンバーの思考を整理し、見える化を行って共通認識を作る必要があるということです。
客観的かつ本質的なフィードバックを行う
客観的・本質的にフィードバックするためのポイントを説明されていました。事実を伝える・違和感を伝える・無意識な回避を見つけるといったように、「見える化」を行うためにいずれも重要なポイントを学ぶことができました。これらのポイントをチームにて共有し、チームが課題を抱えた際に、より客観的・本質的に課題を見える化できるようにしていきたいです。また、ファシリテーターが客観的・本質的なフィードバックをするには、安全な立場からでないと難しいと述べられていました。ファシリテーターが安全な立場から進行する必要があることをチームにて共有して、さらに客観的・本質的な議論を進められるようにしていきます。
自分たちで考え選び、できたことを認める
評価ではなく、実施できたことを認めることが重要と説明されていました。主体的に取り組んだことに対し、それ自体を認めることにより、たとえ失敗しても次も主体的に取り組めるシステムは確かに重要だと感じました。チームにおいても主体性が重視されていますが、セッションにて学んだことをふまえて、より安全かつ主体的に取り組めるようなシステムにしたいです。
「チームの生産性を上げるファシリテーションとコーチングの活用法」における学び
「関係性ができていないときにチームにて話しても効果が出づらい」という言葉は、繰り返しになりますが特に印象深かったです。問題を解決するのではなく、話し合える関係性に再構築することによりチームにて問題と向き合えるようにすることが重要だという点が、特に勉強になりました。また、客観的かつ本質的なフィードバックのためのポイントが明確になっており、こちらも学びになりました。
まとめ
今回はDevelopers Summit 2022 Summerに参加して特に勉強になったセッションをご紹介しました。開発プロセスやチームマネジメント、運用改善などについて、個人とチーム共々成長につながる知識を学ぶことができました。
Sprocketで働きませんか？
弊社ではカジュアル面談を実施しております。
ご興味を持たれましたら、こちらからご応募お待ちしております。
Discussion