mongolyyのブログ

開発(Javascript, Typescript, Next.js)や勉強したことについて色々書ければと。

【スクラム】スプリント8を終えてみて

はじめに

メーカー系のコーポレート部門でソフトウェアエンジニアリングをしているmongolyyです。 私のチームでスクラムを初めて約2ヶ月。 今スプリントは3つPBIが残ってしまい、スプリントゴールが達成できませんでした。

結構忙しく、なかなか更新できていませんでしたが、前々回のスプリントのふりかえりがよかったなと感じたので、書き留めておくことにします。

Keep

  • タイムライン + 感情グラフのふりかえり
    • 振り返りの手法が自分のチームとマッチしていないなーと感じ、ふりかえりカタログから、タイムライン + 感情グラフな感じのやつをチームで選択し、やってみた
    • 以下のようなメリットが有った
      • 感情グラフを見ることで、チームメンバーの物の考え方(何をハッピーと感じてストレスと感じるか)が自然とわかる
      • タイムラインにより、考える元ネタがあるので、うまくいったことと、想定通りいかなかったことが出しやすい
      • 私のチームではスクラムのはじめと終わりは水曜日なので、木曜日、金曜日の話題が振り返りの場で出にくいという課題があったが、この方法だと、木曜金曜に発生した問題についても言及され始めた

speakerdeck.com

Problem & Try

  • スプリントゴール達成しないということが、火曜の朝になって気づいた
    • もっと早く気づくべきでは?ということで、スプリントの真ん中である月曜日のデイリースクラム定量的にストーリーポイントを見て話し合うことにした
    • 実は月曜日に少しやばそうと気づいているメンバーもいたので、なにか課題があるとデイリースクラムで表明があった場合は話し合った議事メモをデイリースクラムスレに残すようにするように決めた

次のスプリントのふりかえりも、近いうち書こう、、

「SCRUM MASTER THE BOOK」を読んだ

はじめに

上司と話していたときに、「mongolyyくんはスクラムマスターだよー」と言われて、「え?!この数スプリント、スクラムマスターの意識なかったんですけど..!」と思ったmongolyyです。 スクラムマスターとして、基本的な心得を身に着けたいなと思い、先日参加したRSGT 2021でも登壇されていたZuzana Sochovaさん著の本書を読んでみました。

感想

スクラムマスターとして、どういうスキルが必要か理解できた

よくメタスキルが重要というという話を聞いていたが、具体的に

  • ティーチング
  • 傾聴
  • 好奇心
  • 尊敬
  • 遊び心
  • 忍耐

が重要ということを理解しました。

特に、スクラムマスターとして大事なのは傾聴だなーと感じました。自分で踏み込んで話しすぎることも多いので、一歩引いて皆の意見を引き出すところにより注力したいなーと感じています。 偉大なスクラムマスターは文化人類学者というのを聞きますが、一方で、私は偉大なスクラムマスターは"親"という表現がしっくりきます。(チームをリーディングするという要素をより感じるので) "親"として、過剰な口出しはせずに一歩引いてチームを見守りつつ、主体的に動いて、チームの成長のきっかけを作れたらなーと思っています。

何を目指せばいいかも理解できた

スクラムマスター道の話も印象に残っています。

  • レベル1:私のチーム
  • レベル2:関係性
  • レベル3:システム全体

上記のうち、私はレベル2に着手し始め、自分のチーム外との関係に目を向け始めたところかな~と思っています。 本書を読んで、その先に"システム全体"として、組織や組織の一部に対して、アジャイルマインドセットスクラムの価値観を企業レベルに持ち込むというということが使命なんだなーと思いました。

私の所属する会社では、アジャイルに馴染む組織、プロジェクトは多くはないものの、エッセンスを少しずつ導入できたらいいなーと夢を描くようになりました。 スクラムマスターではあるものの、妄信的なスクラム信者にならぬよう、自分で効果が出そうか見極めて、場合によっては、逆風の中も信念を持って、新しい概念のインストールをしていきたいなと思っています。

まとめ

