2013年3月23日（土）に開催されたGxPセミナーでの講演内容です。

1. サステイナブルなSIを実現する
開発基盤のあり方
鈴木雄介
グロースエクスパートナーズ株式会社
執行役員/BS事業本部長

2. 自己紹介
• 鈴木雄介
– グロースエクスパートナーズ株式会社
• 執行役員／ビジネスソリューション事業本部長
– コミュニティ
• 日本Javaユーザーグループ 会長
• 日本Springユーザーグループ 幹事
– ソーシャル
• http://arclamp.hatenablog.com/
• https://twitter.com/yusuke_arclamp

3. アジェンダ
• サステイナブルなSIを実現する
開発基盤のあり方
– SIの現在と未来
– では、どうするか
– これからのSI
– サステイナブルなSIを目指して
– 開発環境
– GxPでのチケット駆動開発
– まとめ

4. SIの現在と未来

5. SIの現在と未来
• SIはオワコンなのか？
– 内部要因：ダメなSIerはダメ
• ITゼネコン、多重請負構造、丸投げ…
• 工程分断による技術力の空洞化現象
• 構造的な課題は続く
– 大規模マネジメント重視世代と中小規模技術重視世代の
ギャップは10年続く

6. SIの現在と未来
<平成１７年特定サービス産業実態調査報告書>
情報サービス業 年次別の事業所数、就業者数、従業者数及び年間売上高
16,000,000 600,000
14,000,000
情報サービス業 500,000
従業員数 PMBOKガイド出版
12,000,000
400,000
10,000,000
8,000,000 300,000
6,000,000
200,000
4,000,000
100,000
2,000,000
第三次
オンライン
0 0
1973
1974
1975
1976
1977
1978
1979
1980
1981
1982
1983
1984
1985
1986
1987
1988
1989
1990
1991
1992
1993
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
年

7. SIの現在と未来
<平成２４年特定サービス産業動態統計調査>
情報サービス業の業務種類別売上高、事業所数及び常用従業者数
9,000,000 300,000
ソフトウェア開発
8,000,000
内、受注ソフトウェア
250,000
7,000,000 内、SI
従業員数（技術者のみ）
6,000,000 200,000
5,000,000
埋められないギャップ
150,000
4,000,000
3,000,000 100,000
2,000,000
50,000
1,000,000
0 0
2001年
2004年
1988年
1989年
1990年
1991年
1992年
1993年
1994年
1995年
1996年
1997年
1998年
1999年
2000年
2002年
2003年
2005年
2006年
2007年
2008年
2009年
2010年

8. SIの現在と未来
• SIはオワコンなのか？
– 環境要因：ITサービス産業の米国化は進む
• IT戦略を重視するユーザー企業で内製化が促進
• クラウド活用
– 内製化ができない中小企業、新規事業など
• 技術の標準化
– 人材流動性の向上、ベンダーロックインの回避
• オフショアの促進
– 単純作業の外部化、保守のアウトソース

9. SIの現在と未来
IPA「グローバル化を支えるIT人材確保・育成施策に関する調査」調査結果
米国は1:3
日本は3:1

10. SIの現在と未来
• SIはオワコンなのか？
– 労働環境の違いで米国ほど内製化は進まない
• ロールベースではない仕事、雇用制度の制約
– 今後もユーザー企業はITリソースの外部依存
を続ける（縮小はする）
• 準委任は柔軟性に欠けるため受託請負もあり
– 転職率が低いためSIerが業界や企業を跨がっ
たノウハウ共有の枠組みとして機能している
のでは
• 今後もSIは必要な形態（少なくなるけ
ど）

11. では、どうするか

12. では、どうするか
• 僕のやりたいこと
– 社会で事業を営むユーザー企業にとってITは
ますます重要になる
• その中でSIは必要とされる形態であり続ける
– 「SIはオワコンだからエンジニアは逃げだそ
う」で良いのか？

13. では、どうするか
• 僕のやりたいこと
– SIという形態で様々な顧客を通じて社会とつ
ながる仕事がしたい
• 顧客を通じることで、自分でサービスを提供する
だけでは至れない場所に行ける

14. これからのSI

15. これからのSI
• SIの生き残り戦略
– ブティック型SIも1つの解決策
• 小規模で圧倒的な専門性を持つ
• クラウドエコノミクスの一員へ
– でも、もっと顧客の側（がわ/そば）にいるよ
うなスタイルを模索したい

16. これからのSI
• 顧客の側にいるために
– 「良いソフトウェアを作る」ことではなく
「価値あるITサービスを提供し続ける」こと
にコミットする
• 価値は顧客から見た価値（Value-in-Use）で測る。
売り手の価値（Value-in-Exchange）ではない
• 必ずしも”作る”ことにこだわらない

17. これからのSI
これまで：良いソフトウェアを作る
エンジニア 顧客
ｿﾌﾄｳｪｱ

