Developers Summit 2016 【19-B-１】和智様の資料です。

1. 1
情シスの中のアーキテクト
～ソフトウェアアーキテクチャを超えて～
株式会社ハピネット 情報システム本部
和智 右桂
##ddeevvssuummii ##ddeevvssuummiiBB

2. 会社紹介
社名：株式会社ハピネット
最寄駅：蔵前
設立：1969年
業種：
• 玩具・遊戯用具の企画・製造・販売
• 映像・音楽ソフトの企画・製作・販売
• ビデオゲームハード・ソフト等の販売
• アミューズメント商品の販売等
従業員数：
• 連結：933名
• 単体：532名（2015年3月31現在）
2

3. 自己紹介
名前：和智 右桂
所属：情報システム本部
経歴：
• 現職で４社め
• これまで、開発プロセスの標準
化やアーキテクチャ設計、大規
模システム開発のマネジメント
などを経験
• 現在は基幹システムリプレイス
プロジェクトのマネジメント業
に従事
3

4. 自己紹介
時々翻訳をしています
4
@@ddiiggiittaallssoouull00112244

5. アジェンダ
導入 ～アーキテクト／情シス／内製化～
情シスにとって内製化とは？
内製化「やってはいけない」
山を越えるために
情シスの中のアーキテクト
まとめ
5
本資料および講演内容は、講演者個人の見解であり、
所属する組織の戦略ないし見解を必ずしも反映するものではありません。

6. 導入
情シスの中のアーキテクト
6

7. 導入
アーキテクトとは？
アーキテクチャを設計・構築・維持し、それを成長させ
る責任を担うロール。
アーキテクチャとは、 全体像 に関わるもの。この「
全体」のとらえ方によってアーキテクトの守備範囲は変
わる。
7
“一度リリースを終えただけで
アーキテクトを名乗るような人間には
よくよく注意することだ”
–LLuukkee HHoohhmmaannnn

8. 導入
情報システム部門（情シス）とは？
企業や文化によって多少の違いはあるものの、概ね次の
ミッションを担う。
• 企画提案
– ITの知識に基づいた事業戦略もしくはシステムの企画／提案
• 開発
– 新規システムの開発や既存システムのリプレイス、およびイ
ンフラの構築
– 運用されているシステムの改善要望への対応
• 運用保守
– 運用されているシステムの監視、障害対応、運用対応など
• サポート・ヘルプデスク
– 運用されているシステムおよびPC全般に対するサポート
8

9. 導入
内製化とは？
一般的には「外部に委託／発注して製造していたものを
自らの会社内部で製造するようにすること」を指す。
• インソーシング （⇔ アウトソーシング）
9
本講演では 情報システム の内製化を扱う

10. 情シスにとって内製化とは？
情シスの中のアーキテクト
10

11. 情シスにとって内製化とは？
内製化の目的
ベンダー丸投げだとうまくいかない
• 中身がよくわからない
• 言いなりになってしまう
• そもそもできあがらないことがある
ベンダーロックインの解除
• QCDのコントロール自分たちで行う
– 要員調整などがベンダー都合になることを避ける
– 依頼するベンダーのコントロールを自律的に行う
ノウハウの蓄積による事業化
• 情シスをコスト部門から収益部門へ
11

12. 情シスにとって内製化とは？
システムを取り巻く文脈の変化
以前は、一度作ったシステムは障害対応以外にはほぼ手
を入れず、何年も使い続けることが主流だった。
近年では、一度ベースを作ったシステムに対して継続的
に改善を加えていくようになっている。
– DevOps
– システムに対するコントロールの必要性の向上
12
内製化の価値向�上

13. 情シスにとって内製化とは？
システムに対するガバナンスの形成段階
13
モノリシック＋アウトソース
コントロールが効くシステムの新規開発
ベースに対する継続的な改�善

14. 14
現行システムの業務仕様
業務フローの見直し
大規模新規開発
https://www.flickr.com/photos/126500863@N02/14585778617

15. 情シスにとって内製化とは？
大規模新規開発への挑戦
開発全体のマネジメントを自社内に取り戻すことになる
ため、ノウハウが蓄積されていないユーザー企業にとっ
てはそれなりにチャレンジング
15
開発全体
プログラミング
プログラミングの問題ではなく、マネジメントの問題

16. 情シスにとって内製化とは？
山の向こうにある世界
16
事業部ユーザー システム
事業部フロント
開発チーム
バックログ
使用
問い合わせ／要望
起票
ログ
企画
経営
PPOO
戦略
起票
優先順位
参照
開発

17. 内製化「やってはいけない」
情シスの中のアーキテクト
17

18. 18https://www.flickr.com/photos/ellispotter/16430835967
アジャイルに期待しすぎる

