Slide 1
Slide 1 text
「じつは私、情シスでした」
業務の変化を前提としたアジリティの高い情シスチー
ムの2年間
Feb/20/2015
Tatsuya Sato
Corporate IT Department, Rakuten, Inc.
http://www.rakuten.co.jp/
Slide 2
Slide 2 text
2
自己紹介
• 佐藤 竜也（@sato_ryu）
– 楽天株式会社
• コーポレート情報技術部
– Rubyist
• 経歴
– 2009年新卒入社
– エンドユーザー向けサービスの開発
– プライベートPaaSの開発
– 社内向けウェブサービスの開発
Slide 3
Slide 3 text
「じつは私、情シスでした」？
Slide 4
Slide 4 text
4
運命の日
2014年
2月14日
Slide 5
Slide 5 text
5
Developer Summit 2014
Slide 6
Slide 6 text
6
デブサミ初参加
• ボランティアスタッフ
– 二日間立ち仕事
– どのセッションも聞いてま
せん。
Slide 7
Slide 7 text
7
二日目の帰り道
原田騎郎さんと話す機会をGET
Slide 8
Slide 8 text
8
情シスに対する偏見に気づく
情シス
＝
アウトソーシング
Slide 9
Slide 9 text
9
情シスに対する偏見に気づく
情シス
＝
アウトソーシング
Slide 10
Slide 10 text
10
悟り
＿人人人人人人人人人人人人人＿
＞ 今の仕事、情シスじゃん ＜
￣Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y￣
Slide 11
Slide 11 text
今日話さないこと
Slide 12
Slide 12 text
12
良い話
「アジャイルで情シ
スの仕事をしたら、
コスト削減」
Slide 13
Slide 13 text
13
そんな良い話はない
「アジャイルで情シ
スの仕事をしたら、
コスト削減」
Slide 14
Slide 14 text
14
そういう話はしません。
スクラム取り入れたからって、
そんな上手くいく話は無い。
Slide 15
Slide 15 text
15
スクラム
• アジャイル開発のスタイルの1つ
• 一定期間（スプリント）毎に成果物を出しながら、進め
ていく。
– プロダクトバックログ： 要件の一覧
– スプリントバックログ： やることの一覧
“Scrum Diagram” By Mountain Goat Software (Mountain Goat Software) [CC BY
2.5 (http://creativecommons.org/licenses/by/2.5)], via Wikimedia Commons
Slide 16
Slide 16 text
16
スクラムがしてくれること
• チーム開発がスムーズになる。
“Scrum Diagram”By Mountain Goat Software (Mountain Goat Software) [CC BY
2.5 (http://creativecommons.org/licenses/by/2.5)], via Wikimedia Commons
Slide 17
Slide 17 text
17
スクラムがしてくれないこと
• リリースしたものの価値は？
• 次の方向性は？
?
?
“Scrum Diagram” By Mountain Goat Software (Mountain Goat Software) [CC BY
2.5 (http://creativecommons.org/licenses/by/2.5)], via Wikimedia Commons
Slide 18
Slide 18 text
今日覚えて欲しいこと
Slide 19
Slide 19 text
19
ググっても出ない
継続的チーム
Slide 20
Slide 20 text
20
継続的チームの定義
ずっと居て、
話を聞く
チーム
Slide 21
Slide 21 text
21
継続的でないチーム
要件定義
仕様策定
開発
リリース
サポート
Slide 22
Slide 22 text
22
継続的でないチーム
要件定義
仕様策定
開発
リリース
サポート
• Pros
– 人数のコントロールが出来る。
• Cons
– 変更に時間がかかる
Slide 23
Slide 23 text
23
継続的チーム
要件定義
仕様策定
開発
リリース
サポート
• Pros
– 変更にすぐ着手
• Cons
– 人数変更しづらい
Slide 24
Slide 24 text
24
休憩
• ここまで10分だと嬉しい
• だいたい言いたいことは言いました。
– 継続的チーム
• 深呼吸を一回
Slide 25
Slide 25 text
25
チームの当初のミッション
• 既存の社内認証認可プラットフォームのリプ
レイス
• 既存の課題
– オレオレ認証プロトコル
– 日本語ドキュメントのみ
– 開発者の利用開始までに2週間
Slide 26
Slide 26 text
26
長期的要件定義
• 2ヶ月ほど、熱い議論が続く。
– 前任者 2名
– 新チームのマネージャー
Slide 27
Slide 27 text
27
相反する想い
＿人人人人人人人＿
＞ 膨らむ期待 ＜
￣Y^Y^Y^Y^Y^Y￣
＿人人人人人人人＿
＞ 膨らむ不安 ＜
￣Y^Y^Y^Y^Y^Y￣
VS
Slide 28
Slide 28 text
28
期待と不安
• プロダクトオーナー、マネージャー
– 想像している価値に対する期待
• 開発チーム
– 「本当にいいの？」という不安
Slide 29
Slide 29 text
29
最小の動くモノをつくろう
• 最低限必要なものを作る。
– 組織ごとの認可のために、組織を表わすグルー
プが必要
– グループはディレクトリサービスに作ると既存の
連携サービス
Slide 30
Slide 30 text
30
利用例
• ディレクトリサービス連携したサービスで、認
可として利用
Slide 31
Slide 31 text
31
開発スタート？
• 要件はだいたい確定
• すぐ作れるか？
Slide 32
Slide 32 text
32
No. やっと技術的課題がわかる。
• どうやってデータを貰う？
• いつもらえる？
• 書き込むにはどうする？
• ポートは空いてる？
• インフラの担当者は？
• サーバーどうしよう？
• 言語は？
• DBどうしよう？
• どうやって連携してるの？
Slide 33
Slide 33 text
33
ステークホルダーを見つける。
• どうやってデータを貰う？
• いつもらえる？
• 書き込むための準備は？
• プロトコルは？
• ポートは空いてる？
• サーバーどうしよう？
• 言語は？
• DBどうしよう？
人事部
インフラ
自分たち
• どうやって連携してるの？
管理者
Slide 34
Slide 34 text
34
1つずつ確認しながら進む。
• 分からないことは、訊いて、自分たちで確認。
• 例
– 「HR情報のファイルに重複した情報はない」
– 「記載のアカウントは実在する」
Slide 35
Slide 35 text
35
1つずつ確認しながら進む。
• 結果
– 「HR情報のファイルに重複した情報はある」
– 「記載のアカウントは実在するとは限らない」
Slide 36
Slide 36 text
36
リリースしたら、デモ
• ステークホルダーを集めて、デモをする。
– 現在最新の動くものを見せる。
• 参加者が、本気で意見を言う。
– それぞれが重要と思ってることが違うことがわか
る。
Slide 37
Slide 37 text
37
大事なこと
• 実際にモノを作ろうとしたところで、色々見えてく
る。
– 技術的課題、ステークホルダー
• デモが出来るので、新しい要件を聞けるように
なった。
デモ
“Scrum Diagram” By Mountain Goat Software (Mountain Goat Software) [CC BY
2.5 (http://creativecommons.org/licenses/by/2.5)], via Wikimedia Commons
Slide 38
Slide 38 text
38
次の段階へ…
• 認可に必要な道具が準備できた。
• 本来、作りたかったものを作ろう。
Slide 39
Slide 39 text
39
とあるデモにて
BOSS
「メーリングリスト管理サービス
を引き取ってもらえないか？」
Slide 40
Slide 40 text
40
次に作ったモノ
• メーリングリスト管理サービス
– ディレクトリサービス上へのグループの作成、メー
ルアドレスの管理用ウェブサービス
Slide 41
Slide 41 text
41
きっかけ
• 既存システムが、サポート期限切れ
• 外注製品で、手を付けられる人がいない。
• 自分たちが既に似たようなものを作っていた。
Slide 42
Slide 42 text
42
チームの当初のミッション
• 既存の社内認証認可プラットフォームのリプ
レイス
• 既存の課題
– オレオレ認証プロトコル
– 日本語ドキュメントのみ
– 開発者の利用開始までに2週間
Slide 43
Slide 43 text
43
チームの当初のミッション
• 既存の社内認証認可プラットフォームのリプ
レイス
• 既存の課題
– オレオレ認証プロトコル
– 日本語ドキュメントのみ
– 開発者の利用開始までに2週間
あれ？これは？
Slide 44
Slide 44 text
44
とあるデモにて
BOSS
「そんなに、優先度高くない」
Slide 45
Slide 45 text
45
あっさりと
デモしてたら、
方向性が変わった。
Slide 46
Slide 46 text
46
アルファリリース
• 旧サービスを止めずに並行してリリース
• 業務に支障がないように改善してから、デー
タ移行
Slide 47
Slide 47 text
47
ユーザーサポート対応
• ユーザーからの問合せ対応を開始
– 使い方を教えたり、
– 機能要求を聞いたり
• 開発チームが担当
Slide 48
Slide 48 text
48
ガチ勢が出現
役員
「これだと業務で
使えない。」
Slide 49
Slide 49 text
49
ガチ勢が出現
役員
「部下に使わないよ
う伝えました。」
Slide 50
Slide 50 text
50
業務に支障
• 承認作業が1件ずつしかできなかった。
• 多い日だと数十件の申請を処理
Slide 51
Slide 51 text
51
一括承認の実装
• コンプライアンス部門から承認もらう。
• 確認→実装→ユーザーテストまで3週間
Slide 52
Slide 52 text
52
サポート対応を始めたら、
開発
リリース
サポート
• ユーザーの声が直接聞けて、
• やるべきことが分かる。
Slide 53
Slide 53 text
53
問合せ対応は開発者がすべき
• 機能リリースの手を止める。
– 問合せるということは、困ってる。
– 更にリリースしたら、更に困る可能性
開発
リリース
サポート
Slide 54
Slide 54 text
54
問合せ対応は開発者がすべき
• プロダクトの実装を最も知っているから、即答
できる。
開発
リリース
サポート
Slide 55
Slide 55 text
55
ファンレター
Slide 56
Slide 56 text
56
一番重要なのは
開発者の
達成感
Slide 57
Slide 57 text
57
休憩
• 深呼吸一回
• 締めに入ろう。
Slide 58
Slide 58 text
58
大事なことは
デモ
サポート
• 話を聞いて、変化を汲み取ること。
“Scrum Diagram” By Mountain Goat Software (Mountain Goat Software) [CC BY 2.5
(http://creativecommons.org/licenses/by/2.5)], via Wikimedia Commons
Slide 59
Slide 59 text
59
これからの役割
• アカウント、組織情報の活用のためのハブ
Slide 60
Slide 60 text
60
近い未来の予測ですら難しい
• どんなツール、サービスが必要になるかわか
らない。
– 会社、ビジネス、法律など変化の要因が多い
– 欲しいものが何かわからない
• リリースすると真実が分かる。
– 問合せやデモで。
Slide 61
Slide 61 text
61
近い未来の予測ですら難しい
• どんなツール、サービスが必要になるかわか
らない。
– 会社、ビジネス、法律など変化の要因が多い
– 欲しいものが何かわからない
• リリースすると真実が分かる。
継続する必要がある
Slide 62
Slide 62 text
62
“ソフトウェアはソフトではない”
ソフトウェアは錆びませんが、 ソフトウェアは変化に
対応する必要 があります。 OSや、ビジネスモデル、
法律、税率が変わっていきます。 ソフトウェアは変化
に対応する必要があるのです。それにはどういう方
法があるでしょうか。 スパイラルモデルでしょうか、
アジャイル開発 でしょうか。
まつもとゆきひろ
楽天技術研究所 フェロー
第3回Rubyビジネスフォーラム 基調講演
Slide 63
Slide 63 text
63
ご静聴ありがとう
ございました。