グローバルリソースによるアジャイル的柔軟性開発ソリューション紹介
背景
１ー１．システム開発の現状と課題の弊社認識
■ システムの開発の現状
◆ システム改善〜リリースの期間短縮が必要
- 外部環境変化が激しくなり、それに追従するため、 SoEだけでなく基幹システム (SoR）への改善・リリース期間も短縮が必要となっている。
◆ 開発リソース不足
- 日本国内においては慢性的な開発リソース不足のため、開発人材調達難となっている。
■ 課題
◆ 日本国内のリソース不足問題を解決しつつ、お客様の置かれている情勢の変化の速度に追随できる、柔軟性のある開発スキームと体制が求められている。
この課題に対する弊社のソリューション
■ グローバルリソースによるアジャイル的柔軟性開発ソリューション
◆ ビジネス状況の変化に迅速に対応するには、柔軟性をもった開発プロセスが必要。
◆ 手戻り削減に向けてアジャイル開発プロセスが注目されているが、開発システムの種類・仕様の決定度合いによっては、短期ウォーターフォールのほうが適している場合もある。
➡ アジャイル的柔軟性開発
-「アジャイル開発・短期ウォーターフォール開発」の総称
◆ NSSOLグループでは、日本国内のIT技術者リソース不足問題に対応できるよう、中国拠点において、上記開発に対応できる環境およびハイスキルな技術者を育成
➡ グローバルリソース
リモートアジャイルチーム紹介
2-1. 保有技術
2-2. アジャイル開発プロセス
2-3. 品質確保
■ フロント・バックエンドコードの品質対策
SonarQubeでルール指定できるように自動チェックしている。
■ テスト自動化
・ Junit + Mockitoでクラスの単体テスト
・ Junit + MockMVCでREST APIのIF業務テスト
■ フロント・バックエンドコード品質対策： SonarQube
■ フロント・バックエンドコード品質対策： ルール（拡張可）
■ テスト自動化：Junit + Mockito
２ー４．マイクロサービス
■ ある発注管理案件のマイクロサービス環境
リモートアジャイル開発事例
３ー１．事例１
■ 案件内容：省略
■ 開発環境：AWS
■ 利用コミュニケーションツール：Miro、Teams
■ 役割分担：
・ 日本側：PO
・ 中国軟件：CM（コミュニケーションマネジャ）、SM、Dev
▼ 日本側の実施作業
日本側で実施する事項は以下のみ
・ プロダクトバックログの作成
・ スプリント計画への参加
・ スプリントレビューへの参加
・ 要望についての確認や質問のチャット回答
※発注元から、プログラム設計について細かな指示をしなくても、プロダクトバッグログに書かれた目的を実現する機能を開発した。
実行したスクラムイベント・アクティビティ
スプリントイベント実施タイミングと、スプリント内で実施していた活動は以下の通り。
■ スプリントレビュー、スプリントプランニング※
→ 日本側のPO、関係者が参加してそのスプリント開始時のプランニングで決めた内容が満たされているかレビューを実施する。
→ プランニングでは、そのスプリントで満たしてほしい要望がPOから共有される。
※スプリント3以降、次のスプリントのプランニングは金曜日のレビュー後に実施。
両方合わせても30分以内で実施完了。
■ デイリースクラム
→ オフショア側で毎日10-15程度の打合せを実施し、その日の取り組み内容について認識合わせを行う。
実施詳細：オフショア側の取り組み
オフショア側でフォーカスした意識ポイントと取り組みは以下の通りである。
【ポイント１】
・ プロダクトバックログの記載情報のみでも要望通りの画面が作成できること。
設計フェーズの実施や設計書を作成せず、端的な記載のみ。
① 最初に、POと業務理解についての認識合わせを行う。
② 静止画のイメージで認識を合わせた後に、画面開発作業を行う。
③ 画面レイアウトをPOに確認してから、バックエンドの開発を進めていく。
【ポイント２】
・スクラムイベント以外に会議を設けなくても認識齟齬が生まれないこと。
① 各画面に対しての確認ポイントを頻繁に設ける。（レビューを待たず、できた部分からこまめに確認依頼をする。）
② 疑問点をスクラムイベントまで溜めずに、チャットで都度確認する。
【ポイント３】
・発注元の対応工数に負荷をかけずに案件実施できること。
① レビューを迅速に進行するため、あらかじめ動作環境を用意しておく。
② スクラムイベントの議題を円滑に進めるため、事前にオフショア内部で内容詳細を確認し、
内部で重要度の整理や策案を行ったうえでPOと会話する。
３ー２．事例２
■ 案件内容：省略
■ 開発環境：AWS
■ 利用コミュニケーションツール：Miro、Teams
■ 役割分担：
・ 日本側：PO
・ 中国軟件：CM（コミュニケーションマネジャ）、SM、Dev
▼ 日本側の実施作業とオフショア側の取り組みは事例１と同じく、一部機能は日本側まだイメージつけられていなくて、オフショア側柔軟な提案を行いながら、開発を進めていた。
実施詳細：オフショア側の取り組み
オフショア側で加えた意識ポイントと取り組みは以下の通りである。
【ポイント１】
・ 実業務での利用シーンが考慮されたユーザビリティの高いUIの提案をすること。
オフショア側で業務知見者を立てて検討。
① 最初に、業務背景の理解を行う。
② 背景理解を行ったうえで、業務知見者が主体となってユーザニーズを議論し提案を行う。
【ポイント２】
・ 発注元の対応工数に負荷をかけずに案件実施できること。
対応工数0.1以下での実施を想定。日本側にも業務知見者はおらず、プロダクトバックログも詳細は未記載。
① 業務検討をPOとオフショア側の業務知見者を交えて実施する。
② プロダクトの具体的な検討をオフショア側で行い、POへ提案する形式を実施する。
実施詳細：提案の採用
オフショア側から以下の提案があり、オフショア案を採用している。
・ 「工数の一覧を閲覧できる」にグラフ表示を追加する
→識別性や直感的なボリューム感を考慮した見え方の提案
・ 「工数実績を入力できる」を月単位で画面切り替え可能とする
・ 「工数実績を入力できる」をプロジェクト種別ごとに一覧表示する
・ 「プロジェクト新規登録」機能の画面を二段階に分けて登録できる
→実ユーザの使いやすさを考慮した登録方法の提案
３ー３．事例1, 2 での発注元からの評価
発注元からの評価
①開発中のコミニケションギャップの有無
多少発生した
→多少意味が通じず確認のチャットをする場面はあった。
→依頼が長文になると理解できない旨の返事が来ることもあったが、短文に分けると同じく解消できていた。②認識齟齬の解消までの期間
早く解消できている
→明瞭短文かつ、細かい単位に分割されたPBIを利用するため、誤認が起こりにくい。
→こまめな確認ポイントを頻繁に設けることで、常に認識を修正しており、齟齬が起こりにくい。
→１度だけ、要望にそぐわないものが作成されたが、次のスプリント内（5日以内）に解消された。
③短サイクル開発の実現
短サイクルでの提供が可能だと言える
→開始3日後にまず静止の一覧画面が提示され、その後週平均７つずつの機能が提供された。
→レビューを待たずに作成された機能の確認依頼がくるため、実質機能の提供には5日も必要としなかった。④要望変更に対する柔軟性
柔軟な対応ができている
→開発者が承認権限のある人物と直接会話ができていたため意思決定がはやい。
→変更管理記録をとるためのドキュメント更新や複雑な承認フローがないため、変更を即反映できる。
⑤活動の自主性/積極性
十分に発揮できている
→要望に対して開発メンバーが背景・目的を踏まえてどう実現していくのか設計を含め、取り組みを決めていた。
→独自で工夫するポイントを設定し、それに応じた取り組みが見られた。
お問い合わせとご相談は下記の方法でご連絡ください。
連絡先：021-64739299
e-mai：info.hp@cn.nssol.nipponsteel.com
