エンタープライズにおける開発ツールの導入と活用推進

Copyright© Growth xPartners, Inc. All rights reserved.
エンタープライズにおける
開発ツールの導入と活用推進
グロースエクスパートナーズ株式会社
執行役員鈴木雄介
2016/2/16
エンタープライズにおけるアトラシアン製品の導入の進め方
～アトラシアン社の製品活用方法と日本の現実とギャップ～

アジェンダ
• 開発支援ツール
• ツール利用レベル
• ツールの運営
• アトラシアン製品
• まとめ
1

開発支援ツールとは
2

• 開発プロセスの様々な工程利用するツール
• 目的：
–チーム内での情報の共有
–トレーサビリティ（現状と経緯）の把握
–自動化（効率化とミス抑止）
• 対象物：
–開発資産（ソースコード、設計書など）
–課題（検討事項、バグなど）
–タスク（作業など）
–構成（環境構築、リリース手順、インフラなど）
3

• 目的と対象物のマトリクス
4
対象物／目的情報共有履歴管理自動化
開発資産ソースコードや設計書
の最新版を共有する
ソースコードや設計書
の変更履歴を管理する
ー
課題発見された課題の内容
や状況を共有する
課題の担当者や状況の
履歴を管理する
課題の発生や解決状況
レポート作成を自動化
する
タスクスケジュールや進捗状
況を共有する
スケジュールや進捗の
変更履歴を管理する
ー
構成環境構築手順、リリー
ス手順などを共有する
手順書の変更履歴を管
理する
環境構築やモジュール
作成・配備を自動化す
る