19. 内製化「やってはいけない」
「アジャイルに期待しすぎる」
「ウォーターフォールではうまくいかないからアジャイ
ルでやりましょう」という発言は鵜呑みにすべきではない
• 「アジャイルでやる」とはなんなのか
方法論で解決できない問題を方法論で解決しようとし
ても、不幸にしかならない
• 失敗ケース
– ウォーターフォール → できたものが思ったものと違う
– アジャイル → まともなものができない
19
アジャイルが商材になっていないだろうか？

20. 内製化「やってはいけない」
そもそも...
無計画に目的地へ連れて行ってくれるようなものではない
構想を実現させるためには具体的な計画を立てなけれ
ばならない
• この点についてはアジャイルもウォーターフォール
も関係ない
• 「前工程が完了しないと次工程に進まない」と言う
ほど厳格なウォーターフォールは最近見たことがない
20
計画せずに踏み出すことは、ただの無計画でしかない

21. そういえば、アジャイルとは？
アジャイル宣言の背後にある原則
21
顧客満足を最優先し、
価値のあるソフトウェアを早く継続的に提供します。
要求の変更はたとえ開発の後期であっても歓迎します。
変化を味方につけることによって、お客様の競争力を引き上げます。
動くソフトウェアを、22--33週間から22--33ヶ月という
できるだけ短い時間間隔でリリースします。
ビジネス側の人と開発者は、プロジェクトを通して
日々一緒に働かなければなりません。
意欲に満ちた人々を集めてプロジェクトを構成します。
環境と支援を与え仕事が無事終わるまで彼らを信頼します。
（以下略）
http://agilemanifesto.org/iso/ja/principles.html

22. 22https://www.flickr.com/photos/johnloo/4876114194
コンサルタントを信じすぎる

23. 内製化「やってはいけない」
「コンサルタントを信じすぎる」
23
コンサルティング企業とは、「業務における
問題の発見・解決策の提案・業務の改�善の
補助、経営戦略への提言、などを中心に、
企業の様々な業務を効率化するための
提案自体を売り物にしている企業」 のこと
ウィキペディア ((WWiikkiippeeddiiaa))::
フリー百科事典（hhttttppss::////jjaa..wwiikkiippeeddiiaa..oorrgg//wwiikkii//コンサルティング）より

24. 内製化「やってはいけない」
「コンサルタントを信じすぎる」
専門領域については間違いなくプロフェッショナル
ただし、こちらが必要な領域を全てカバーしているわけ
ではない。
• コンサルタントにはコンサルタント側の都合もある
• 領域についてはコンサルタント側も自覚的
24
カバーされていない領域については
何らかのかたちで補完しなければならない

25. 25
https://www.flickr.com/photos/86639298@N02/8559728371
ツールに頼りすぎる

26. 内製化「やってはいけない」
「ツールに頼りすぎる」
開発の様々な局面でツールは必要不可欠
デファクトスタンダードも少なくない
• 課題管理→ Redmine / JIRA
• コミュニケーション→ Hipchat / Slack
• バージョン管理→ Git / SVN
• IDE→ IntelliJ / Eclipse
26
では、注意すべきことは？

27. 「ツールに頼りすぎる」
特定のパラダイムに基づき、プロセスをコントロールで
きている前提で、各アクティビティをサポートするツー
ルを使う分には何ら問題はない。
パラダイム
内製化「やってはいけない」
27
プロセス
アク
ティビ
ティ
アク
ティビ
ティ
アク
ティビ
ティ
アク
ティビ
ティ
ツール ツール

28. 「ツールに頼りすぎる」
特定のパラダイムを持ち、プロセスを包括するようなツ
ールを導入する場合には、そのパラダイムが文脈に適し
ているか、十分な先行事例があり安全であるかという点
について注意深く評価する必要がある。
ツール＝パラダイム
内製化「やってはいけない」
28
プロセス
アク
ティビ
ティ
アク
ティビ
ティ
アク
ティビ
ティ
アク
ティビ
ティ

29. 内製化「やってはいけない」
たとえば…
フルスタック自動生成系ツール
• 習得自体が困難なケースがある
• 常識的な開発プロセスと整合しないケースがある
モデル駆動開発
• 手なれたER図&SQLとは間合いが違う
• 複雑なモデルは処理の設計も困難にする
29
パラダイムシフトを避けろということではない

30. 30
https://www.flickr.com/photos/cclogg/13993998237
ベンダーに任せすぎる

31. 内製化「やってはいけない」
「ベンダーに任せすぎる」
「ものづくり」についてはプロフェッショナル
何を作るかを決めることはできない
• 何にコミットしてもらえるかは、契約によっても相
手のスタイルによっても異なる
31
屏風の虎を追い出すのは誰？
捕まえるのは誰？
もう一度屏風にしまうのは誰？

32. 内製化「やってはいけない」
ではどうすればいいのか？
32
適切に計画する
コンサルタントの専門知識を活用する
要所要所で適したツールを使う
ベンダーとの協力・信頼関係を築く

