この記事はうるるAdvent Calendar 2022の25日目の記事です。
24日目の記事は@DoueKazunaによる〜イブに彼女がいないあなたにおくる〜 来年こそは！彼女を作るためのプロダクトマネジメントでした。
成長著しくて頼もしい限りです。
はじめに
株式会社うるるの @hokutohagi です。
NJSS というサービスにてデータ基盤の構築やスクレイパーの開発に携わっています。
今年1年間を振り返ると、「可視化」というキーワードで活動していたことが多かったのでそれについて記事を書いてみました。
可視化に取り組みを始めた経緯
最初は深く考えずに勢いで取り組みを始めようと思い立ちました。
2022年5月当時、育休から復帰をし、どんな役回りでミッションを持つかについては先んじて会話はしていたのですが、具体的な目標の置き方をどうしようかと考えていたタイミングでした。
会社全体としての方向性としても「データドリブン」というような言葉が用いられたり、事業部の中でも「ユーザー目線を持てるようになるためのデータ活用」という文脈が語られるようになっていました。
このムーブメントにあやかってしまおうと思い、「データ活用」の文脈範囲を意図的に拡げた会話をし始めました。
どのような範囲の拡げ方をしたかというと、
- エンジニアリング活動状況の可視化
- システム稼働状況の可視化
- プロダクトにおけるユーザー行動状況の可視化
の3つに領域を置きました。
ヒト・モノ・コトの観点となっています。
ヒト = 組織パフォーマンス、モノ = システムパフォーマンス が前提にある上で、コト = ユーザーが遭遇している事象について理解をしていきたいという思いです。
他の領域のデータも当然存在しますが、今後の展開を睨んだ上で取っ掛かりとしていくにはわかりやすさや必要性の理解度が一致しやすいものだったのでこの3つを選定しました。
それぞれにおいて具体的な内容について触れていきます。
エンジニアリング活動状況の可視化（ヒト）
開発組織としてのパフォーマンスを理解したいという考えで可視化に踏み込みました。
具体的な経緯や取り組み、考えなどについては別記事で記載しておりますので、良ければご参照ください。
開発生産性 Advent Calendar 2022 の25日目の記事として公開してあります。
Four keys について取り組んでみたらエリートクラスに到達したので生産性について考え直してみたりのあれこれ
可視化した結果感じたこと
チームごとの開発プロセスの違いによって、開発パフォーマンスにおける指標の差がハッキリと出るということがわかりました。
LeanとDevOpsの科学で言及されているようなことをどこまでやりきれるか、どこまで真摯に向き合うかによって大きな差に繋がってくるということを、研究結果として頭で理解していただけの状態から、それを実感できたことは大きい収穫でした。
もう1つ大きいのが、アーキテクチャ設計や運用設計によってパフォーマンスに影響を出ることを実感できたことも大きい収穫でした。
指標を見ながら何か改善に動いてみることで成果に繋がる部分は当然あるのですが、どこかで頭打ちになってしまいそうな状況も感じています。
アーキテクチャ内の結合度合いをどう考えるか、運用時の負担軽減をどこまで考え込むことができているか、これらによって開発パフォーマンスが左右されるということを確信できたので真摯に向き合わないといけないことを再実感しました。
システム稼働状況の可視化（モノ）
我々はシステムのフルリニューアルを経た経緯がありますが、その際、既存のシステムを刷新することになるのでモニタリングを含めた運用方法についても考え直す必要が当然のように存在していました。
一方で、フルリニューアルのプロジェクトの中でデリバリーを優先して考えざるを得ない状況があったことも事実で、予想に難くないと思います。
その結果、フルリニューアル前に実現できていたモニタリング水準を維持することは後回しにせざるを得ず、この状況をなんとか脱していくことを目指したいという考えで可視化に踏み込みました。
モニタリングツールの活用推進
まずは、モニタリングツールとして使い続けていた Datadog を再活用することで、システムに関わる各メトリクスを総合的に可視化できるようにしました。
後輩である@KawamotoShujiに対して口酸っぱく必要性を説きながら、彼が実働として動くことで普及が進みました。
（普及が進んだ結果、ダッシュボードを Terraform 管理する猛者も出てきて、大変そうだなーと思いながら応援していました）
この時に話していたこととして、各種インフラのリソース状況のメトリクスをただ可視化するだけに留まらせずに「システム全てが正常に稼働することを100点としたときに、減点可能性があるような不安な箇所のメトリクスを収集しよう」という旨を伝えていた記憶があります。
結果として、インフラ周りのメトリクスに加えて、とあるバッチ処理の処理数の可視化といったような観点にもアプローチをしてもらうことができました。
後に彼と話す中で「こうやって状況を正確に理解できるの、マジいいっすね」という言葉を貰ったことがあり、抽象的な表現ではあったものの当たり前レベルの認識が一致してきたと感じ、技術力的な1歩としては大きくないものの大きな意味を持つ1歩を踏み出せたと振り返っています。
SLIの設定とSLA（社内向け）の運用
次に、Datadog を用いたSLIの可視化を行い、SLAとして定義したい水準に足りているかどうかをモニタリングするようになりました。
正確には2021年から活動していた内容でもあったのですが、サービスが拡大し顧客が増加していく中で運用水準に関するヒアリングが重なることが続きました。
そういった状況で自社としての一定水準を示すようにしていく未来を見据え、まずは社内の運用から始めてみるといった経緯で検討を始めました。
SLIの選定については、経産省から出ているガイドライン（※）を参考に進めました。
こういったものを公開して頂けていることに本当に感謝しか覚えませんでした。話がスムーズに進められたのを記憶しています。
※SaaS 向け SLA ガイドライン - 経済産業省
SLAとしての水準の設定については、社内での限定運用であったため、現状値をベースに考えるようにしました。
現状から悪化が著しいような状況では当然何かしらの対処を検討する運用が必要になりますし、その運用を進めるための準備としても運用を回し始めることができればよいだろうと関係者とも会話をしていました。
結果、今では社内のボードメンバーが参加する会議にて毎回の報告議題として取り上げるようになりました。
報告をするからには単に数字の共有だけではなく、管轄部門による所感や今後の見通しなどの内容も必要になり、それが盛り込まれていくようになりました。
可視化した結果感じたこと
ここはありきたりな感想ですが、可視化してよかったと思えるような一般的な要素を感じました。
モニタリングを通じて、状況の正確な理解、そこからの推測、未来に対する予測について考えられるようになりました。
これは自分たちの責務範囲における責務の果たし方として非常に重要な意味を持っていると感じます。
つまり、説明責任の話です。
今までは可視化されていなかったことでよくわかっていなかったこともあり、説明をせずとも済んでいた部分がありました。
それが求められるようになったことで、思考して抑えるべきポイントが明確になり、それについて脳みそを働かせることになりました。
これが悪い方向に運ぶことなんて考えられません。
さらに追加で感じたこととしては、副産物としての洗練をもたらすことができた驚きでした。
Datadog に関する話で述べた話はダッシュボードの活用やAPMの活用についての話が起点でしたが、RUM（Real User Monitoring）という機能があることでさらに深い活用ができると知ることができました。
このRUMを活用することによって、不具合発生時の原因調査が圧倒的速度で進み出しました。
社内で2,3人かけて3時間ほどかけて突き止められていなかった原因を、RUM経由で5分で突き止めていたような場面を見かけたことがあります。
これを実現できるソリューションは偉大です。是非パワーを借りましょう。
プロダクトにおけるユーザー行動状況の可視化（コト）
これについてはまだ道の途中です。そもそも、ゴールがどこにあるのかもわかっていません。
とにかくまずはデータ基盤を作り、それを基軸に様々なデータを可視化/分析できる状況を作り出そうと進めてきました。
この話に関する具体的な動きは別記事でも公開しました。良ければご参照ください。
シンプルに始めてみるデータ基盤
上記に記載する動きの結果として、具体的なユーザー行動の一部を可視化していけるようになりました。
一方でPLG/SLG問わず、サービスを成長させていくことの全体を想定した指標の整備は不十分でした。
ここの指標出しがとても大切で、その部分の思考に時間を使ってきました。
思考を掘り下げる際には、下記に記すようなブレイクダウンをしていきました。
これは確か@pilot_fishが言い出した話で、道理に叶っており素晴らしい考え方だったと記憶しています。
- カスタマーが成功（期待する目的を叶える）に到達するまでのジャーニーのステップを確認
- ステップごとの理想状態（何を成し遂げられていると次ステップに繋がるか）を定義
- ステップ x 理想状態を計測できる指標を定義
この会話をした上で出てきた具体的な指標の可視化には至っていませんが、具体的な背景を基にモニタリングすべき指標について議論することができました。
可視化した結果感じたこと
（まだ具体的な可視化に到達していないので勘弁してください😭）
可視化できていない範囲が多いのですが、可視化のためのデータ集計を試みた中でもやはり発見はありました。
例えば弊社のサービスは時勢/トレンドに応じてデータの変動が反映されることも多いのですが、変動的なデータとこれまでの傾向を変わらないような恒常的なデータがあることがわかりました。
具体的な内容は入札リサーチセンターとして内容を公開しているのでご覧ください。
また、計測をしていきたい対象の指標が並ぶようになったことは、ユーザー視点でのプロダクト成長を目指す中では、思考を深められたという点で有意義に働いたと感じています。
指標に関する議論をする中でも理解度の相違に気づくことはあり、そういった部分の相互理解ができたことも大きな意味を持っていると感じています。
指標について会話した結果、現在取得しているデータで計測できる/できないについて理解が進んだことも良かった点でした。
なんとなく計測できるからデータを見たいと思ったらすぐに見ることができるはず、という暗黙の考えが一切排除され、データ整備についての必要性を深められたことも大きい要素でした。
可視化に関する取り組みを経て全体的に感じたこと
可視化は銀の弾丸には当然なりえず、泥臭さを強く要求するようになるもの
今年1年、様々なテーマに対してデータに向き合い、それを目に見えるようにすることで何かが変わることを期待してやってきました。
銀の弾丸ではないと聞くものの、可視化したら何か変化が勝手に起こるのではないかという期待もゼロではありませんでした。
そして実際に可視化をしてみたものの、銀の弾丸ではなかったことを実感しました。
可視化をした結果実際に遭遇したことは、
- その状況について現状理解を正しくするために分析すること
- 要因を掘り下げて分析の裏付けを作ること
- 分析を基に仮説を立てること
- 仮説を周囲に理解してもらうために説明を施すこと
でした。
文字だけで見ると当たり前のように感じる内容かもしれませんが、これを行うために費やす脳みそや時間のリソースたるや、生半可では足りません。
これらに対して真摯に向き合い、丁寧に要所を抑えることの泥臭さが自分たちに返ってくる結果でした。
技術力とは、解決すべき課題を技術で解決できる能力である
ここから、事業会社に対して求められる技術力という言葉の正体について考えることに至りました。
みなさんは技術力が表す内容ってなんだと思いますか？
わたしは少なくとも、今この記事を書いている状況においては、何かの言語やフレームワークを、しかも最新の情報をキャッチアップしていることでそれらを駆使して技術的課題を解決できる能力だとは思えなくなりました。
向き合うべきものは可視化された結果から見える課題をどう解決できるかであり、それを技術的に解決できる力が技術力なのではないか、そう考えるようになりました。
どれだけ言語やフレームワークを熟知していても解決すべき課題を正しく捉えられていなければ意味がない、課題を正しく捉えていても技術ではない方法で解決を促す、というようなことは技術力に根ざした話では無いのだと考えます。
高めるべき技術力についてどう考えるか
これまで書いたような前提を踏まえると、技術力を高めて成長をする、といったテーマにどう対峙したらよいのでしょうか。
答えはシンプルで、泥臭く掘り下げに掘り下げた結果、解決すべき課題に全力で取り組む、といったことだけです。
「フロント領域のフレームワーク理解を広めよう」
「インフラ領域にも手を出そう」
「Pythonを使ってデータ分析を使えるようにしよう」
などなど
こういった内容は小手先の考え方にしか過ぎないのではないかと考えています。
あまりに極端の物言いになっているので反発を買うかもしれませんが、誤解を恐れずに続けると、泥臭さに根ざした技術力ではないと本質的な課題解決はできないと考えています。
Web黎明期から活躍されている諸先輩方を見ていると、フロントだのフレームワークだのに縛られずにキャリアを踏みしめているように感じており、こういった泥臭さの上に根ざしている思考を持っているのだと感じています。
まとめ
エンジニアは課題解決屋だと思っています。
その解決を技術という手段を用いてアプローチするだけの特殊性があるだけで、他領域の課題解決屋と本質は大差ないはずです。
それを忘れずに今後の自身のキャリアや、周囲に対しての貢献の仕方を考えることを諦めないようにしようと思いました。
最後に
「可視化」と銘打っているので図などを使ってわかりやすく書き連ねたいと思っていましたが、正反対にテキストばかりの記事になってしまいました😭
それはさておき、2022年、株式会社うるるとしてアドベントカレンダーに参加させて頂きましたが、ご覧頂いた皆様、貴重なお時間を頂き大変ありがとうございました。
参加者である社内のみなさまも、忙しい合間を狙いながらお祭りに参加頂き、ありがとうございました&お疲れさまでした。
今年2022年、みなさまにとって大変よいお年であったことを願いつつ、来年2023年もさらなる良い年となりますよう願っております。
よいお年をお迎えし、素敵なエンジニア生活、素敵な仕事生活、素敵な私生活をお過ごしください！
メリークリスマス！！！🎄