• ドキュメント管理
– Wiki：Wiki、Confluene(※）
• ソースコード管理
– 並行バージョン管理：CVS
– 分散バージョン管理：Git、Bitbucket (※）
• 課題管理/バグ管理
– Redmine、Trac、JIRA (※）
• タスク管理
– WBS：MS Project
– チケット管理：Redmine、Trac、JIRA (※）
• 構成管理
– ソフトウェア構成管理：Ant、Maven
– CI（リリースプロセス管理）：Jenkins、Bamboo (※）
5
※：アトラシアン製品

開発支援ツールと開発手法
6

開発支援ツールと開発手法
• 開発支援ツールは開発手法に関係なく有用
–ただし、向き不向きはある
• プロジェクト型とプロダクト型
–プロジェクト：ゴールを定めた終わりのある活動
–プロダクト：プロダクトが存続する限り続く活動
• プロダクト型の開発が増えてきている
–お客様や取引先との関係性を強化するシステム
–ともかくスピードが重要
7

開発マネジメント
• マネジメントの基本
–計画：タスクを積む
–実行：タスクに沿って作業を実施する
–計測：計画と実行の誤差を確認する
–調整：誤差を修正する
※計画できないことはリスク（不確定要素）管理
• 大きく分けると計画重視と調整重視
8

• ウォーターフォール型（計画重視）
–計画：全体を計画する
–計測：計画と実行との差異を把握
–調整：差異への対応
• ポイント
–長期でタスクが洗い出されるため、それに最適化さ
れたリソース調達ができる
–ただし、計画精度が悪いと調整の限界を超えてしま
い、破たんする
9

• アジャイル型（調整重視）
–計画：短い期限を設定する
–計測：動くソフトウェアで計測
–調整：定期的に関係者で計画見直し
• ポイント
–リソースを固定し、短期＋定期の計画を繰り返すこ
とで継続的な開発を可能にする
–ただし、長期計画との齟齬が発生すると破たんする
10

• どちらが良いか？ではなく、全てのシステム開
発には両方の要素がある
–ウォーターフォール型のシステムでも、技術調査な
どは必要
–アジャイル型のシステムでも、基幹系システムとの
連携は必要
11

開発支援ツールの活用
12

• マネジメント手法に関わらず管理対象は同じ
–開発資産（ソースコード、設計書など）
–課題（検討事項、バグなど）
–構成（リリース手順、インフラなど）
• ただし、管理の考え方は違う
–ウォーターフォール：計画ありき
–アジャイル：時間制限ありき
13

• 開発資産
–ソースコードやドキュメントの履歴管理は必須
–図表は常に悩ましい
» Wiki＋描画ツールでもできないことはないが便利ではない
• 課題
–課題＝発生する度に対応を考えるもの
» ウォーターフォールにおける「バグ」や「リスク要素」
» アジャイルでは「タスク」が課題的に扱う
14

• タスク
–長期での全体感：WBS＋ガントチャート
» 時間軸の前後関係や重複が分かりやすい
–短期での全体感：チケット＋カンバン
» タスクの状況が分かりやすい
• 構成
–頻繁にリリースするほど自動化重要
–マージは、常に重要
15

例の最強ツールについて
16

EXCELについて
• 最強のツール「Excel」
17
対象物／目的情報共有履歴管理自動化
開発資産ソースコードや設計書
の最新版を共有する
ソースコードや設計書
の変更履歴を管理する
ー
課題発見された課題の内容
や状況を共有する
課題の担当者や状況の
履歴を管理する
課題の発生や解決状況
レポート作成を自動化
する
タスクスケジュールや進捗状
況を共有する
スケジュールや進捗の
変更履歴を管理する
ー
構成環境構築手順、リリー
ス手順などを共有する
手順書の変更履歴を管
理する
環境構築やモジュール
作成・配備を自動化す
る
けっこう、色々できる

EXCELについて
• 最強のツール「Excel」の課題
–情報がスナップショット
» 情報収集して記載することになるので、情報共有がリアル
タイムにならない
–手間がかかる
» 管理のための運用が人手になるため、ルールの周知やPMの
手間が上がりがち
• ようは使い分け
–報告のためにEXCEL表を出すのは悪くない
18

ツール利用レベル
19

• レベルの指標
–利用ツール：どのツールを使っているか
–トレース範囲：ツールをまたがったトレース範囲
• トレーサビリティについて
–いつ発生した課題が、いつ誰が実装されて、いつど
こにリリースされたかを自動的に把握する
20

• レベル0
–ツールはほとんど利用していない
» ※EXCELは対象外
–利用していてもチームでは共有できていない
» 一人が集中管理をしており、全員に配っている
21
開発資産
課題
タスク
構成
情報の共有 × × × ×
トレーサビリティ × × × ×
自動化 × × × ×

• レベル1
–ソースコード管理、バグ管理は導入され情報共有が
できている
» ドキュメント管理はEXCELをバージョン管理
–タスク管理は中央集権
» タスクのステータスや時間を個別入力はできていない
–ビルドスクリプトを手動実行している
» ビルドから先のリリースは自動化されていない
–トレーサビリティが確保されていない
» いつ発生したバグが、いつ誰が実装されて、いつどこにリ
リースされたかが明確には分からない
22
開発資産
課題
タスク
構成
情報の共有 ○ ○ △ △
トレーサビリティ × × × ×
自動化 ○ ○ △ △

• レベル2
–バグやタスクとソースコードやリリースバージョン
は関連づけられている
–ドキュメントも一部はWikiで管理
–CIツールが導入され、リリースは自動化されている
–開発チーム内では情報が共有化されている
» 運用チームとの情報共有が不十分
23
開発資産
課題
タスク
構成
情報の共有 ○ ○ △ ○
トレーサビリティ ○ ○ △ △
自動化 ○ ○ △ ○

• レベル3
–課題発生からサービス提供までがトレース、かつ、
運営側にも情報が共有されている
» 開発視点：いつ発生した課題が、いつ誰によって実装され
、どのバージョンに含まれて、いつどのサーバにデプロイ
されたか
» 運営視点：このサーバには、どのバージョンがデプロイさ
れ、そのバージョンでは、どの課題が、いつ誰によって実
装されて、いつリリースされたかが自動的に把握する
–DevOps/OpsDevが実現されている
24
開発資産
課題
タスク
構成
情報の共有 ○ ○ ○ ○
トレーサビリティ ○ ○ ○ ○
自動化 ○ ○ ○ ○

• ポイントは、それぞれの範囲
–情報共有
» 個人→開発チーム→開発と運用
–トレース
» なし→課題とコード→課題とコードとバージョン→課題と
コードとバージョンとデプロイ
–自動化：
» なし→スクリプト化→自動運行
25

• ステップバイステップ
–レベル0→レベル1
» 最適はバグ管理とソースコード管理から
▸ タスク管理はWBSでOK
» バグとバージョンへの紐付け
» タスクからコードやバージョンへの紐付け
» Wikiの導入（内部手順書から）
» CIツールの導入（まずはボタン1つ）
» タスクからデプロイまでの一括管理
26

• ステップバイステップ
27
運営
運用テスト
結合テスト
企画
検討
外部設計
内部設計
実装
ユニット
テスト
内部テスト
レベル1
レベル2
レベル3

ツールの運営
28

ツールの運営
• ツールは設定＆改善が重要
–ツールを置くだけではうまくいかない
–設定して、ルールを適用して使ってもらう
–改善して、使いこなしていく
• 問題になりがちなところ
–初期構築における問題
–横展開における問題
29

ツールの運営
• 初期構築における問題 1/2
–初期にどこまでやるのか
» まずは適用範囲とフローのルール決め
» 最初は設定しすぎず、継続的に改善を行うほうがよい
▸ フローの最初と最後を誰が、いつ行うのかが重要
–設定を開発チームの誰かが兼任するのは危険
» 「誰か」しかわからないブラックボックスに
» 大規模プロジェクトであれば「専任」が必要
30

ツールの運営
• 初期構築における問題 2/2
–作りこんだ品質管理ツールの代替とはならない
» WF的な管理要素をアジャイルツールには期待しない
» EXCELダウンロード＋加工で提出資料にはなる
31

ツールの運営
• 横展開における問題 1/2
–推進者を明確にする
» 「Aさん」では破たんする
» 事務局の創設や推進メンバーの指名などが必要
–教育の実施
» 管理者と利用者向けのマニュアル整備
» 利用者は「読まなくても分かる」ようにしていく
32

ツールの運営
• 横展開における問題 2/2
–PJ個別のカスタマイズの管理
» 他のPJに影響を出さないような範囲を決める
–メンバー追加・変更の管理
» 特に権限管理が重要（参照、書き込み、削除など）
» 内部統制対応の申請書管理（特に退社の扱い）
33

アトラシアン製品
34

• レベルを上げていくのは、レベルアップを想定
したツール群の導入が推奨
–Redmine+Git+Jenkinsでもいいけど…
–アトラシアン製品なら、最初から統合前提
» 課題/タスク：JIRA Software
» ドキュメント：Confluence
» ソースコード：Bitbucket（Git）
» CI：Bamboo
35

• 製品サイクル
36
課題ソースコードモジュール実行環境
v1 済
☑タスクA
☑タスクB
v2 未
☑タスクC
☑タスクD
□タスクE
残
□タスクF
□タスクG
□タスクH
v1
v2.b2
v1
v2.
b1
v2.
b2
☑タスクA
☑タスクB
☑タスクC
☑タスクD
☑タスクC
本番
受入T
開発
検証
v2.b1

• 利用者へのメリット
–分かりやすい見た目
» とっつきやすく、分かりやすい用語
–柔軟なワークフロー、権限管理
» 設定しすぎ注意
–アジャイルネイティブ
» スクラムに合わせたツール
37

• 運用者へのメリット
–充実した管理ツール
» 命名規約さえあれば、比較的引継ぎが容易
–ツール間の安定した統合
» バージョンアップで苦労しない
–エンタープライズ・サポート
» 相談できる人がいる
38

まとめ
39

まとめ
• 開発支援ツールは開発手法に関係なく利用可能
–目的：情報共有、履歴管理、自動化
–対象：開発資産、課題、タスク、構成
• ウォーターフォールとアジャイル
–計画重視：タスクを中心に管理する
–調整重視：時間を中心に管理する
–PJの中で、うまく使い分ける
» ツールの使い分けていい
40

まとめ
• ツールの利用レベル
–Lv0:ツールは使わず、共有はフォルダ管理
–Lv1:ソースコードやバグ管理はできているが、トレ
ーサビリティが弱い
–Lv2:バージョンによってタスク・課題、コードが連
携している
–Lv3:開発と運用で情報やプロセスが共有されている
• 段階的に拡張すればいい
41

まとめ
• ツール運営の問題
–初期構築における課題
» 初期設定と段階的な改善のバランス
» ブラックボックスにしない
–横展開における課題
» 組織的な取組みにするときの注意点
» 事務局：教育、カスタマイズ、権限など
42

まとめ
• アトラシアン製品のメリット
–利用者
» 使いやすく、分かりやすい
» アジャイルを始めるには最適
–運用者
» 管理が楽、管理が楽、管理が楽
43

エンタープライズにおける開発ツールの導入と活用推進

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Semelhante a エンタープライズにおける開発ツールの導入と活用推進

Semelhante a エンタープライズにおける開発ツールの導入と活用推進 (20)

Mais de グロースエクスパートナーズ株式会社/Growth xPartners Incorporated.

Mais de グロースエクスパートナーズ株式会社/Growth xPartners Incorporated. (8)

エンタープライズにおける開発ツールの導入と活用推進