はじめに
現場での仕事にガムシャラに向き合ってきた20才台を卒業して、
エンジニアとしてアウトプットをして世に貢献していける30才台を目指す、
とあるSIerのSEによる備忘録の第一号記事です。
スクラムの知識を前提としますので、意味のわからない単語がたくさん出てくる方は
アジャイルでやってみた。とかカイゼン・ジャーニーあたりが読みやすかったです。
初版：2018/08/05
最終更新：2018/09/09
目次
- 登場人物や最初に安定した役割分担：本記事
- 初回リリースに向けた取組：こちらの記事へ
登場人物
ユーザー企業
- プロジェクト責任者
- コア業務の計算ライブラリ開発者
- 一般ユーザ
ベンダー
- ITコンサルタント
- コア業務の知見者
- アジャイル開発経験のない本件業務システムの開発者
採用技術要素
対応ブラウザ
- Chrome
- 将来的にEdge移行要件有
フロントエンド
- AngularJS
- Wijmo
バックエンド
- C#
- ASP.NET WebAPI
- AutoMapper
- EntiryFramework(Code First)
- OracleDB
その他
- SignalR(WebSochet)
開発ツール
- Visual Studio
- Visual Studio Code
- Team Foundation Server
- NUnit
- Redmine
- Jenkins
最初に安定した役割分担
大コケしない程度の安定感を持ってスプリントを回せるようになった、
最初の役割分担をまず書いておきます。
一般的なウォーターフォールやスクラムのあるべきからはほど遠い上に、
まだまだ課題のある状態である点はご留意ください。
本件業務システムのシステム要件定義での業務知見の要求が高いため、
業務知見のある人間による「要件具体化」（要件定義、基本設計の大部分に相当）と、
「開発」（基本設計の一部、詳細設計、実装、クラス単体テスト、動作確認）と、
「テスト」（結合テスト、非機能要件テスト、総合テスト）との、
3つに役割を分離しています。
開発手法も分離した体制毎に異なり、
「要件具体化」は超簡易スクラム（ストーリーポイントは振らずバックログ運用のみ）、
「開発」はスクラム（ストーリーポイントとベロシティによる管理）、
「テスト」はウォーターフォール（WBSによる管理）、
というように三者三様です。
※要件具体化は事前見積が非常に難しくストーリーポイントが機能しなかったため中途半端
プロダクトオーナー
ユーザー企業のプロジェクト責任者が担当。
- プロダクトバックログ（要件具体化/開発）の優先順位の決定
- プロダクトバックログ（要件具体化/開発）からスプリントバックログ（要件具体化/開発）の決定
- プロダクトバックログ（要件具体化/開発）の受入判定
- リリーススプリントの決定
- テスト計画の承認
- エンドユーザー向け本件業務システム利用方法の説明、横断的なニーズヒアリングの企画、実施
スクラムマスター
ベンダー開発者のうちマネジメント適性の高いメンバーが担当。
- スプリントプランニング（開発）、デイリースクラム、スプリントレビュー（開発）、スプリントレトロスペクティブの司会進行
- バーンダウンチャート、カンバン、デイリースクラムでのコミュニケーションロスの検知、解消
- 技術的な課題解消の支援
- プロジェクト推進上の課題解消の支援
- 開発環境の維持メンテナンス
スーパーサブ
ベンダーのITコンサルタントが担当。
- プロダクトバックログ（要件具体化/開発）の起票
- スプリントバックログ（要件具体化/開発）の優先順位案の作成
- プロダクトバックログに対する要件具体化/開発チーム、プロダクトオーナーとのコミュニケーションハブ
- プロダクトバックログ（開発）に対するストーリーポイント見積の司会進行
- プロジェクト推進上の課題解消の主体
要件具体化チーム
ベンダーのコア業務知見者が担当。
- スプリントバックログ（要件具体化）の消化
- エンドユーザーの一部との要件検討ミーティングの企画、実施
- ユーザー企業のコア業務の計算ライブラリ開発者と開発チームとのコミュニケーションハブ
- スプリントプランニング（要件具体化）、スプリントレビュー（要件具体化）の司会進行 ※ベンダー
開発チーム
ベンダーの残りメンバーが担当。
- スプリントバックログ（開発）の消化
- プロダクトバックログ（開発）に対するストーリーポイント見積
- 技術的な課題解消の推進
テストチーム
この時はまだ編成されておらず。
後にテストエンジニアが担当。
役割分担の変遷
ここからがやっと本題で、これを書かないと歪な役割分担の意図が見えないのですが、
第一号はここまでとします。（2018/08/05）
きっと続きます！
編集後記
こうしてアウトプットしようと書いていると、改善点や、人が変わるとこの体制ではうまくいかないよなという、
当たり前のことがよく実感できます。
週末開発のがっつりプログラミングの記事も書けるようにがんばろう！