Biz、Dev、そして「IT部門」と企むアジャイル

大きな企業の中で「IT部門」と協調して課題解決を目指すには?

とあるアジャイルプロジェクトの取り組み事例を、ビジネス/開発/IT部門それぞれの観点から共有します。

 
 

Outline/Structure of the Advanced Case Study

ビジネスを変革するために企業のITシステムの刷新を試みようと企めば、いわゆる「IT部門」に代表される社内の利害関係者と正面から向き合うことになります。

わたしたちは、既存の企業の文化や習慣を尊重しながら、しかしビジネス上の「企み」を素早く具現化して行くために、「IT部門」と沢山の対話や行動を積み重ねてきました。上手くいったこともあれば、まだまだ道半ばの部分も残っています。

本Talkでは、とあるグローバルIT案件のプロジェクトに関わった、ビジネス側、開発側、そして「IT部門」側の三者が登壇します。

そしてそれぞれの視点から、今回のプロジェクトをどう受け止め、取り組んでいるのかを伝えることで、アジャイルにチャレンジを続けるチームの現実的な姿を立体的に浮かび上がらせてみたいと思います。

Learning Outcome

同じように規模の大きな企業でアジャイルに取り組み、実際に組織の壁にぶつかっている人々にとってヒントとなる事例が得られます

Target Audience

大きめの企業でアジャイルに企みたいすべての人

schedule Submitted 1 year ago

Public Feedback