18. これからのSI
これから：価値あるITサービスを提供し続ける
エンジニア 顧客
利用者
IT
ｿﾌﾄｳｪｱ ｻｰﾋﾞｽ

19. これからのSI
• “サステイナブルなSI”の定義
– ITサービスの継続的な提供を通じて、顧客が
持つ社会的価値を常に最大化することで、顧
客と持続可能な関係を結ぶSI/SIer
• ITサービス＝顧客、および顧客の顧客が利用者
• 継続的な提供＝環境変化への適応を含む
– サマリ：なくなったら困る人を増やす

20. これからのSI
• サステイナブルではないSI
– 価値をもたらさないと分かっているものを言
われた（＝仕様）通りに正しく作る
– 自分の成果物だけに興味を持つ
• 後工程なんて知らない
• 暗黒面に落ちると持続できない
– それって楽しいですか？社会的意義はあるん
ですか？

21. サステイナブルなSIを目指して

22. サステイナブルなSIを目指して
• 弊社の取り組みと実態の紹介
– GxP（Growth xPartners/グロースエクス
パートナーズ）
– 社名の由来は「顧客と共に成長するパート
ナー」
– 複数ユーザー企業の戦略的パートナーとして
ITサービスの提供を実施中
• 内製化、クラウド活用、技術標準化、オフショア
は大きなテーマ
http://www.gxp.co.jp

23. サステイナブルなSIを目指して
• Fact sheet
– 社員数：約80名（男6:女4）
– 平均年齢：35歳
– 受託のプライム率：98%
– 準委任率：15%以下
– 受注規模：5人日～300人月
– 売上上位3社の平均社歴：100年越え
http://www.gxp.co.jp

24. サステイナブルなSIを目指して
• どうしたらサステイナブルなITサービス
が提供できるのか
– これまで：ソフトウェア開発の視点
• アーキテクチャによる適応力の保持
• アジャイルなプロセス管理
– これから：＋ITサービス提供の視点
• では、良いITサービスとは何か？

25. サステイナブルなSIを目指して
• SERVQUAL
– Parasuraman, Zeithaml, and Berryが1988
年に発表したサービスの品質評価モデル
– コンセプト：顧客が期待していたサービスと、
提供されたサービスのギャップをいかに埋め
るか
– サービス品質の構成要素として5次元を定義
– 完璧ではないけど流用して考えてみる

26. サステイナブルなSIを目指して
• SERVQUAL
– サービス品質の構成要素
• Tangibles (有形性)：外見的な要素
• Reliability (信頼性)：一貫した品質
• Assurance (保証性)：きちんとしている
• Responsiveness(応答性)：迅速に答える
• Empathy(共感性)：「ぐっとくる」

27. サステイナブルなSIを目指して
構成要素 取り組み
Tangibles ITサービスとしての見た目。UI/UX、グラフィッ
(有形性) クデザインのきれいさ、IA（情報設計）
Reliability ITサービスの品質安定。ITIL（サービスサポート、
(信頼性) サービスデリバリ、サービス管理、アプリケーショ
ン管理、インフラ管理）
Assurance ITサービスの中身。ソフトウェア品質（外部品質
(保証性) ＞内部品質＞プロセス品質）、構成管理
Responsiveness サービス改善速度。CI/CD（継続的統合/継続的デ
(応答性) リバリー）
Empathy マインドセットとしての取り組み。「顧客と共に成
(共感性) 長するパートナー」であるための人事制度

28. サステイナブルなSIを目指して
• 本講演では取り組みの1つである開発環境
基盤の再整備を紹介
– Reliabilityとしてのインシデント管理
– Assuranceとしての構成管理
– ResponsivenessとしてのCI/CD
– など

29. 開発環境

30. 開発環境
• 現開発環境
– JIRA + Confluence ＋ SVN
• その昔、課題管理ツールが乱立していたのを標準
化するために構築
• 標準化で仕事のやり方が統一され人材流動性が高
まった
• JIRAは顧客とのコミュニケーション基盤としても
活躍中
• SVNは内向きと外向き（顧客共有用）を用意
• プロジェクトによってはJenkinsを利用

31. 開発環境
• 新開発環境の構成
– JIRA [継続] ：課題管理/BTS
• Bonfire：UIバグレポート
• GreenHopper：アジャイル管理
– Confluence [継続] ：Wiki
– Stash：Git（DVCS）
– Bamboo：CI
– Crowd：SSO

32. 開発環境
• 新開発環境の狙い
– メインはGit(Stash)とCI(Bamboo)
• Git：分散開発が増えた
– 顧客との協業開発 -> 内製化
– オフショア／二アショア -> オフショア
• CI：リリースサイクルを高速化にしたい
– ITサービスに対する変化要求が早い
• SSO：いろいろ導入した場合の管理コスト低減

33. 開発環境
• 当たり前ですみません
– Web業界から見たら「当たり前」
– SI/エンタープライズでも必要です
• セキュリティとガバナンスを気にしつつ維持コス
トを低減
– アトラシアンであればマルチプロジェクトでも管理が低
コストで実現できる
– トレーサビリティと自動化は歓迎