私のチームにスクラムコーチがいることもあって、既知の内容が多かったです。 ただ、逆に言うと、スクラムコーチが事前、その場でやっていたことが多く、本書によってそれらの理由が少しわかりました。

スクラムマスターに任命された方は本書を読むことで、スクラムマスターとしての一通りを掴むことができるので、非常におすすめです。 ただ、スクラムに対して、未知などを理由に抵抗があったり、完全にできないこともあるように思います。 実際にスクラムを導入するためには、強い意志 + 経験 + 知識が必要になってくるので、本書で知識をつけつつ、スクラム経験者を巻き込む or スクラムへの興味が強い人を巻き込んで、都度相談していく、、というのがスクラム成功の秘訣ではないかなと感じました。

【スクラム】スプリント2を終えてみて

はじめに

メーカー系のコーポレート部門でソフトウェアエンジニアリングをしているmongolyyです。 私のチームでスクラムを初めて早二週間。スプリント2終えてみての感想です。 スプリント1はスプリントゴールを達成しましたが、スプリント2はスプリントゴールを達成できませんでした。最後のPBIが着手中でした。

mongolyy.hatenablog.com

の続きです。

Keep

  • プロダクトバックログリファインメントを始めた
    • プランニングに時間がかかっていたので初めて見たが、時間短縮になった
    • ただ、今回は次スプリントのバックログリファインメントしかできなかった
    • 次回は数スプリント先のバックログリファインメントもできると良さそう
  • デザインチームのレビューを始めた
    • デザインの精度が上がるだけではなく、POとデザイナーの距離も縮まった

Probrem

  • デザイナーと開発チームの距離感はまだある
  • 朝会が、形式化して、問題の共有ができていなそう

Try

  • PO、デザイナーをモブワーク部屋に来てみたら?と誘ってみた
    • 相手は乗り気なので、これで距離感、情報共有度は上がりそう
  • 朝会をエクストリームにしてみる
    • ファイブフィンガーでチームの状態を確認
    • 問題なさそうであれば、即解散
    • 3以下の人がいれば、それについて議論する

次のスプリントも頑張っていきます

【スクラム】スプリント1を終えてみて

はじめに

メーカー系のコーポレート部門でソフトウェアエンジニアリングをしているmongolyyです。 私の部署(多分会社全体でも)ではスクラムを導入しているチームはないものの、顧客の要望がはっきり見えない中で満足度の高いシステムを早急に提供したいね、、ということで、私のチームで段階的にスクラムを導入してみようということになりました。 本記事を始めとして、スプリントごとの振り返りをしてみようかなーと思います。

言葉の間違い等あるかもしれませんが、そこは優しく指摘していただけると幸いです。

私のチームはPO、週2稼働のデザイナー、アジャイルコーチ含め7名で構成され、かなり初対面なメンバーだらけで、かつ、スクラムな開発はおろかアジャイル開発もしたことないメンバーばかりでした。 アジャイルコーチはもちろんバリバリなわけですが、他のメンバーで言うと、私がアジャイル開発を経験していた程度でした。(あと、一応昔とった杵柄的にSCMは持っている)

その他、ステークホルダーとして以下のような方々がいます

  • 事業部の方
  • エンドユーザー
  • 私の上司達

Keep

  • ユーザーストーリーマッピングを使用して、事業部の方と打ち合わせ
    • Miroを使用
    • 事業部が考えている、理想のシステムが少し分かってきた
    • 話し膨らみすぎ問題があったので
      • 話が膨らみがちなので、話さないことを最初に言うようにした
      • 話が膨らんだとき用に、パーキングロットを作った
  • ワイヤーフレームを使用して、事業部の方と打ち合わせ
    • Miroを使用
    • デザイナーの方がいるからこそ取り組めた。これがここまで早期にできたのでかい!
    • 画面があることにより、ユーザーストーリーマッピングよりも深く、また、別の角度から意見が出るようになった。
      • この時点でユーザーストーリーマッピングと若干異なる意見も出てた気がする
  • 開発者のモブワーク
    • 最初、モブプロをしていたが、個々で仕事が進められる様になったのでこの形になった
    • ビデオ会議システムをつけっぱなしにして、基本全員マイクはミュート。適宜相談、質問しながら仕事
    • 私はロール的に会議が多いので、数分の空き時間でもこの部屋に入って、質問や相談に乗るようにしていた
    • 心理的安全性が高く、開発初期で何も決まっていない状態だったという条件が相まってチームにフィットした
  • デイリースクラム
    • デイリースクラム前に本日やることなどをSlackに書くようにした。
    • 一言を書いてもらうようにした。困りごとの枠とは別に、ボヤキのようなことがここに書きこまれた
    • チームリーダーとしては、みんなのアラートに早く気付けるきっかけとなってめっちゃ良かった

