2019年7月から参加したAzitを、2020年6月30日をもって退職することになりました。
AzitにはSREとして参加しましたが、開発プロセスを設計したり、開発物を考えたり、データを分析してみたり、 振り返ればSRE的な仕事はほとんどしておらず、色んなことに手を出した一年でした。 「サービス開発」という物事に対して、ソフトウェアエンジニアとしてだけではなく、 様々な観点から考える機会を貰えたことに今はとても感謝しています。
んで、今は有給消化期間になりましたので、とりあえず頭の中に溜まってた諸々の学びを外に出していこうと思います。 やってきたことがとても幅広いので、どのように見せるのが適切なのかウンウン唸っていたのですが、 うなり続けても全然見つからないので、一旦思いつく範囲で具体的に書き下してみました。 とりあえずは読みやすさを完全に無視して、やったことや学びとなったことを箇条書きで、粒度も揃えずに書き出します。 そのうちこの記事に書いた内容を追記・修正して再編集していこうと思います。
ここに書いた内容について、詳細を知りたいという奇特な方がいましたら、ブコメとかでコメントください。 そこだけ切り出してブログにまとめられそうなら、やってみようかなと思いますー。
Azitでやったこと一覧
ソフトウェア開発
開発プロセスの設計
- 下記４つの手法をもとに開発プロセスを策定した
- アジャイル・スクラム
- ユーザーストーリーマッピング
- リーンスタートアップ/アナリティクス
- デザインスプリント
新規サービスの開発
- リーンアナリティクスにおける共感フェーズ達成のための目標設計など
学びまとめ
開発プロセスについて
- 開発プロセスで重要なのは目的と思想であり、漠然と手法を守ることではない
- 理想とする開発組織の状態を考え、その状態にするために使える開発プロセスを採用する
- 開発プロセスの「守破離」はもちろん大切
- それ以上に、理想とする開発組織の状態とそこに至るための過程を考えることが重要
- KPTはチームを目標とする状態に軌道修正するための場であり、目標とするべきチームの状態と、チームの現状を適切に把握する手段がなければ機能しない
- 開発プロセスの改善においては、チームメンバーで同じ本を読み、共通認識を持つことができると難易度がぐっと下がる
読書会について
- 開発プロセスの改善にあたって、共通認識となる知識の土台が欲しかったので、めちゃくちゃ読書会をやった
- 全盛期は週５で毎朝やっていた
- 「正しいものを正しく作る」「ユーザーストーリーマッピング」「図解リーンスタートアップ」「リーンアナリティクス」「SPRINT 最速仕事術」などをチームで読んだ
- 結果として、チームの中で普通にリーンスタートアップ/リーンアナリティクスの用語が普及し、開発プロセスの改善に大きく役立った
- 普通に仕事をしている中で、あるべき開発の姿について、定期的に腰を据えて話し合うことができるチームは少ない
- 読書会をし、チーム全体で議論をすることによって、あるべき形はどうなのか。我々は何ができてて、何が足りないのかを定期的に考える機会が生まれた
- これによりKPTの質も上がった
- 書籍に書かれている情報をもとに各々の経験を持ち寄って話し合うなど、ハンガーフライト的な役割も果たしてくれた
Azitでやったことについて
ソフトウェア開発
基本的にはあんまり目新しいことは出来ていない。箇条書きにするとこんな感じ。
- AWS上のインフラリソースをterraformやaws-cdkを使って大体コード化した。
- 基本的にはTerraformを利用する
- Lambdaに関連するリソースはテストやデプロイの容易さという観点からaws-cdkを利用して管理する
- Datadog等の監視用SaaSもTerraformで管理して、監視基準の設定を変更するときはPR上で意図を残すようにした
- 監視設定については、SRE WorkbookとDatadogのmonitoring 101 を参考にした
- AWSアカウントをAWS Organizationを利用して、staging/production/管理用と３つのアカウントに分割した
- G Suite + AWS ALBの組み込み認証の導入
- メール送信を自前のメールサーバーからSendGridに移行した
- 新規サービスを Rails & React(redux)を利用して構築した
Rails & Reactを利用する上で書いたブログ記事はこちら。
もっと沢山書いておけばよかったですね。CDK周りについてはもうだいぶ忘れている。 SendGrid周りについては、まだ知識が新しいのでブログに書こう。
開発プロセスの設計
開発プロセスは、リーンスタートアップ・アジャイル・デザインスプリントの３つを軸として設計しました。 具体的にはこんな感じ。
- 解くべき課題をリーンスタートアップにより推定し
- 課題を解くために必要な機能をデザインスプリントにより見つけ出し
- 見つけ出した機能をアジャイルに作り出す
リーンスタートアップで解くべき課題を選定する
上記に、リーンスタートアップで機能を開発するときに考えた諸々をブログでまとめています。 ここで私が学んだこととしては、10~15人くらいのチームであれば 目標を一つに絞って職種の垣根なく協力することが、最も良い結果を生むということです。 全員で一つの目標を追うことはコミュニケーションコストも掛かりますし、マネジメントコストもかさむでしょう。 だからと言って安直に職種ごとに目標を設定すれば、結局は局所最適化が発生します。 局所最適化による組織的な負債は、把握が非常に困難です。 見えないボトルネックほど怖いものはないので、ここはマネジメントする人間の踏ん張りどころだと思います。
この他にも具体的に開発物を考えていく上で学びになったことがたくさんあるんですけど、力尽きたので一旦ここまで。
Design Sprintで課題を解決するのに有効な機能を見つけ出す
- デザイン思考について様々な意見があることは知ってる
- ただ、デザインスプリントはチーム開発において、再現性高く課題解決が可能な開発プロセスであると思っている
- デザインスプリントにおいては「権限」を持つ人が参加し、適切に権限を行使することが求められる
- 「達成する責任はあるけど、決める権限はない」という人間が多く存在する現場は少なくない
- 現場においては権威がない人間の素晴らしいアイデアよりも、権威がある人間の的を外したアイデアの方が採用されうる
- 意思決定プロセスを明確にし、不健全な責任と権限のバランスによる機能不全を防ぎ
- アイデアと発案者を明確に分離し、評価することができるという点において、デザインスプリントはよく練られた開発プロセスだと思う
- デザイン思考に対する批判の中に、答えはユーザーの中にないというものがある
- それはそのとおりだが、サービスによって成し遂げたい世界観とユーザーの間には「課題」が必ずあるはず
- その「課題」を見つけ出し、課題に適切な「解決手段」を見つけ出す上でデザインスプリントは効果的
- また、仕事の9割は卓越したイノベーションにより解決されるのではなく、現場の課題の泥臭い改善であり
- その改善の速度と精度が競合優位性を作るのだと思う
- 大抵の失敗は、ユーザーを理解したつもりになっていることによって起きている
- 課題はサービスを作る人間が頭の中だけで考えるよりも、現場にいって直接目で見ることが大切
- この点はリーンと非常に親しい開発の思想な気がする。徹底した現場主義
- このあたりはもうちょっと本を読んで比較・整理してみる
アジャイルで作る開発チームを考える
- 基本的にはアジャイルで作ることにした
- アジャイルを推進していくにあたっては、最初に最終的なチームの成長目標を描いた
- そして目標状態に至るためのフェーズを書き出した
- Phase 1. アジャイル開発のインストール
- Phase 2. ユーザーストーリーマップの導入とQCDのハンドリング
- Phase 3. 仮説検証型の開発への移行
- Phase 4. リードタイムの短縮
- Phase3の方がPhase2よりも大切だが、いきなりチーム全体で行うことは難しい
- 先に限られたメンバーでPhase3をある程度形にする
- Phase3を少人数で実施できたら、チームメンバー全体でやる
- 自分たちのフェーズを認識し、そのフェーズの目標を達成できているか振り返る
- スクラムマスターは、振り返りに必要な定量・定性的情報を常に整理する
- スクラムマスターはチームの補助輪であることを認識し、自らが積極的にファシリテートしなくても回るチームを作るのが理想
開発チームの目標とする状態
- 自分たちが作るべきサービスについて、その存在意義、届けるべきユーザー、届けるべき価値について正しく理解している
- 自分たちが作るものに対して、開発チームが主体となってQCDをコントロールして開発ができている
- チームの全てのメンバーが、無駄なく目的とするサービスを作れている
- 自分たちが届けたい価値について、どのような方法で届けるのか精度が高い仮説を出せる
- 自分たちが作った機能について、事前に建てた仮説が正しかったのか検証することができる
- 上述した取り組みについて、新しい知識を積極的に取り込み、改善し続けることができる
Phase1の目標状態
- アジャイルに対する体系的な理解とその実践ができてる状態を目指す
- プロジェクト管理をする上で必須となるスキルの習得
- プロダクトオーナーから開発チームに齟齬なく要求を伝えられるようにする
- 完了の定義を明確にし、届けるべき価値について認識に相違ないようにする
- タスクを細分化し、それらを相互確認することによって無駄な仕事をしないようにする
- タスクを見積もり、いつまでにどのような価値を届けるのか、ステークホルダーと合意を取りながら進めることができる
Phase2の目標状態
- 開発チームが作るべき機能について、その仕様を自分たちで決めることができる
- そして、開発チーム外のステークホルダーと協力して開発できる状態を目指す
- 取り込むべき知識は下記２点
- ユーザーストーリーマッピング
- Minimum Lovable Product
Phase3の目標状態
- アジャイルとリーンスタートアップを結合し、効果的に運用できている状態を目指す
- リーンアナリティクスにおけるOMTMや、課題・仮説キャンパスを設定し、そこから開発物を考案できる状態にする
Phase 4の目標状態
- DevOps的な概念を導入して、諸々自動化し、リードタイムが短縮される状態を目指す
- まだ解像度は高くないが、チームとして目標とする状態の順番を示すための書いた
- もちろん開発効率の向上はどのフェーズでやっても良いが、全体をみる人はこの優先度で頭を使った方が良いと思っている
最後に
他にも色々ありましたが、一旦疲れたのでここまで。 また記事を書いていくなかで、追記していこうと思います。
