【20-A-5】「じつは私、情シスでした。」- 業務の変化を前提としたアジリティの高い情シスチームの2年間

「じつは私、情シスでした」業務の変化を前提としたアジリティの高い情シスチームの 2 年間

Feb/20/2015Tatsuya SatoCorporate IT Department, Rakuten, Inc.http://www.rakuten.co.jp/

2

自己紹介

• 佐藤竜也（ @sato_ryu ）– 楽天株式会社

• コーポレート情報技術部– Rubyist

• 経歴– 2009 年新卒入社– エンドユーザー向けサービスの開発– プライベート PaaS の開発– 社内向けウェブサービスの開発

「じつは私、情シスでした」？

4

運命の日

2014 年2 月 14 日

5

Developer Summit 2014

6

デブサミ初参加

• ボランティアスタッフ– 二日間立ち仕事– どのセッションも聞い

てません。

7

二日目の帰り道

原田騎郎さんと話す機会を GET

8

情シスに対する偏見に気づく

情シス＝

アウトソーシング

9

情シスに対する偏見に気づく

情シス＝

アウトソーシング

10

悟り

＿人人人人人人人人人人人人人＿＞　今の仕事、情シスじゃん　＜￣ Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y ￣

今日話さないこと

12

良い話

「アジャイルで情シスの仕事をしたら、コスト削減」

13

そんな良い話はない

「アジャイルで情シスの仕事をしたら、コスト削減」

14

そういう話はしません。

スクラム取り入れたからって、そんな上手くいく話は無い。

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

16

スクラムがしてくれること

• チーム開発がスムーズになる。