Problem

  • 私がPO、デザイナー業務に目が向けられていなかった
    • タスクのスケジュール感について認識相違が発生していた
    • スクラムな開発、、というか、チーム開発が初めてのメンバーだったので、もう少しサポートすべきだった
    • もっとPOとデザイナーが連携したり、POと開発チームが連携できるように促すべきだった

Try

  • 開発チームメンバーは初対面だったが結構信頼できるということがわかった
  • もう少し背中を預けて、PO業務をサポートしつつ、スクラムマスターとしてチームの障害を取り払っていきたい

「モノリスからマイクロサービスへ モノリスを進化させる実践移行ガイド」を読んだ

はじめに

上司や同僚と会話していたときに、マイクロサービス、マイクロフロントエンドの話題が出てくるのですが、概要しかわかっていませんでした。
マイクロサービス、マイクロフロントエンド自体の解像度を上げたり、現場に適応できるのか理解を深めたいなーと思い本書を読みました。

モノリスからマイクロサービスへ ―モノリスを進化させる実践移行ガイド

モノリスからマイクロサービスへ ―モノリスを進化させる実践移行ガイド

  • 作者:Sam Newman
  • 発売日: 2020/12/26
  • メディア: 単行本(ソフトカバー)

感想

マイクロサービス化の準備のイメージがついた

本書を読んで、マイクロサービス化は以下のような流れで進めていけばいいのかなと理解しました。

  1. 目的を定める
  2. ドメインモデルを作る。イベントストーミングを通して、ステークホルダーと共通理解
  3. チーム、組織を再編成
  4. 定量的、定性的に計測しながら各マイクロサービスを段階的に移行していく

旧システムからの移行(含: to モノリシック)について理解を整理できた

マイクロサービスへの移行パターンについて、以下のようなものを学びました。

  • スタラングラーアプリケーション
    • プロキシを挟んで、新システムをモノリスから切り出して、マイクロサービスとして稼働させて、リダイレクトで移行していくパターン。すぐに戻せるのがメリット。
  • UI合成
  • 抽象化によるブランチ
    • 既存のシステムで、マイクロサービス化する部分に対して抽象化のクラスを用意する。それまでのコードは実装クラスのコードとし、既存のシステムは抽象化クラスを通して実装クラスのコードを呼び出すように変更する。
    • その実装クラスの機能をマイクロサービス化する。新たに実装クラスを作成し、そのマイクロサービスを呼び出すようにする。
    • 準備が整ったら抽象化クラスと実装クラスの関連付けを変更してマイクロサービスを呼び出す実装クラスを稼働させるようにする。
  • 同時実行
    • 既存のシステムも新しいシステムも同時に動かす。複雑な仕組みを移行した場合に有用で、差分を比較することで正しく動いているか評価できる。
  • デコレーティングコラボレーター
    • 既存のシステムの前にプロキシを置き、そのプロキシからマイクロサービスを呼び出すようにする。既存のシステムに変更を加えなくて良いことがメリット。
  • 変更データキャプチャ
    • モノリスによって変更されたデータをキャプチャして、それをトリガーにマイクロサービスを動かす。

他に、データベースの移行についても10弱のパターンが紹介されていました。

上記はマイクロサービスへの移行を前提に書かれているものではあるのですが、業務システムを作っているものとしては、現行システムの一部だけを切り出し、新システムとして稼働させるみたいなこともあり、そこについて役立ちそうな知識(フューチャーフラグ、スパイを使う等のテクニック)があったのが今後役に立ちそうでした。 特にフューチャーフラグのあたりは最近同僚とのディスカッションテーマだったりもしたのですごくタイムリーでした。

