銀行員からのRailsエンジニア

銀行員からのRailsエンジニア

銀行員から転身したサービス作りが大好きなRailsエンジニアのブログです。個人で開発したサービスをいくつか運営しており、今も新しいサービスを開発しています。転職して日々感じていること、個人開発サービス運営のことなどを等身大で書いていきます。

当ブログではアフィリエイト広告を利用しています

【読書まとめ30】いちばんやさしいアジャイル開発の教本

勤務している会社でアジャイル開発を取り入れはじめ、開発・ビジネスサイドのメンバー合同で「いちばんやさしいアジャイル開発の教本」の輪読会を行いました。

学びが多く、これからアジャイル開発を実践していく中で、都度振り返れるようポイントをまとめました。

f:id:ysk_pro:20210611082845p:plain

なぜアジャイル開発が必要とされるのか

従来型の開発手法であるウォーターフォールの課題を整理し、その上でなぜアジャイルなのかを学びます

ウォーターフォールとは

一言で説明すると

開発をいくつかの工程に分けて順番に取り組んでいく手法

 

メリット

工程が明確に分かれているので、進捗確認、役割分担がしやすい

 

ソフトウェア開発の難しさ

開発したけど使われない問題

ソフトウェアの6割の機能は使われていないという調査結果がある

なぜそんなことが起こるのかというと、利用者が欲しいと思っているものが本当に必要かどうかは、利用してみるまでわからない

 

不確実性が高い

特にプロジェクト初期ほど不確実性が高く、見積もりから大きくブレやすい

プロジェクト初期では、見積もりの0.25倍〜4番の振れ幅があるとされている

 

ウォーターフォールの課題

  • 手戻りができない。ただ、実際にソフトウェアを触ってみないとわからないこともあるので、要件を最初に全て決めることは現実的ではない → 本当に必要なものからかけ離れたものが作り込まれてしまうリスクがある

  • 前工程で遅延が発生した場合に、後工程で辻褄あわせのために期間が圧縮されることがある。前述のように序盤の工程ほど不確実性は大きい → テストなどの工程が削減され、品質の低いソフトウェアになるリスクがある

 

ウォーターフォールアジャイル開発の違い

  • ウォーターフォール:各工程での成果物を完成品とみなし、後工程での手戻りが発生しないようになっている。各工程は1度ずつのみ行う
  • アジャイル開発:一定の期間(スプリント)ごとに動くソフトウェアが作られ、次のスプリントではそのソフトウェアから得られた気づき・フィードバックをもとに要件レベルから見直しが行われる。 スプリントの数だけ各工程を繰り返す

アジャイル開発だと少しずつ動くものを作るので、細かくフィードバックを受けることができ、本当に必要なものを作れる可能性が上がる

 

アジャイル開発の原則・コンセプト

アジャイル開発について理解するために、原則・コンセプトをまとめます

主な原則

  • 継続的かつ短い間隔でのリリース
  • ビジネスサイドと開発者の協働
  • 対話の重視
  • 絶え間のないカイゼン
  • ふりかえり
  • 動くソフトウェアの重視
  • 要求の変更はたとえ開発の後期であっても歓迎する

 

3つのコアコンセプト

  • チームアジャイル開発における機能するチームは、自己組織化されており、職能横断型なチーム
    • 自己組織化:自分たちで物事を決めて自律的に動けること
    • 職能横断型:複数の専門性を保有し、ソフトウェアを完成させる能力を有していること
  • インクリメンタル少しずつ作る
  • イテレーティブ反復的に作る。反復的に作ることで、経験・得られた学びに基づき次の開発ができる

 

具体的な手法・カイゼン

職場で実際に使えそうな手法や、カイゼンの例をまとめました

カイゼン」は、改善とは区別されています

  • カイゼン今あるものをより良いものしていくという、前向きで積極的な活動を意味する
  • 改善:発生している問題を取り除くという、カイゼンに比べると若干後向きなニュアンス

プロジェクト開始時に有効な手法

プロジェクト、プロダクト作りを始めるにあたり、目的や前提を把握することやチームメンバーへの理解を深めることは、状況に応じた判断を自分たちで行うための第一歩。このような共通理解を深める3つの方法がある

  • インセプションデッキ:プロジェクト、プロダクトレベルで目的や目標、前提や制約を理解する
  • ドラッガー風エクササイズ:チームメンバーレベルで考え方や得意なことを理解する
  • ワーキングアグリーメント:チーム活動レベルで協働のためのルールを理解する。何か問題が起きる都度、ルールの追加、変更を検討する

 