comment Suggest improvements to the Speaker

  • Liked Yoh  Nakamura
    keyboard_arrow_down

    Yoh Nakamura - ファシリテーションの難しさと楽しさ

    20 Mins
    Thought & Practice
    Beginner

    ScrumでもXPでもアジャイルなやり方でプロダクト開発をしていく上で”会話”は大事になってきます。

    そのような会話は1対1に限らず、チーム全員、チームとステークホルダーのような複数人である会話することもあります。
    そのような場には様々なコンテキスト、利害関係を持った人々が集まることもあり、何もしないで良い結果を得るのが難しい場合もあります。

    その場の質を高めるスキルの1つがこのセッションのテーマである”ファシリテーション”です。


    ファシリテーションとは、会議、ミーティング等の場で、発言や参加を促したり、話の流れを整理したり、参加者の認識の一致を確認したりする行為で介入し、合意形成や相互理解をサポートすることにより、組織や参加者の活性化、協働を促進させるリーダーの持つ能力の1つ。日常での組織コミュニケーション全般において、ファシリテーション技術は活用される。 (Wikipediaより抜粋)


    このセッションでは、スクラムマスターにとって必要なスキルの1つでもあるファシリテーションの難しさや楽しさを、現場コーチとして20以上の現場を支援してきた知見を交えてお話します。

  • Liked Narichika Kajihara
    keyboard_arrow_down

    Narichika Kajihara - エンジニア採用もカンバン使ってみたら、「透明性」によって採用が活動が変わったこと / Agile Recruiting

    Narichika Kajihara
    Narichika Kajihara
    Agile Coach
    Yappli,Inc.
    schedule 1 year ago
    Sold Out!
    20 Mins
    Advanced Case Study
    Advanced

    「スクラム」のフレームワークは、もともとソフトウェア開発に用いられてきました。しかし「スクラム」の経験主義の原則は、短いイテレーションの中で、検査と適用を繰り返すことでプロセスのカイゼンを加速させる事ができます。また透明性の原則によって、ステークホルダーへの説明責任、今何が問題になっているのかを見える化させることができます。

    その「アジャイル」フレームワークを「エンジニア採用活動」に適用してみた内容について、発表させていただきたいと考えています。
    トラディッショナルな採用活動は秘密主義に根ざしており、独自な文化が根強く残っています。その中で透明性をもったプロジェクト運営をすることで、「採用活動の変化」「ステークホルダーの意識の変化」、検査と適用を繰り返すことでプロセスのカイゼン速度が向上した。

    開発部門以外にも適用した事例について、お話させていただきたいと思います。

  • Liked kyon_mm
    keyboard_arrow_down

    kyon_mm - 超Scrum入門〜未完成フラクタルと15minSprint〜

    kyon_mm
    kyon_mm
    Test Architect
    オンザロード
    schedule 1 year ago
    Sold Out!
    45 Mins
    Thought & Practice
    Advanced

    https://www.youtube.com/watch?v=7xhxIYYMmTc

    チームがうまくいっていることはスクラムチームの大きな目標です。

    いくつかのスクラムチームに関わってきた立場から、良いチームになるための1つの大きなアプローチを見つけました。私が関わってきたチームでは、最初から1DaySprintをやりつづけています。また、1 Hourのタイムボックスを持つチームもあります。またそれらはたった数日で成されます。

    良いチーム、美しいチームとはスクラムという視点だけにはとどまりません。あるチームでは、15minSprint、1hourSprint、1DaySprint、1WeekSprint、1MonthSprintを構成したフラクタルなスクラムを実践しています。

    数万年に渡る生物の美しさ、クリストファー・アレグザンダーが発見してきた美しさ、といった視点からスクラムやチーム、そして理想像を整理します。

  • Liked ohbarye
    keyboard_arrow_down

    ohbarye - プロダクトの「負債」を「機能」と呼び直すために ーA/Bテストを用いた"価値"の定量化ー / Fact based decision making

    ohbarye
    ohbarye
    Engineering Manager
    Quipper
    schedule 1 year ago
    Sold Out!
    20 Mins
    1st Step Case Study
    Beginner

    ―――憶測や独断ではなく計測されたデータや事実に基づいて意思決定している者だけが石を投げなさい―――

    多くのWebサービスがそうであるように、Quipper が運営する「スタディサプリ」においても長らく"負債"と呼ばれる機能を抱えてきました。

    関係者曰く「なぜこんな機能を早く消してしまわないのか」…

    しかしA/Bテスト・統計的手法・エンジニアリングを組み合わせ、「その機能がどれだけ売上に貢献しているのか」という価値を定量化した結果、"負債"と呼ぶのは相応しくないと認識を改めることになりました。

    本セッションではその事例をご紹介しつつ以下の内容についてお話できればと思います。

    • Quipper が実践しているA/Bテスト
    • 定量データに基づく意思決定
    • 価値の定量化が開発体験やチームにどのような影響を及ぼしたか
  • Liked Rie Chonan
    keyboard_arrow_down

    Rie Chonan / Tadataka Ebihara - プロダクトオーナーは突然に 〜メカ屋出身プランナーと奇妙な冒険〜

    20 Mins
    1st Step Case Study
    Beginner

    プロダクトオーナーの育成、支援はスクラムマスターの役割であり、難しさである、という事は巷でよく聞く課題です。

    確かに、私も過去に現場でそのような状況に直面することがあり、プロダクトオーナーの立ち位置やチームとの関わり方、支援の方法について悩むことがありました。

    一方で、私たちClova関連チームのプロダクトオーナーは、POという役割も、スクラム開発も初めてという状態での抜擢。

    未経験による悩みだけでなく、ソフトウェア開発とのギャップを感じていました。

    このような状況で、私たちはプロダクトオーナーが抱える悩みや問題は、開発チームの課題として一緒に解消する事にしました。

    本セッションでは、Clova関連チームのプロダクトオーナーと共に登壇します。

    複数の立場から、開発チームとの関わり方やプロダクトオーナーが躓きやすいポイントを紐解きながら紹介できたら幸いです。

  • Liked Mitsuyuki Shiiba
    keyboard_arrow_down

    Mitsuyuki Shiiba - ちゃんとやってるのになんかうまくいかないスクラムからの脱出

    20 Mins
    Advanced Case Study
    Intermediate

    こんにちは。椎葉です。

    僕は楽天でWebアプリケーションエンジニアとして働いています。数年前に「エンジニアとして色んなチームを内側からサポートしたい!」と考えて「改善グループ」というグループを立ち上げました。そして、様々なチームの中に入っていって、一緒にコードを書いたり、テストを書いたりして楽しんでいます。

    そんな風にエンジニアとして動くことを中心にしてはいるのですが、実は毎回最初にやるのはチームの開発プロセスを一緒に改善することなんです。というのも、エンジニアとして動くための土台としての開発プロセスが、とても重要だからです。

    僕の所属しているECインキュベーション開発部では、どのチームもスクラムで開発をしているのですが、この活動の中でよく聞いたのは「スクラムをやってはいるのだけど、何かうまくいかない」ということです。

    このセッションでは「スクラムが何かうまくいかない」と感じているチームに実際にどのような課題があったのか、その原因は何だったのか、そしてそれをどのように改善したのか、を失敗談も交えながらお伝えしたいなと思います。

    同じような課題を感じている方が一歩踏み出すきっかけになるといいなと思います。そして、セッションの後にはみなさんと「うちもこういうことがあるよー・あったよー」みたいな話をできたら嬉しいです!

  • Liked Koki Shimizu
    keyboard_arrow_down

    Koki Shimizu / Kazunori Yamasaki - ロボットベンチャーでLeSSの実践 -フラット組織をどうスケールしていくか-

    45 Mins
    Thought & Practice
    Intermediate

    私たちGROOVE Xは家庭用ロボットの開発を進めています。

    この開発は非常に領域が広く、関わる人数も多く、100名を超えています。

    • ハードウェア(メカ/エレキ/ファーム)
    • ソフトウェア(OS/機械学習/クラウド)
    • アプリケーション(振る舞い/アプリ/サイト)
    • マーケティング
    • コーポレート

    などのチームがありますが、私たちは全社的にスクラムを推進しています。

    チーム数は15を超えており、大規模スクラムの手法の一つである、LeSS(Large Scale Scrum)を活用しています。

    また、組織構造はフラットを維持しており、CEO以外は役職はありません。フラット組織特有のメリット・デメリットも交えてご紹介できたらと思います。

    本セッションでは、LeSSを活用する上での注意点や工夫点、難しい点、LeSS Hugeへ向かい、さらにスケールするにはどうすればよいかという今後の展望を皆様とシェアさせていただきます。

    ※LeSS HugeはLeSSをさらに大規模にする手法。

    今後スクラムで大規模開発・スクラムのスケーリング・組織のスケーリングをする上での一助になればと思っています。

  • Liked Mitsunori Seki
    keyboard_arrow_down

    Mitsunori Seki - プロダクトオーナーがエンタープライズアジャイルで抱える苦悩と対処

    45 Mins
    Thought & Practice
    Intermediate

    エンタープライズアジャイルを実現するにあたり、プロダクトオーナーは、プロダクトマネジメント組織の中心として振る舞うことが求められます。しかし、プロダクトオーナーが抱える悩みは多岐に渡ります。本セッションでは、それらの悩みごとを整理した上で、解決に向けた取り組みについてご紹介いたします。

    • プロダクトオーナーとは
    • プロダクトオーナーが抱える悩み
    • なぜプロダクトオーナーが悩むのか
    • どう対処したらよいか
    • プロダクトオーナーがやるべき3つのこと
    • まとめ
  • Liked Hiroki Hachisuka
    keyboard_arrow_down

    Hiroki Hachisuka / Masahiro Kimura / Mitsunori Seki - 価値観ババ抜き ~潜在的価値観を知るチームビルディング~

    100 Mins
    Workshop
    Beginner

    価値観ババ抜きはカードを使った自分発見ゲームです。

    今回は公認インストラクターの私が実施させていただきます。

    「成長」「思いやり」「愛」「つながり」の手札に「貢献」というカードが加わってきたとき。この中から一枚手放さなくてはならないとしたら、あなたは何を手放しますか?

    そしてその後に「チームワーク」がはいってきたら、今度はどれを?

    その場で集まった仲間とカードをとったり、とられたりしながら自分が大切にしている思いに気づいていく。気づきがいっぱいで、そしてとにかく楽しい!そんな素敵なワークです。
    是非お楽しみください。

    こんな方にお勧め

    • 自分に自信がない
    • 元気になりたい
    • コミュニケーションの質をあげたい
    • 楽しみながら、自分を知りたい
    • 自分の軸が持てなくて悩んでいる
  • Liked Takashi Takebayashi
    keyboard_arrow_down

    Takashi Takebayashi - プロダクトオーナー/スクラムマスター/開発チームはつらいよ 〜リーダーシップ勘違い事例集〜(仮)

    20 Mins
    Thought & Practice
    Beginner

    アジャイルソフトウェア開発のスクラムで開発をする上で、スクラムチームとして、プロダクトオーナー・開発チーム・スクラムマスターのいずれかのロールを担当します。
    今までいずれか一つのロールを経験してきていると思いますし、なかには複数のロールを経験されている方もおられるでしょう。
    それぞれが経験したロールの視座から他のロールについて好ましい振る舞い、好ましくない振る舞いを直感的または論理的に理解しているのではないでしょうか。

    同時期に、まったく異なるプロジェクトで、プロダクトオーナー・開発チーム・スクラムマスターのロールを経験と周囲からのフィードバックを得る機会に恵まれました。
    そこから、それぞれのロールが他のロールに対する大きな勘違いがあることに気づきました。

    このセッションでは、実例に基づき、プロダクトオーナー・開発チーム・スクラムマスターに対してのよくある勘違いについてご紹介します。
    また、その勘違いを乗り越え、どの側面を改善することでより良い振る舞いができるかについてもお話します。

  • Liked shihara shinji
    keyboard_arrow_down

    shihara shinji - アジャイルを組織に取り入れるために、人財育成始めました

    20 Mins
    Thought & Practice
    Beginner

    弊社プロダクト部門は、長い間、プロダクトアウト思考のプロダクト開発を行ってきました。
    プロダクトアウト思考の組織文化が形成されており、同じような会社は多いと思います。

    現在は、VUCA時代。
    お客様のためになるプロダクトやサービス開発は、アジリティが高いアジャイル開発が主流です。

    完成された組織文化に新しい取組みを導入するのは、非常に困難です。
    同じような悩みを抱えている会社も多いと思います。

    何のためにアジャイルなのか?
    その答えとして、”お客様のためになるプロダクトやサービスを開発する”と考え、デザイン思考に着目しました。

    デザイン思考もアジャイル開発と同様に、新しい手法を導入するという点では同じため、単に方法論や手法の導入ではなく、それが必要な動機付けを行う取組みにチャレンジしています。

  • Liked Makiko Nakasato
    keyboard_arrow_down

    Makiko Nakasato - スクラムフレームワークの意義を問いなおす

    Makiko Nakasato
    Makiko Nakasato
    Consultant
    Mamezou
    schedule 1 year ago
    Sold Out!
    20 Mins
    Thought & Practice
    Intermediate

    みんな一体何を求めて、アジャイルに来たのか。作っただけで誰が読むかもわからないドキュメント。参加する人の90%が無意味だと思っているレビュー会議。「うちの会社の決まりだから」の一言で、繰り返される煩雑なプロセス... それがイヤだったんじゃないのか。

    ケース1

    「プロダクトオーナーなんだから、これをするべき」「これをしないならスクラムじゃない」「ユーザーストーリーはここまで書かないとReadyじゃない」... いや、ちょっと待て。「スクラムの決まりだから」で「かくあるべし」と言うだけならば、従来の開発プロセスと何が違うの?

    ケース2

    じゃあ逆を考えてみるか。「スクラムは理想論だから」の一言で、「要件定義スプリント」「テストスプリント」を是とする、CSMやCSPO。何がしたかったの?「スクラムやってます」って言いたいだけ?

    スクラムが理想論であるならば、現実のチームに対するコーチは、何をどう考えてチームに向き合うべきなのか。スクラムフレームワークとは何なのか。このセッションは、この1,2年で見聞きしたチームの実例を紹介しつつ、あらためてスクラムの枠組みの意義を考える時間にしたいと思います。