まとめ

システム設計周り、特にDDD周りの知識が増強されたり、システムの移行の手法について手札が増えたように感じました。 また、マイクロサービスの概要、DDDの節を中心に、最近読んだ「Design It!」とも関連する話だなーとも思いました。

Design It! ―プログラマーのためのアーキテクティング入門

Design It! ―プログラマーのためのアーキテクティング入門

  • 作者:Michael Keeling
  • 発売日: 2019/11/25
  • メディア: 単行本(ソフトカバー)

「マイクロサービス化したら良くなるわけではない。現況を踏まえて判断しなさい」との記述がところどころにあったが、それを踏まえてなのか、本書ではマイクロサービスが前提になっていつつも、マイクロサービス化しなくても当てはまるパターンやテクニックの紹介があり、非常に有用でした。

Web API: The Good Parts を読んだ

はじめに

最近の業務で、SaaSと連携したシステム構築によりWeb APIにふれる機会が多くなったり、Next.jsでシステムを構築する中で、自身でAPIを作成することも出てきたので知識の整理をしたいと思い、「Web API: The Good Part」を読んでみました。

Web API: The Good Parts

Web API: The Good Parts

 感想

API設計の具体的なベストプラクティスをまとめて知ることができた

本書を読むまでは、なんとなくググったり、先輩社員に聞いて設計していることが多かったので、まとまった知識がなかったように思います。
近いうちに新しく開発チームを作り、APIの開発業務が発生しそうだったので、今回得た知識でガイドラインが作成できそうだなーと感じました。
特に、私は以下のような内容が勉強になりました。

  • エンドポイントで使う単語について
    • 複数形の名詞を利用
    • 単語を繋げる場合はハイフンを使用
  • クリパラメータ
    • ページング発生時
    • 絞り込み時
  • レスポンスデータのフォーマット
  • APIのバージョン番号
  • セキュリティ関係のHTTPヘッダ

API設計について標準として決まっていないものが多いのですが、国内外の有名なAPIを例に比較し、作者の見解が記載されているというスタイルにより、理解が進みました。

API周りの関連情報を知ることができた

特に印象深かったのは HATEOAS です。
APIがどういうレスポンスを返すべきかの1つの解だなーと感じました。

あと、REST API = HTTP/HTTPS通信でJSON形式でデータを返すAPIだと理解していましたが、その理解は間違っていることもわかりました。今後は言葉に気をつけようと思います。

まとめ

マイクロサービス化、マイクロフロントエンド化、SaaS利用、連携が増えていく中でAPI設計知識の重要性は今後更に上がってくると思います。
本書を読むことで、API設計のスキルも上がると思いますし、APIを使う側だとしても、サービス選定時に「良い設計のAPIを提供しているか?」という評価ができるようになると感じました。
チームメンバーにも本書を紹介したいと思います。

async/await, thenの使い分け

はじめに

会社の同期から、Javascriptの非同期処理について、「async/awaitとthenでどっちを使ったほうがいいのだろうか?」と聞かれて、基本はasync/awaitでよいけど、thenの方が良い場合もあるなーと思ったので、調査、整理してみました。

async/awaitが優れている点について

async/awaitはES2016で追加された文法なので、それまでのthenが抱えていた課題を改善、解決する、非同期処理の記述が可能になります。

具体的には以下のようなメリットが有ると思っています(個人的意見)

  • 複数の非同期処理について、依存関係が発生してくる場合に書きやすい
  • エラーハンドリングが見やすい
  • Javascriptエンジンによっては早くなる
  • thenを使ったときと比べてネストが発生しない

一つ一つについてコメントしたいと思います。

非同期処理について、複雑に依存関係がある場合に書きやすい

async/awaitを使用すると、非同期処理に依存関係は発生している場合効果を発揮してくると思っています。
以下のように、同期処理を記載するとほとんど同じ書き味で書くことができます。