34. 開発環境
デモ

35. 開発環境
• でも、お高いんでしょう？
– 500ユーザーで約600万円（定価）
– 100ユーザーで約300万円（定価）
– 10ユーザーで7000円（定価）
– 2年以降は半額で保守更新
• 最新版の提供
• ソースコード公開
• QAインシデント
– 見積もりはこちらまで
• http://www.gxp.co.jp/atlassian/

36. GxPでのチケット駆動開発

37. GxPでのチケット駆動開発
• チケット駆動開発とは呼んでいない
– 2005年からJIRAを使っている中で自然発生
的に作られてきたプラクティス
– 色々な利用方法
• タスク管理、バグ管理、顧客QA管理、問い合わせ
管理
• 個別にテンプレートを用意して運用
– 顧客にも利用してもらう

38. GxPでのチケット駆動開発
全体の負荷を調整
負荷を見ながらタス
タスクを消化
クを割り当て
PM
リーダー 実装者
③割り当て Subversion
課題を登録し、対応が ④コミット
決定したら転記 コード
QA管理 ④完了報告
御社メンバー JIRA タスク
①記述 ②実装指示
課題 ⑤タグ設定
実装管理 ⑤バージョン設定
①記述
JIRA
課題番号 設計者 デプロイヤ
⑥バグ報告 完了タスクをバージョ
課題タイトル
⑤リリース ンにくくり、以下を実
内容 施する
⑥テスト 1.ソースコードの場
ジョン付与
検討履歴 テスタ アプリ 2.該当バージョンのア
検討履歴 アプリのバージョンを プリをリリース
検討履歴 元にしてバグを報告
QAも課題と同じように
JIRAで管理
※コミュニケーション管理計画として提出

39. GxPでのチケット駆動開発
• 記載ルール
– 記述内容
• 「現象」と「依頼」と「予想」を分けて記載
• 「現象」には環境、証拠、再現方法などを記載
• 言葉遣いは丁寧に…
• いわゆる「バグの書き方」と同じ
– プロセス
• 誰がクローズするのかが一番重要
– メンバーの教育も必要なので、初期段階では
チェッカーの運用が大事
• 抱えがちな人には棚卸しを定期的に促す
39

40. GxPでのチケット駆動開発
• コミュニケーションツールである
– 複数人で共有すべきものを対象にする
• 自分のTODOは共有JIRAで管理しない
– 「問い合わせ」で必ず課題を作ってもらう
• 電話や定例での依頼も必ず登録してもらう
– 定例前に棚卸して、定例でサマリ報告
• 日常はJIRAで視覚化されている
40

41. GxPでのチケット駆動開発
• 計画できるタスクはWBSへ
– 多くのタスクを「いつ誰がやるか」をがっつ
り管理するにはWBSのほうが便利
• 前後関係や依存関係が明確になる
• アジャイル的アプローチでは週間単位にしか調整
できない
• 小さなプロジェクトであればチケットでもいける
場合があるが事故につながることもある

42. GxPでのチケット駆動開発
• 計画できないタスクはチケットへ
– バグ/問い合わせ/QAなど、発生したことを追
跡するにはチケット
– 未来のことでも備忘録/TODO的なものはいれ
ていい
• ただし、迷子になることは多いので棚卸重要

43. GxPでのチケット駆動開発
• WBSとチケットのバランス
– 要件～プロト：チケットでタスク/顧客QA
– 開発：WBSでがっつり管理。並行して顧客
QAをチケットで
– 終盤：バグ/QAなどのチケットが中心。日程
調整が厳密な物はWBS
– 運用：問い合わせなどのチケットが中心

44. GxPでのチケット駆動開発
• なぜJIRAなのか？
– ともかくかっこよくて使いやすい
– Office連携が可能（定例はEXCEL）
– マルチPJでの認証認可/ワークフロー制御
– プラグイン構造とマーケット
– ※いろいろカスタマイズできるけど、やり過
ぎないことも大事

45. まとめ

46. まとめ
• どうしたってSIは必要とされている
• だったら優れたSIをやろうじゃないか
– てか、なんでやらないの？
• サステイナブルなSI
– ITサービスの継続的な提供を通じて、顧客が
持つ社会的価値を常に最大化することで、顧
客と持続可能な関係を結ぶSI/SIer

47. まとめ
• たとえば開発環境から考える
– 分散したチームのコラボレーション基盤
• 顧客と開発者とパートナーと課題/文書/構成の管
理を
– ITサービスを高速に提供する仕組み
• 継続的統合から継続的デリバリーへ
– お勧め
• JIRA(BTS) + Confluence(Wiki) + Stash(Git) +
Bamboo(CI) + Crowd(SSO)

48. まとめ
• チケット駆動開発の実践
– コミュニケーションツールとして考える
• 顧客を巻き込む
• 個人の作業管理は何を使っても良い
– 計画できるタスクはWBSも検討する