【20-A-5】「じつは私、情シスでした。」- 業務の変化を前提としたアジリティの高い情シスチームの2年間
•Download as PPTX, PDF•
17 likes•4,601 views
企業の情報シスは、少ない予算と人的リソースの中でリリースしたのに、実際の現場から使えないと言われる過酷な現場に見えます。しかし一方で、ユーザーである社員が近く、リリースは調整し易く、 直接コミュニケーションしながら課題を一緒に解決でき、社外向けの開発では得難い経験ができる現場とも言えます。グローバル化を推進する企業の情報シスで、私達は少ないメンバーで自ら要求を発見し、作り、実際に試してもらい、改善を続けてきました。本講演では、その過程で発見したことを共有します 。
Recommended
More Related Content
What's hot
Viewers also liked
Similar to 【20-A-5】「じつは私、情シスでした。」- 業務の変化を前提としたアジリティの高い情シスチームの2年間
Similar to 【20-A-5】「じつは私、情シスでした。」- 業務の変化を前提としたアジリティの高い情シスチームの2年間 (20)
【20-A-5】「じつは私、情シスでした。」- 業務の変化を前提としたアジリティの高い情シスチームの2年間
- 1. 「じつは私、情シスでした」 業務の変化を前提としたアジリティの高い情シスチーム の2年間 Feb/20/2015 Tatsuya Sato Corporate IT Department, Rakuten, Inc. http://www.rakuten.co.jp/
- 2. 2 自己紹介 • 佐藤 竜也（@sato_ryu） – 楽天株式会社 • コーポレート情報技術部 – Rubyist • 経歴 – 2009年新卒入社 – エンドユーザー向けサービスの開発 – プライベートPaaSの開発 – 社内向けウェブサービスの開発
- 6. 6 デブサミ初参加 • ボランティアスタッフ – 二日間立ち仕事 – どのセッションも聞いてま せん。
- 11. 今日話さないこと
- 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. 今日覚えて欲しいこと
- 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 最小の動くモノをつくろう • 最低限必要なものを作る。 – 組織ごとの認可のために、組織を表わすグルー プが必要 – グループはディレクトリサービスに作ると既存の 連携サービス
- 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
- 41. 41 きっかけ • 既存システムが、サポート期限切れ • 外注製品で、手を付けられる人がいない。 • 自分たちが既に似たようなものを作っていた。
- 42. 42 チームの当初のミッション • 既存の社内認証認可プラットフォームのリプ レイス • 既存の課題 – オレオレ認証プロトコル – 日本語ドキュメントのみ – 開発者の利用開始までに2週間
- 43. 43 チームの当初のミッション • 既存の社内認証認可プラットフォームのリプ レイス • 既存の課題 – オレオレ認証プロトコル – 日本語ドキュメントのみ – 開発者の利用開始までに2週間 あれ？これは？
- 47. 47 ユーザーサポート対応 • ユーザーからの問合せ対応を開始 – 使い方を教えたり、 – 機能要求を聞いたり • 開発チームが担当
- 53. 53 問合せ対応は開発者がすべき • 機能リリースの手を止める。 – 問合せるということは、困ってる。 – 更にリリースしたら、更に困る可能性 開発 リリース サポート
- 55. 55 ファンレター
- 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
- 60. 60 近い未来の予測ですら難しい • どんなツール、サービスが必要になるかわか らない。 – 会社、ビジネス、法律など変化の要因が多い – 欲しいものが何かわからない • リリースすると真実が分かる。 – 問合せやデモで。
- 61. 61 近い未来の予測ですら難しい • どんなツール、サービスが必要になるかわか らない。 – 会社、ビジネス、法律など変化の要因が多い – 欲しいものが何かわからない • リリースすると真実が分かる。 継続する必要がある
- 62. 62 “ソフトウェアはソフトではない” ソフトウェアは錆びませんが、 ソフトウェアは変化に 対応する必要 があります。 OSや、ビジネスモデル、 法律、税率が変わっていきます。 ソフトウェアは変化 に対応する必要があるのです。それにはどういう方 法があるでしょうか。 スパイラルモデルでしょうか、 アジャイル開発 でしょうか。 まつもとゆきひろ 楽天技術研究所 フェロー 第3回Rubyビジネスフォーラム 基調講演