33. 内製化「やってはいけない」
結局、誰もゴールまで連れて行ってはくれない
発注者が全体観を失っていては、他のアクター
が最善を尽くしても、どこにもたどり着かない
33
発注者
コンサルタント
ベンダー
ツール
虎
Σ||||
Σ||||
Σ||||
屏風

34. 内製化「やってはいけない」
自分の全体観の中で向き合うしかない
発注者が自らの全体観の中、各アクターの力を
借りてゴールまでの道筋を紡ぐ
34
発注者
コンサルタント
ベンダー
虎
屏風
ツール

35. 35
それができれば苦労はしない！
https://www.flickr.com/photos/philliecasablanca/2578469959/

36. 山を越えるために
情シスの中のアーキテクト
36

37. 山を越えるために
全体像を描き出すための３つの軸
• アーキテクチャ
• 組織
• プロセス
紡いでいくための３つの基礎
• 進捗管理
• 課題管理
• コスト管理
37
これを押さえれば、
大失敗はしない！

38. 3つの軸
38

39. 山を越えるために
• 各ドメインの責務とドメイン間のメッセージインタ
ーフェイスを明確に
• 開発対象が明確になるように
• どのような構造になるのか
• それがどのように動くのか
39
業務領域（ドメイン）を包括した大きな絵を描く
各ドメイン内の実装構成要素の絵を描く
アーキテクチャ
静的側面と動的側面の両方からとらえる

40. 山を越えるために
• 設計（＝具体化）フェーズには、それに対応する検
証フェーズが必ず必要
• ドメイン内／ドメイン間の検証も設計する
• 各フェーズの成果物（＝アウトプット）は、次のフ
ェーズのインプットになる
• 実装構成要素までつながるようにする
• 成果物間に跳躍があると、誰かが埋めることになる
– 検証フェーズへのインプットが消滅する
40
V字モデルがすべての基本
成果物間を正確につなげる
プロセス

41. 山を越えるために
41
組織
アーキテクチャとプロセスを反映させる
組織間のコミュニケーションも設計する
• システムの構造と組織の構造は整合させておくべき
ref.コンウェイの法則
• 成果物の精度はそれを受け取る組織によるレビュー
を受けるべき
• いつ、何を受け渡すのか
• 日々のコミュニケーションはどうするのか

42. 42
https://www.flickr.com/photos/emigh/113092386
ポイントはインターフェイス
3つの軸で全体像を描き出す

43. 43
3つの基礎

44. 山を越えるために
• 構想は計画として積み上げなければならない
• 計画とズレることが悪いのではなく、そのズレに気
づけないことが問題
• 個人の自己管理に頼らない制度設計
44
進捗管理
線表を作り、チーム全員で共有する
進捗を確認するための会議体を設定する
アーキテクトの自己管理能力を信じない

45. 山を越えるために
• 課題の管理を個人の記憶に頼らない
• 課題の発生から解決までのフローを定める
• 担当者と期日を明確にする
45
課題管理
課題は統一的に管理する
課題の棚卸／解決をするための会議体を設定する
放っておけば必ず課題は放置される

46. 山を越えるために
• 「誰がどの期間」はコストの話でもある
• 予定とのズレに気づくタイミングを導入する
• 特に、スケジュール変更のタイミングでは必ず見直す
46
期間が延びればコストにはねることを忘れない
コスト管理
線表と合わせた要員計画と対応付ける
定期的に予実を比較する仕組みを導入する

47. 47
ゴールまでの全体観を得る
https://www.flickr.com/photos/trainor/2902023575/
Plan

48. 48
継続的に追跡しズレに対応する
https://www.flickr.com/photos/7214702@N02/8019843586
Inspect and Adapt

49. 情シスの中のアーキテクト
情シスの中のアーキテクト
49

50. 情シスの中のアーキテクト
アーキテクトが構築／コントロールすべきもの
50
システム／ソフトウェア
構築までのプロセス・組織・道筋
システムをとりまく情報の流れ

51. まとめ
情シスの中のアーキテクト
51

52. まとめ
システムのガバナンス形成には３段階がある
• まずはモノリシックな基幹に立ち向かう
最初の山を越えるのはそれなりにチャレンジング
• 自分の力で越えていかなければならない
山を越えるための一定のノウハウはある
• ３つの軸によって全体観を得る
• ３つの基礎によってゴールまでの道を紡ぐ
構築すべきは情報の流れ
• 最終的には企業のビジネスと有機的に関わる
52

53. 53
OOnnee mmoorree tthhiinngg…�

54. • システムをどうしていくか自分たちで決められる
• 最終的に（できる限りの）責任を持つ覚悟は大前提
• とはいえ、説明責任を果たし、最後までやりきるこ
としかできないのだが
• 発注者側に立って、これまで見えなかったものが見
えるようになってきた
54
ユーザー企業に入って
結局は最初から最後まで 覚悟 と 人 の話
大きな判断への導き
「全体」像の広がり
自分たちのシステムを作る楽しみ

55. 55
ご清聴ありがとうございました！