DX(Developer Experience)を追求していけば良い製品をスピーディーに届けられるはずだ
エンジニアが良い製品を良い品質でスピーディーに作り続けたり、自己研鑽を続けるときに必要なのはDX(開発者体験)や楽しさだと思います。
地道なリファクタやパイプラインの整備やより良いアーキテクチャの導入などを取り入れていき、より製品そのものに注力できるようにすることをモットーにしています。
直近だとサーバレスというキーワードで技術習得をするのが良いアプローチだと信じて日々エンジニアリングをしています。
このプロジェクト詳細は公開されていません
このプロジェクト詳細は公開されていません
このプロジェクト詳細は公開されていません
自社クレジットカードのイシュアリングを担うシステムの機能開発と運用。カード発行、決済、債権回収機能及び明細管理機能、ユーザー向け、社内管理者向け画面を、複数のスクラムチームでScrum of scrums体制で開発を行っています。
複数チーム全体のスクラムマスター及び、1チームのPdLを担当しています。
機能開発保守全般を行うと同時に複数チーム全体のスクラムマスターと1チームのPdLを担当しています。
基本は案件ごとに要件定義〜Delivery全てを1チームモブワークで行っていますが、案件によっては私自身がメイン担当者として、あるいは他のメイン担当者のサポートとして、レビュー全般を担っています。
現在はScrum of scrumsの形をとっていますが、当初は大人数でスクラムを行っており、スクラムの形骸化やコミュニケーションコストの増加、また1チームで複数案件を取り扱うことによる認知負荷が大きな問題となっていました。
スクラムチームを複数に分割し、かつチームごとに担当するドメインを定義することでコミュニケーションと認知負荷のコストを下げました。
また、スクラムの原理原則の啓蒙を行い、アジリティのあるスクラム運用をすることができるようになりました。
スクラムチームが分割することによるチーム横断のディスコミュニケーションや実装箇所の競合等を防ぐための取り組みも行い、各自が並行して開発ができるようになりました。
スクラムマスターとしてチーム分割を主導しました。
並列開発するためのCI/CDフローやルール整備を行いました。
それらの改善と機能開発のアウトプットを出し続けました。
スクラムマスターとして複数チームのスクラム運用の整備
当初15人のエンジニアメンバーで1チームでスクラムを運用していましたが、チーム内コミュニケーションの複雑さや一部古参メンバーへの作業負荷の偏り、サービスの機能スケールに伴う認知負荷がネックとなり、技術や運用負債の取りこぼしや、ビッグバンリリースなど多くの問題が顕在化しました。
上記の問題を解決し、デリバリーや品質の問題に対しチームが健全に取り組める環境を作る必要がありました。
コミュニケーションや認知負荷に関する問題は1チーム内のコミュニケーションパスや関心の種類が多いものと考え、チームとチームが担当するドメインを分割するアプローチを取りました。
当初はLeSSを導入しスプリント内でのアプローチを取りましたが、そもそもサービスで取り扱うドメインが多岐にわたっていた為、スプリントレビューやレトロスペクティブでの認知負荷が下がらず、各メンバーや各チームにとって価値のあるものにならないことがわかりました。
そこで、Scrum of scrumsに切り替えて、情報集約のタイミングをボードメンバーだけに絞って会話することで解決することができました。
また、各チーム内でモブプロ、モブワークを行うことでチーム内の負荷や技術知識を平滑化することで、作業負荷の偏りを減らすことに成功しました。
Scrum of scrumsを取り入れたことでコミュニケーションパスや認知負荷や各チーム内のドメスティックな改善をすることができましたが、今度は各チームを跨いだメンバー間のコミュニケーションや技術知識の伝達が希薄になりました。
また、各チーム間の技術力の偏りも顕在化しています。
上記のような問題を解決するために、横断的に働きかけをするチーム内TLやEMを設置しようと考えています。