デイリースクラムカイゼン

  • 進捗遅れがあるにも関わらず「問題ありません」発言が目立ってきたら、「困っていること」から「モヤモヤと違和感を感じていること」に変えてみると良い。メンバーが問題を共有するハードルを下げることができる
  • ファイブフィンガーで進捗状況を発言しやすくできる。スプリントゴールの達成度合いは5本の指で表現するといくつぐらいか、と数字の大きさで表明してもらうと、問題ありませんと発言していたメンバーも数字の理由を聞くことで状況を発言しやすくなる
  • 個人レベルの失敗を共有することは、チームで成果を出すための成長と前進のきっかけ。デイリースクラムで共有される問題は、他のメンバーが同じ失敗をしないための学びのきっかけであることを強調するためにも、マネージャーなどから積極的に行っていく

 

振り返りのカイゼン

  • 暗くなるようの反省会のようになってしまったら、良いことをさらに良くするための振り返り方法を試してみる
  • 「YWT」やったこと(Y)、わかったこと(W)、次にやること(Y)を意味し、わかったことという気づきをベースに、次にやることを明確にできる。気付いた学びを次に活かすという流れが成長を促進する
  • 「Fun! Done! Learn!」楽しかったこと(Fun!)、やったこと(Done!)、学んだこと(Learn!)を意味し、これら3つの円を重ね合わせて、実施したことがやっただけなのか、楽しさも同居していたのか、さらには学びもあったのかを振り返る。振り返りながら楽しさをイメージするため、記憶に残りやすい成功体験の学びになる
  • KPTカイゼン策に、YWTは気づきに、Fun! Done! Learn! は楽しかった学びに関心のフォーカスが当たる。3種類の振り返りを定期的に変えたり、状況によって使い分けることで形骸化を打破できる
  • こぼれ球を拾う、手こずっているメンバーを手伝うなどの動きはチームワークを発揮するために重要だが、フィードバックがなければ継続する気力がなくなっていく。チームワークを支える行動にフィードバックを与えるには、感謝を見える化するプラクティスが有効KPTに感謝という軸を加え、Tryを決めた後に最後にチームメンバーへの感謝を示すアクティビティをすると良い。チーム内に互いを尊重し称え合う文化も醸成されていく

 

プロセスのカイゼン

  • プロセスの無駄を見える化するためには、バリューストリームマッピングが有効。開発が始まってからユーザーに届くまでのプロセスを全て洗い出すことで、待ち時間が多いところや、手戻りが発生しやすい箇所が見つけられる

 

その他覚えておきたいこと

  • DX(デジタルトランスフォーメーション)とは、ITを道具として活用するだけでなく、ITによりビジネスや生活を変革させていくこと。これまでのITとビジネスの関係は、もともと人間が行なっていたことをITで置き換えることだが、DXが実現するのはITを前提とした新しいプロセスやビジネス
    • 例:音楽ストリーミングサービス
  • 仮説を検証するための、価値を提供できる実用的で最小限のプロダクトのことをMVP(Minimum Viable Product、Viable: 実行可能な)という
  • モブプロなどの1人でできることを全員でやったら時間が無駄なのではないか?への回答
    • 隙間時間があって時間を無駄にしていることを懸念するよりも、価値が早く顧客の手に届く流れの効率を大切にしている人がフル稼働することよりも、開発された成果物を重視している。リリースすることで顧客が利用可能になり、使われて初めて価値が生まれる
  • プロダクトバックログの開発可能チェックリスト
    • スプリント内で開発着手できる具体的な情報がある
    • 顧客に価値がある根拠や仮説がある
    • 優先順位で並べ替えられている
    • スプリントで開発可能な大きさに分解されている
    • 見積もられている
    • テスト可能な受け入れ条件がある

 

おわりに

ここまでお読みいただきありがとうございます。

本書の中では図がたくさん使われており、アジャイル開発の考え方がとても理解しやすかったの、ご興味ある方は是非読んでみてください。

 

以下の関連記事を合わせて読むことでアジャイル開発、アジャイル開発の1つであるスクラムについての理解がさらに深まると思うので、ご興味ある方は是非ご覧ください。

ysk-pro.hatenablog.com

ysk-pro.hatenablog.com

ysk-pro.hatenablog.com