const asyncFunc = async () => {
    const getUserId = () => Promise.resolve(...) // APIを叩いてuserIdを取得する関数
    const getGroup = (userId) => Promise.resolve(...) // APIを叩いて、Promiseでラップされた引数で与えられたユーザーが所属するgroup情報を取得する関数
    const getDepartment = (userId) => Promise.resolve(...) // APIを叩いて、Promiseでラップされた引数で与えられたユーザーが所属するdepartment情報を取得する関数

    const userId = await getUserId()
    const groupId = await getGroup(userId)
    console.log(groupId)
    const departmentId = await getDepartment(userId)
    console.log(departmentId)
}

一方、これをthenで書こうとすると、次のように書くことができます。
Promise.allを使用したり、ネストが発生したり、async/awaitと比べると見づらいコードになっているかなーと感じます。

const asyncFunc = () => {
    const getUserId = () => Promise.resolve(...) // APIを叩いてuserIdを取得する関数
    const getGroup = (userId) => Promise.resolve(...) // APIを叩いて、Promiseでラップされた引数で与えられたユーザーが所属するgroup情報を取得する関数
    const getDepartment = (userId) => Promise.resolve(...) // APIを叩いて、Promiseでラップされた引数で与えられたユーザーが所属するdepartment情報を取得する関数

    getUserId().then(userId => {
        Promise.all([getGroup(userId), getDepartment(userId)]).then((values) => {
                values.map(value => console.log(value))
        }
    })
}

エラーハンドリングが見やすい

JavaC++と同様のtry/catchが使えるので、エラーハンドリングが見やすいです。
一方、then/catchはメソッドチェーンになるので、catchを書き忘れていても気づかずスルーかもしれないなーと感じますので、try/catchを使用することでそのようなミスも減りそうかなと思います(慣れの問題かもしれませんが)

Javascriptエンジンによっては早くなる

awaitについてJavascriptエンジンごとに独自の実装がされているので、Javascriptエンジンによる、パフォーマンスチューニングが可能なようです。
例えば、V8ではPromiseをそのまま使って処理したときよりも早くなるようです。

v8.dev

thenを使ったときと比べてネストが発生しない

ここはawaitの説明でもよく出てきますが、個人的には一つネストするくらいなら別に可読性は落ちないんじゃないかなーと考えています。
また、map関数もあったりするし、引数で匿名関数を渡すケースはJSにおいて普通にあることにも思えるので、このくらいいいのではないかなと思っています。

thenを使うとき

今まで、async/awaitの素晴らしさを書いたわけですが、以下のようなケースでは、thenを使ったほうがいいんじゃないかなーと個人的には思っています。

  • Promiseの後処理がかなり単純な場合
      • fetch APIのresponseを取るとき

また、以下のケースは問答無用でthenを使わなければならないです。

  • async funcの中以外で非同期処理を書く場合
    • 関数の中に書いていない場合(グローバル変数など)
    • 関数について、何らかの制約があり、asyncキーワードがかけない場合
  • ES5以前を使用している場合

それでは、個人的に考えているthenを使ったほうがいいケースについて書いていきます

Promiseの後処理がかなり単純な場合

例を見てみていただくのが一番わかり易いと思うので、書いてみます。
無駄な変数を定義しなくて良い分、読みやすく、意図もはっきりしたコードになっていると思います。

例 fetch APIやaxiosを使って取得したデータから必要な情報のみを取得する場合

thenで書いた場合

// Fetch APIを使った場合
const userId = fetch('http://example.com/api/user')
        .then(response => response.json())
        .then(data => data.id)

// axiosを使った場合
const groupId = axios.get('http://example.com/api/group')
        .then(response => response.data.id)

async/awaitで書いた場合

// Fetch APIを使った場合
const response = await fetch('http://example.com/api/user')
const user = await response.json()
const userId = user.id

// axiosを使った場合
const group = axios.get('http://example.com/api/group')
const groupId = group.data.id

まとめ

async/awaitとthen、使うならasync/awaitだが、thenで書いたほうがいい場合もある(個人的な見解です)

みなさんもご意見あれば、コメントいただけると嬉しいです!