00:12
はい、みなさんこんにちは。kkeethことくわはらです。本日もやっていきましょう。
kkeethのエンジニア雑談チャンネル。この番組では、ウェブ業界やエンジニアリング、いろんな技術についての情報を、雑談形式で発信していきたいと思います。
えーと、今日はですけども、昨晩ですね、ファインディさん、会社さんの、まあとある、キックオフミーティングに呼ばれまして、
ミーティングという名の、まあ単なる交流会なんですけど、交流会に呼ばれて飲みつつ、話をしつつ、みたいな。
まあ最近のファインディさんの行いとしては、とにかくイベントをたくさん行っているっていうところがすごい強くて、
まあやっぱ認知度拡大がすごいしたいっていうのと、エージェント的なお仕事をされているので、そこを強めていきたい。
単に、うちはいろんな採用をやってますよっていうお話ではなくて、いろんなイベントをやったり、交流をする中で、質の高いエンジニアとかレベルの高いエンジニアさんを
マッチングさせることができるっていうのを、多分強めにしようとしているのかなって、僕は個人的に思っていて、まあいろんなイベントをやってると思いますし、会社自体の認知度拡大と、
ファインディさん自身も採用されてますので、そこの辺も強めたいんだろうなっていうところはありますけど。
昨日は、その中で彼らが企画しているものが一つあって、まあまだ公表していけない、まあしてもいいかもしれないですけど、まあまだ公表はしないので、
それを待とうと思いますけど、新しく何かやろうとしていることのキックオフに僕も参加しつつ、まあそのやろうとしていることに自分自身も参戦をして、
一緒に頑張っていきたいなっていうところがあるので、まあそういう話をしてました。
で、まあその中で文脈として、まあやっぱファインディさんが最近開発生産性のお話をすごくされてますし、
まあそういうツールを作ってましたよね。ファインディチームプラスっていうサービスがあるので、まあそれを弊社も使っておりまして、ユーザー界に近いようなお話に、
昨日のイベントはなったんですけど。
ちなみにもともとファインディチームプラスっていうサービスの名前は、ファインディチームズっていう名前だったんですよね。
で、途中で、そもそもマイクロソフトチームズとやっぱり名前が被ってしまうし、まあ省略するとチームズって言っちゃうんですけど、
そこが被ってしまうからやっぱり名前よろしくないねって言ったので、途中でチームプラスっていう名前に変えたらしいです。
で、実態としては、いわゆるGitHubをベースとした、まあGitHub以外もありますね、GitLabもそうですし、BitBucketも確か連携した気がしますけど、
まあ要はソースコードのコミットのタイムスタンプをベースとして、開発の生産性を数値化、もしくは可視化をしていこうというようなサービスになりますね。
それはもちろんチームも出向きますし、個々人のものも。
でもデイリーからウィークリー、特定の期間をもってその生産性っていうのを数字を可視化しましょうみたいなところもあって、
それだけなら、まあぶっちゃけGitHub API叩いてやろうと思えばできなくはないですけど、
いざ実際やってみるとものすごい大変なので、それをサービス化してくれるのはすごくありがたい。
でまた、チーム単位でどんだけ頑張ったら、どの辺の数字が出たらうちらは素晴らしいものなのか、それともこの辺の数字だとまだまだなのかみたいな、
03:05
そういう指標もサービスの中にある程度含めてくれていますので、
例えばリードタイム、開発サイクルタイム、サイクルのリードタイムとして、
ファーストコミットから特定ブランチへのマージ行われたそのリードタイムの時間が、
例えば20時間とかだとすると、かなり良い方だよみたいな結果を出してくれるので、
まあそこはすごくありがたいですし、個々人のタイムスタンプからコミットの時間だったり、コミットの量だったり、
あとはそのコミットの流度とかですかね、みたいなところまでしっかり可視化をしてこと細かく分析することもできたりするので、
割とオススメではありますけどね。
ハインディのサービスの紹介はここまでにして、本題の開発の生産性ってなんだろうねってところなんですけど、
そういうツールを使って、要はエンジニアの活動って結局開発の仕事が多いと思うので、
開発のプロセスにおける生産性っていうお話ですけど、
いろんな定義があるし、会社さんごとに定義がたくさんあると思うんですけど、
我々みたいなクライアントワーク、住宅企業でいくとやはりいかに仕事をしないかってところが大事なので、
先ほど言った通りに、うちの会社ではまずは特定のブランチへのマージまでのリードタイムっていうのが僕らは生産性と一旦指標を決めて、
数値を見ていったってことがありますね。
いろんなチームに入れたり、いろんな人個人に入れてみたりしてやってました。
そうやってやっていくとですね、意外とうちの会社はそもそもベースとしてたくさんのメンバーの生産性は高かったんですよね。
その数字だけを言うと。
高かったんですけど、プロジェクトの進行が遅かったり、そもそもリソースかかりすぎだろっていうようなビジネスサイドの視点だったりご意見がある。
それは納期に対してここまでのチケットが消化されたりストーリーポイントがちゃんと積み上がってますっていうのがあって、
それと照らし合わせると、エンジニアの生産性は高いと言うけど、結局ビジネスに貢献しないって意味では生産性が効くんじゃないのっていう話があって、
それは開発の生産性ではないでしょみたいな話もある。
目的としてはビジネスがある中で開発というフェーズを僕らがやってるって意味では一概に無視はできないよね。
なかなか大変ではあるんですけど。
ちなみにうちの会社とか僕の所属していたチーム何個か見たんですけど、
ボトルネックがどこにあるかっていうのが意外とそういうサービスを使うとパッと見えたりしてて、
びっくりしたのはプロリクエストを出すじゃないですか。
アプローブされたんですけど、マージされるまでの時間が結構かかったりしてて、
それはルールとしてプロリクを出した本人がマージをするっていうところがルールだったチームがいくつかあったんですね。
そういうチームはメンバーがアプローブしましたって言って、スラックにも通知が流れるんですけど、
本人がそれを見るのがまた次のリパブ見るとき、もしくは本人が次のプロリクを出すときまで意外と放置をされていて、
リードタイムとしては長くなった。
なのでデプロイする頻度も下がりますよね。
マージされたら基本的にCICDとかがキックされて、マージされたりデプロイするまでの自動化はもちろんしてたりするんですけど、
それが遅かった理由はそこにあると。
06:01
それを本人ではなくてもプロリクした人がそのままマージすればいいじゃんみたいなルールに変えてみたりすると一気に数字が変わったとかいう事例もありまして、
これは一つの事例ですけどね。
ただ意外と可視化してみないとわからないところがたくさんあるので、
こういうサービスを使っていろんなものをまずは可視化して、
本当に早いのかとか、実はこの辺ボトルネックで自分たちが思ってたよりも遅いんだよっていうのは往々にあったりします。
面白いのは自分たちは割と開発効率よくできてるとか早くできていると思ってる人たち、
もしくはチームの人ほど意外とリードタイムという数字で見ると遅かったりするのがあってですね。
これがなかなか面白いです。
やっぱり感覚と実態は違うよっていうので、やっぱり感覚ではなくてしっかり計測をしましょうという話はあると思うんですけど。
サイクル自体が早ければ生産性は高いのかというと、
開発だけのお話で文脈で言えばもちろん高いんでしょうね。
生産性という言葉そのものはどこに寄与するかは、
目的となるビジネスとかプロダクト開発とか、やりたい実現したいもののためのフェーズであって、
それに対して寄与できてないのであれば生産性なんて、
正直言うとただの数字にしかならないというお話ですね。
最近のエンジニアはやはり皆さん優秀で、
少なくエンジニアリングをやってる人であれば、
数字の改善自体は普通にできるんですよね。
その数字に対して何の意味をつけるとか、どう運用するかによってその数字自体が生きる。
その指標とか運用ルールみたいなところを決めてないんであれば、
生産性を測ることにあんまり意味はない。
そもそもなんで取るのっていう話をしっかり各チームでやっていかなきゃいけない。
昨日のユーザーコミュニティのお話の中で分かったのは、
皆さん数字は割と取れてるし、測れている。
もしくは改善もしてたり、定期的に数字自体の見直しをしてるっていうのは皆さんもやってますけど、
なかなかそれが売り上げとかビジネスに直結できなくてそこが課題だなみたいなところがあって、
どういう機能があったら生産性っていうところに寄与するのかって話を
割としてて面白かったんですね。
何社かはファインデチームプラスの中で、
近代の時間もそこに含めて、
もう少し地座を上げて生産性を見ていこうみたいな話をしてて、
本当にやるんであれば確かに、
ちゃんと稼働時間とどのプロダクトに対してどれだけの時間を使って、
その時間の中でどれだけのバリを出したかっていうのをファインデチームプラスの、
Gitの実績を持ってやっているっていう話があって、
それは結構面白かったですね。
どうやって近代時間とかを上手いこと加味しているのか難しそうではありますけど、
最近アドラシアンの地裏との連携ができるようになったので、
よりストーリーポイントと実際の稼働率とみたいなところが、
連携できるようになったのがすごく大きいので、
その辺を上手いこと使ってやったら少しはいけるのかな。
とにかく早く開発ができれば、
でも生産性が高いのかっていうのはなかなか難しいなと思いましたね。
早く効率よくできても、
09:01
フォーキーズの指標の3つ目か4つ目にありましたけど、
障害率とそれの障害のリカバリーのスピードですよねっていうのがある。
障害出さないんであれば、スピード早ければそれは最高ではあるんですけど、
ただスピードが速くて障害もたくさん出してるっていうのであれば、
トータルで見ると生産性は別に高くはないよねっていう話があるんで、
そこのバランスは難しいですけど、
検知まずできてないなっていう話が多分あるんです。
変更とか障害率の話でいくと、
障害のちゃんと検知とすぐにリカバリーする対応する体制ができてるか、
それを仕組み化できてるかっていうのが割とボトルネックになるんじゃないかな。
まずはその仕組み化から入るというのがスタートかな、
みたいなところをいろいろ喋っていきましたけど、
結局は意味付けは後でちゃんと人化していかなきゃいけない。
最初から方針としてこういうものを見る、そのための数字が欲しいっていうので、
デベロッパーのコミュニティのタイムスタンプから
どれだけのスピードでやれてるかっていうのが大事になっているので、
何もやってない会社さんであればまずはそもそも計測をして、
ちゃんと数値化をして、それを見てどう思うかっていうのからスタートで良い。
やらんことには何も議論はできないので、
材料として明確な事実としての数字を見るのが大事かな。
みたいなことを昨日はバーッとお話ししながら、
とはいえ、生産性ってやっぱりそもそも抽象度が高い言葉で、
各社さんいろんな仕組みだったり、知見を持っていますけど、
その知見がなかなか共有される場が少ないし、
いざ指標を取ったり数字を測ったはいいんですけど、
そこからどう社内に浸透させるかとか、
本当はみんなが意識をして、
同じように生産性を高く開発をするっていう風な
意識のもとをやっていればいいんですけど、
数字を出すと今度は数字のハックをしようとするメンバーはやっぱり絶対出てくるんですよ。
数字のハックはもちろんできちゃうんですよね。
単に数字だけを上げようと思えばいくらでもできるんですけど、
それがちゃんと自分のチームのプロダクトの成長とか、
会社のビジネスに直結するとか、
例えばそのOKRみたいなものを定めている会社であれば、
自分の年間目標に対してどれだけ今貢献できてますかっていうのは、
ある程度定量的に見るっていう風に使うとか、
何かしらの意味付けをしていくことが今後は課題になってくると思いますので、
いろんな会社さんの仕組みだったり、
アクション、知見っていうのを共有する場がやっぱり欲しいよなっていうのが
昨日の交流会でのお話でした。
今回のデブサミの中でもすごく面白い話が一個あって、
あれは僕だと参加できなかったのですげー悔しかったんですけど、
スライド見ればそのまんまだよなっていう感じはあるんですけどね。
めっちゃ勉強になったので、
そういうでかいイベント以外でも気軽にお話をしたりとか、
悩み相談する場が欲しいなっていうところで、
そこをファインディーさんがやってくれたらなっていうのを
昨日お話ししながらちょっと思ってました。
昨日の話の中でインフルエンジニアの方が参加されてましたけど、
その方が言ってたのは、
スキーマーのレビューとかはAIにガンと投げって
してもらってるみたいなことを言ってましたね。
レイヤーが低いほど変更とか変化することって割と少なかったりする。
こういうケースにあいてはこういうのをほぼ正解とするみたいな。
多少の正解は割と定量化しやすい気がしているので、
12:02
僕も実際いろんなCICDのYAMLを書くときは
まず一回AIに書かせて、それを手直しをすることがほとんどに。
自分もそうなってしまいましたし、
データベースの正規化とかスキーマーも
テープル定義も割とAIに聞くほうが早かったりはする。
そこの辺から少しずつ改善ができたらいいのかなって気はしますね。
ただ、AIに全振りして、
脳死でそれをフル力に出すのはさすがに
おいおいって話はもちろんあると思うので。
うまいことサポートとして活用していくっていうのが大事だと思います。
AIを使ったところでどれだけ改善をしたかっていうのを
定量的に見ていくのが大事だよなっていうのはすごくありますので。
そういうふうな知見もいろんなところで
回っていただければ嬉しいなって感じですね。
今回はこんなところで終わっていきたいと思います。
いつも聞いてくださり本当にありがとうございます。
ではまた次回の主力でお会いしましょう。
バイバイ。