“Scrum Diagram”By Mountain Goat Software (Mountain Goat Software) [CC BY 2.5 (http://creativecommons.org/licenses/by/2.5)], via Wikimedia Commons

17

スクラムがしてくれないこと

• リリースしたものの価値は？• 次の方向性は？

??


今日覚えて欲しいこと

19

ググっても出ない

継続的チーム

20

継続的チームの定義

ずっと居て、話を聞くチーム

21

継続的でないチーム

要件定義

仕様策定

開発

リリース

サポート

22

継続的でないチーム

要件定義

仕様策定

開発

リリース

サポート

• Pros– 人数のコントロールが出来る。

• Cons– 変更に時間がかかる

23

継続的チーム

要件定義

仕様策定

開発

リリース

サポート

• Pros– 変更にすぐ着手

• Cons– 人数変更しづらい

24

休憩

• ここまで 10 分だと嬉しい• だいたい言いたいことは言いました。

– 継続的チーム• 深呼吸を一回

25

チームの当初のミッション

• 既存の社内認証認可プラットフォームのリプレイス

• 既存の課題– オレオレ認証プロトコル– 日本語ドキュメントのみ– 開発者の利用開始までに 2 週間

26

長期的要件定義

• 2 ヶ月ほど、熱い議論が続く。– 前任者 2 名– 新チームのマネージャー

27

相反する想い

＿人人人人人人人＿＞　膨らむ期待　＜￣ Y^Y^Y^Y^Y^Y ￣

＿人人人人人人人＿＞　膨らむ不安　＜￣ Y^Y^Y^Y^Y^Y ￣

VS

28

期待と不安

• プロダクトオーナー、マネージャー– 想像している価値に対する期待

• 開発チーム– 「本当にいいの？」という不安

29

最小の動くモノをつくろう

• 最低限必要なものを作る。–組織ごとの認可のために、組織を表わすグ

ループが必要– グループはディレクトリサービスに作ると既

存の連携サービス

30

利用例

• ディレクトリサービス連携したサービスで、認可として利用

31

開発スタート？

• 要件はだいたい確定• すぐ作れるか？

32

No. やっと技術的課題がわかる。

• どうやってデータを貰う？• いつもらえる？

• 書き込むにはどうする？• ポートは空いてる？• インフラの担当者は？

• サーバーどうしよう？• 言語は？• DB どうしよう？

• どうやって連携してるの？

33

ステークホルダーを見つける。

• どうやってデータを貰う？• いつもらえる？

• 書き込むための準備は？• プロトコルは？• ポートは空いてる？

• サーバーどうしよう？• 言語は？• DB どうしよう？

人事部

インフラ自分たち

• どうやって連携してるの？

管理者

34

1 つずつ確認しながら進む。

• 分からないことは、訊いて、自分たちで確認。

• 例– 「 HR 情報のファイルに重複した情報はな

い」– 「記載のアカウントは実在する」

35

1 つずつ確認しながら進む。

• 結果– 「 HR 情報のファイルに重複した情報はあ

る」– 「記載のアカウントは実在するとは限らな

い」

36

リリースしたら、デモ

• ステークホルダーを集めて、デモをする。–現在最新の動くものを見せる。

• 参加者が、本気で意見を言う。– それぞれが重要と思ってることが違うことがわかる。

37

大事なこと

• 実際にモノを作ろうとしたところで、色々見えてくる。– 技術的課題、ステークホルダー

• デモが出来るので、新しい要件を聞けるようになった。

デモ


38

次の段階へ…

• 認可に必要な道具が準備できた。• 本来、作りたかったものを作ろう。

39

とあるデモにて

BOSS

「メーリングリスト管理サービスを引き取ってもらえないか？」

40

次に作ったモノ

• メーリングリスト管理サービス– ディレクトリサービス上へのグループの作成、

メールアドレスの管理用ウェブサービス

41

きっかけ

• 既存システムが、サポート期限切れ• 外注製品で、手を付けられる人がいない。• 自分たちが既に似たようなものを作っていた。

42




43




あれ？これは？

44

とあるデモにて

BOSS

「そんなに、優先度高くない」

45

あっさりと

デモしてたら、方向性が変わった。

46

アルファリリース

• 旧サービスを止めずに並行してリリース• 業務に支障がないように改善してから、

データ移行

47

ユーザーサポート対応

• ユーザーからの問合せ対応を開始–使い方を教えたり、– 機能要求を聞いたり

• 開発チームが担当

48

ガチ勢が出現

役員「これだと業務で使えない。」

49

ガチ勢が出現

役員「部下に使わないよう伝えました。」

50

業務に支障

• 承認作業が 1 件ずつしかできなかった。• 多い日だと数十件の申請を処理

51

一括承認の実装

• コンプライアンス部門から承認もらう。• 確認→実装→ユーザーテストまで 3 週間

52

サポート対応を始めたら、

開発

リリース

サポート

• ユーザーの声が直接聞けて、• やるべきことが分かる。

53

問合せ対応は開発者がすべき

• 機能リリースの手を止める。–問合せるということは、困ってる。– 更にリリースしたら、更に困る可能性

開発

リリース

サポート

54

問合せ対応は開発者がすべき

• プロダクトの実装を最も知っているから、即答できる。

開発

リリース

サポート

55

ファンレター

56

一番重要なのは

開発者の達成感

57

休憩

• 深呼吸一回• 締めに入ろう。

58

大事なことは

デモサポート

• 話を聞いて、変化を汲み取ること。


59

これからの役割

• アカウント、組織情報の活用のためのハブ

60

近い未来の予測ですら難しい

• どんなツール、サービスが必要になるかわからない。– 会社、ビジネス、法律など変化の要因が多い– 欲しいものが何かわからない

• リリースすると真実が分かる。–問合せやデモで。

61

近い未来の予測ですら難しい

• どんなツール、サービスが必要になるかわからない。– 会社、ビジネス、法律など変化の要因が多い– 欲しいものが何かわからない

• リリースすると真実が分かる。

継続する必要がある

62

“ソフトウェアはソフトではない”

ソフトウェアは錆びませんが、ソフトウェアは変化に対応する必要があります。 OSや、ビジネスモデル、法律、税率が変わっていきます。ソフトウェアは変化に対応する必要があるのです。それにはどういう方法があるでしょうか。スパイラルモデルでしょうか、アジャイル開発でしょうか。

まつもとゆきひろ楽天技術研究所フェロー

第 3 回 Ruby ビジネスフォーラム基調講演

63

ご静聴ありがとうございました。

Engineering

【20-A-5】「じつは私、情シスでした。」- 業務の変化を前提としたアジリティの高い情シスチームの2年間