声に出して読みたい FLINTERS "エンジニアリング指針" を声に出して読んでみた

みなさんこんにちは。PM(プロジェクトマネージャー)部門の担当をしている荒井です。

今回はFLINTERSブログ祭り！FLINTERS全社でチームに分かれてブログを書きまくっています。これを書いてる時点でブログ祭り始まってから8日経過ですが、もう26本も記事が出ています (凄!!)

なんかこういう大勢を盛り上げてくれる人がいるのもステキだし、背中を押されたらヒョイって乗っかって一緒に楽しんじゃうのもステキだなー。ということで、FLINTERSでステキだなって思っているもののうちの1つ 「エンジニアリング指針」を声に出して読んで見ることで、読書録としようと思います。
(声に出すことに意味はありません。小学1年生になった娘がガンバって音読してるので僕も音読してみようと思ったくらい)

テーマは #読書感想 #FLINTERS愛 #エンジニアリング指針 の3点です。

我らがFLINTERSのエンジニアリング指針

これです↓ (ドン!!)

ユーザー価値の高いシステムを素早く提供し続けることで、今までにない未来を作り出す。 これが我々の達成したいことです。

ふむふむ。僕たちFLINTERSの好きが詰まっているというか、普段めちゃめちゃ見ているわけではないけど、ふとした瞬間に何気なくみるとやっぱいいよねってなるような、そんな大事な共通の価値観が言語化されてる気がします。

前提として僕はエンジニアではないですし、エンジニアとしてコードを書いた経験もありません。(そして書くスキルもない) エンジニアではなくともいいなぁと思える内容ですし、自分たちがこうして価値を生み出したいと思えるものを言語化して公開してるのってなんかいいなって思うんですよね。

みんなが同じ方向を向いて力を集中したり、困った時の拠り所となったり、それでいてプロジェクトごとのチームや人の裁量が残されているような絶妙な抽象度。もちろん外部公開している分、実践していることへの覚悟も求められます。

こんなエンジニアリング指針をPM視点中心にはなりますが、それぞれ見ていきたいと思います。

エンジニアリング指針 目次

ユーザ価値を確かめる

苦労して完成させたとしても、ユーザーに価値をもたらさなければ誰も利用しません。
我々はソフトウェアやデータを作るだけにとどまらず、それらをユーザーが活用する場面まで関心を持ちます。

事前に価値をもたらせるか不確かな場合には、モックやプロトタイプによる価値検証を検討します。価値検証はできるだけ早く実施できるようにコードを書かない方法を優先します。
検証用にコードを書いた場合、価値検証後の本番プロダクトコードに安易に検証用コードを利用しません。保守運用の観点から利用の是非を検討します。

またリリース後は洞察を得るためにKPIを追跡し、プロダクトの改善に活かします。

はい、これ。エンジニアリング指針といいつつ、一番最初にこれが出てくるのが最高です。

もちろんFLINTERSは受託でのシステム開発が事業の主軸なので、開発をしてシステムを完成させることがお仕事です。ただ、それだけで満足する人はほぼいなくて、開発したものがどのような価値を生み出すのか、誰がどんな業務でどのように活用するのか。これらを開発する前に知りたい欲求が強い人が多いです。

PMとしても要件はこれ、仕様はこれ。なのでその通りに実装しておいて。なんてエンジニアとコミュニケーションとることはなく(その通りにやれば良いというレベルまで落とし込めるスキルがないというのもある)、プロジェクトの目的や活用方法を把握したらそれをエンジニアにもしっかりと伝える努力をします。

そのためにリーンキャンバスを作ったり、インセプションデッキを作ったり、業務フロー図を作成して理解を深めたり、一緒にユビキタス言語やドメインモデリングをしたりしています。

もちろん、半年も1年もかけて開発し続けてきたものがリリースしても誰も利用してくれなかった経験、開発している途中でこのまま作ってもユーザが求めているものとは違いそうだと感じてしまった経験も、僕もたくさんしています。

そうならないように、開発物を短いサイクルでレビューしたり、改善フィードバックを取り入れて改修したり、機能イメージが定まらないときにはプロトタイピングも駆使して確度をあげながら前に進めています。

お客さんからも、この機能で、この画面で、この仕様で開発してほしいといわれることはほぼなくて(ほぼ)、実情に合った内容であればこちらから提案もしやすい環境であるということも、この価値観の前提になっていると思います。

変化に強い構造を作る

環境は常に変化します。プロジェクトが少し進めば新しい視点が加わり、やりたいことややるべきことが変化します。また、利用しているライブラリやサービスは機能追加や脆弱性修正により変わっていきます。 そのため、我々は変化に強い仕組みを取り入れます。 - 変化が起こりやすい箇所の特定と変更を局所化するアーキテクチャとデータモデリング、変更しやすくするためのテストに取り組みます。 - アジャイルな開発プロセスを採用します。利害関係者の要望やチームのプロセス・成果物を明らかにし、目標の設定と実行のサイクルを短期間で回し、目標の調整とプロセスの改善に努めます。 - プロダクトを隅々まで把握し発展させることができるメンバーを継続的に育てるために、設計やコードをピアレビューします。

変化、というと人によって捉え方はまちまちだと思いますが、僕らはインターネット広告、デジタルマーケティング関連のシステム開発をすることが多く、それはもう驚くべきスピードで日々外部環境から変わってきます。

