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

Developer Summit 2015での講演資料です。
https://event.shoeisha.jp/devsumi/20150219/session/678

【概要】
企業の情報シスは、少ない予算と人的リソースの中でリリースしたのに、実際の現場から使えないと言われる過酷な現場に見えます。しかし一方で、ユーザーである社員が近く、リリースは調整し易く、 直接コミュニケーションしながら課題を一緒に解決でき、社外向けの開発では得難い経験ができる現場とも言えます。グローバル化を推進する企業の情報シスで、私達は少ないメンバーで自ら要求を発見し、作り、実際に試してもらい、改善を続けてきました。本講演では、その過程で発見したことを共有します 。

Transcript

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