※ 本記事は予約投稿です。
こんにちは、虎の穴ラボのnsdです。
この記事は「虎の穴ラボ Advent Calendar 2022」10日目の記事です。
9日目はY.K.さんによる「Go言語で書いたコマンドラインツールをGitHub Actionsでビルドしてみる」が投稿されました。
11日目はT.M.さんによる「AWSのコンテナツール、Finchを動かしてみる」が投稿されます。
こちらもぜひご覧ください。
■はじめに
2022年もそろそろ終わりますが、皆様はどのようなスキルアップや自己研鑽の年でしたでしょうか？
自分としてはアジャイルやスクラムを勉強したり実践したり、時にはそれらを元に発表したりとそんな1年でした。
今回はそんな1年の締めくくりとして、今まで目を通してきた基礎的な参考書から1歩ステップアップして少し実践に近づいた参考書を読んだので内容や気になったポイントを紹介したいと思います。
■書籍情報
- 誰も教えてくれなかったアジャイル開発
- 著者：堀 哲也、稲荷 裕、木村 秀顕、柴㟢 秀算、廣瀬 志保、石橋 正裕 bookplus.nikkei.com
■どんな本？
ビジネスコンサルティングを手がけている筆者の方々による、ウォーターフォール型開発で情報システムを構築してきた企業向けに、アジャイル開発の方法をコンサルタントしてきた経験を体系化したもの。
特に、アジャイル開発の経験が少なく、中央集権型の日本企業において、アジャイル開発を成功させるにはどうすればいいのか、その事例などが記載されています。
■構成
基礎編
アジャイル開発の最初に押さえるべき5つの要点を解説。「らしさ」にとらわれないアジャイル開発の立ち上げ方や、成長し続けるアジャイルチームのつくり方などを解説
実践編
アジャイル開発の成否を左右する「企画」工程や「初期計画」の具体的な進め方や、アジャイル開発に欠かせない5つの定期イベントの取り回し方などを現場のノウハウをベースに説明
応用編
アジャイル開発とウオーターフォール型開発を「ハイブリッド」で進める方法や、ローコード開発やSaaS導入でアジャイル開発をどう生かすかなど、一歩進んだアジャイル開発を紹介
■気になったポイント（アジャイル開発を企業に取り入れる）
①組織・文化はそのままで問題なし
冒頭で紹介した通り、本書ではウォーターフォール型開発を行ってきた企業へアジャイル開発の方法を紹介した経験を基にしています。
そのため、アジャイル開発に慣れていない日本企業のIT部門向けに組織や文化を変革せずにアジャイル開発を成功させるノウハウが紹介されています。
②教科書通りは存在しない
日本企業で「成功するアジャイル開発」を行う要素の1つとして、教科書通りに実践するのではなく企業の組織や文化の変革を踏まえたうえで柔軟にアジャイル開発を取り入れることを提案しています。
これは、アジャイル開発手法の中ではスクラム開発が最も多く採用されていますが、スクラム開発はアメリカの雇用形態やソフト開発事情を前提としているため、日本企業に取り入れる際に敬遠されることが多いためです。
■気になったポイント（アジャイル開発を定着させるために）
③まずは小さい成功事例を作る
日本企業でアジャイル開発やスクラム開発が敬遠される理由の1つとして、日本企業の多くは中央集権的組織で、上からの指示で現場が動くケースが多いことに由来があります。
アジャイル開発ではチームが自律的に活動するため上からは「チームが何をしているのか分からない」とみなされてしまうためです。
その解決策として、筆者は小さいことで良いので社内でアジャイル開発を成功させて、それを積み重ねることでアジャイル開発を定着させることを提案しています。
④スクラムではなくともアジャイルできる
スクラムの教科書である「スクラムガイド」ではプロダクトオーナーとスクラムマスターと開発チームの3つを必要としていますが、アジャイル経験が少なく中央集権的な組織ではそれらの役割を持つ人材を揃えることが難しくなります。
そのため、プロダクトオーナーを支援する代理プロダクトオーナーとスクラムマスターの代わりに開発リーダーを配置する構成を提案しています。
代理プロダクトオーナー
- プロダクトオーナーの手が回らない作業を補佐
- アジャイルチームとステークホルダーのコミュニケーションや調整
- アジャイル手法に基づくチームマネジメント
開発リーダー
- 開発メンバーへのタスク割り当て
- 開発メンバーの積極的フォロー
- 開発環境の整備
- 開発チームの生産性向上支援
■気になったポイント（アジャイル開発を実践する中で）
⑤優先させるのはバグ対応か新機能か？
アジャイル開発はリリースがゴールではなく、リリース後もバグの修正、機能改善、新規機能の開発を続けることとなりますが、限られた工数の中で最大限の価値を生み出すためには無条件にバグの修正を優先するのではなく、これらを同じ基準の土俵に上げたうえで優先順位を決める必要があります。
その際に使用するのが業務への影響度と対応工数による以下のような2軸のマトリクスとなります。
（つまり、業務に支障があるものは最優先で対応を行い、誤字など改修効果が小さいものは優先度が低くなります）
⑥ペア設計で新メンバーを増やす
アジャイル開発はドキュメントが少なく、新メンバーが開発内容や規約を理解するのに時間がかかってしまう場合があります。
そこでペアプログラミングならぬ「ペア設計」として、既存メンバーとともに設計作業を行ってもらうことで開発の進め方、既存資料の見方、具体的な設計手法、業務内容の把握をしてもらう方法です。
■まとめ
「アジャイル開発はこうである」というものではなく、それを踏まえて企業に導入するにはどうするのかを説明した一冊でした。
虎の穴ラボは開発部隊として独立しているため社内ではアジャイル開発は理解されていますが、とらのあな全体でみるとまだまだアジャイル開発が浸透しているわけではありません。
そんな中で他の部署と共にシステム開発を行っていくうえで参考にしていきたいと思います。
これからIT部門にアジャイル開発を導入したいという方々も参考にしてみてはいかがでしょうか。
P.S.
採用
虎の穴では一緒に働く仲間を絶賛募集中です！
この記事を読んで、興味を持っていただけた方はぜひ弊社の採用情報をご覧下さい。
yumenosora.co.jp
LINE スタンプ
エンジニア専用のメイドちゃんスタンプが完成しました！
「あの場面」で思わず使いたくなるようなスタンプから、日常で役立つスタンプを合計 40 個用意しました。
エンジニアの皆さん、エンジニアでない方もぜひスタンプを確認してみてください。
store.line.me