先ほど例に出した短いサイクルでのレビュー・改善フィードバックを行っている点からも、作ってみると元々想像していた機能がイケてなかったりより良い機能案を思いついたりというのは日々発生します。
外部のAPIが突然仕様を変更したり、アップデートしたら挙動が変わったり。最近でいうとOpen AIの高速アップデートも対処しないといけない項目の1つになってきました。

自分たち自身を変化させることで外部変化に適応していく、そのために開発やシステムにおいても変化させやすい状態を作っておくという考え方が強く浸透していると思います。

僕たちが開発するシステムは基本的には運用保守も自分たちで担当する、そして数年は利用され続けるものがほぼ全てです(ほぼ)。継続的に機能追加や改修ができるようにテストコードを書いてCIで自動化する、特定の1人しか触れないコードを減らすためにドメインモデリング会や複数人でのコードレビュー、インフラをコード化する、など各種の施策を行い変化しやすい状態を作り維持しています。(組織図も3ヶ月〜半年のスパンで変化し続けます)

適正な品質を目指す

プロダクトの品質は様々な視点からみることができ、例えば利用時の品質と製品品質の２つの視点が挙げられます。
品質は一面だけを見ず多面的に評価し、適正な品質を目指すことが重要です。またいずれの品質への要求も環境の変化と共に変化します。
利用時の品質が低いプロダクトはユーザーに価値をもたらしません。一方で製品品質が低いプロダクトは開発速度や拡張性やコスト効率等の点で、変化する品質への要求に応え続けることが難しくなります。
我々はビジネス課題を解決するのに必要十分な品質を定義することで評価できるようにしたうえで、点検し、向上させるよう継続的に努めます。

品質を手軽に高められる工夫をする
本質的な価値の創造に力を割くために、品質を高められるツールを積極的に取り入れます。例えば、静的型付け言語、豊富なエコシステムを持つツール、lintツールの採用が挙げられます。
プロダクトのコアではないドメインについてはSaaSを含む汎用部品の利用を検討します。
適切なツールがまだない場合は、自ら作ることも選択肢にいれます。

テストし監視する
品質を担保する上でテストと監視は大切です。
正解が定義できるものについてはテストを中心に、テストが難しいものについては監視を中心にアプローチします。

データを理解する
利用時の品質や製品品質の解像度を高める観点としてデータ品質があります。我々が扱うデータの量や複雑度が高まっていること、またデータはソフトウェアより長寿命で二次活用される機会が多いことから、データ品質の重要性もまた高まっています。
データを適切に扱うには、それが何であるかを理解する必要があります。ユースケース、値域や分布、データ間の関係性などの把握を通じてデータを理解し、データ品質の管理に活かします。

ともすればユーザ価値 = 速く機能追加したり改修するスピード重視？とも思われるかもしれません。

これは半分正解でもあるのですが、僕らが目指しているのはユーザー価値の高いシステムを素早く提供し続けることです。初回リリース時だけ速くても、その後もずっと発展させていくシステムの場合、コードが複雑で改修スピードが遅くなってしまったら速いとはいえないですよね。

そりゃ長期間のシステム運用であれば、対応するメンバーも入れ替わりは発生しますし、コードも何百回も改修されてマージされます。機能も増えテストケースも増え、毎回のリリース前にリグレッションテストを回すのも工数的にもスピード的にも無理が出てきます。

僕自身の経験でいっても短期スピードを追い求めたあまり、運用期間が長くなるに連れてスピードに課題を感じるものをたくさん経験してきたので、こういった手軽に品質を高める施策はすごく重要だなと身にしみて感じます。(その教訓も踏まえての指針になっているなと感じます。)

個人の強みを磨きチームで活かす

個人の能力や経験は均一ではありません。 個人がチームに貢献する際に様々な形があることを我々は理解しています。 各人が強みを伸ばしながら、チームとして最高の成果をもたらせるように努力します。

新しいことに挑戦する知性と勇気を持つ

我々の取り組むテクノロジー分野では日々新しいツールやプロセスが提案され、ベストプラクティスが変わります。
今取り組んでいる手法を深く追求するとともに、新しいコンセプトに好奇心を向け、知性と勇気をもって取り入れる挑戦をしていきます。

2022年3月 更新

最後の締めくくりがこれなのもいいなと思います。更新日が書いてあるということはこれも今後も更新するよって意思の現れです。

テクノロジーやツール、プロセスも新しいものが出てきますが、僕ら自身もどんどん新しいものを取り入れ試し、新たなスタンダードとともに自分たちをもっと磨いていきたいと思っています。

なんか書いていたらちょっと気持ちよくなって長々と美談っぽい内容になってきてしまいましたが、エンジニアリング指針で言語化しているものは、今後こうしていきたい！こう変えたい！という気持ちが半分まとまったものでもあるので、書いてあるものが全て完璧にできています！と胸を張っていえる状態ではないです。(それこそ胸を張っていうものではないですが)

ただ、書いたからにはこの指針を実現したい。その価値を証明したい。そしてそのころにはきっともっといい指針ができあがっているだろうと思っています。

このFLINTERSエンジニアリング指針はFLINTERS社員に向けた内容が中心ではありますが、新しく入社した方にはぜひとも読んでみてもらいたいですし(浸透ワークショップもあります)、今後FLINTERSに入社しようかなって思ってくれた人だったり、ちょっと最近システム開発で辛い状況にいる人にも元気を与えられるようなものになったら嬉しいです。

読んでみて、いいなって思ってくれた方はぜひ一度カジュアルにお話しましょう！

それでは、長々とありがとうございました。