ベトナムでは COVID-19 が世界的に流行する以前より、日系企業のオフショア開発の縮小・撤退が散見されるようになってきました。ベトナム経済の継続的なえげつない高度成長により(コロナ禍でもGDPプラス成長)、コスト上昇が著しいのは事実です。コスト、品質、そのバランスなど悩みどころはたくさんあります。

ベトナムの開発では日系企業の場合、基本的には、通訳を通じての日本語もしくは直接英語でやり取りを行いますが、

言葉が通じることと、話しが通じることは違います。

要件を正しく伝える・相手の言いたいことを正しく理解する。ごく基本的で大切なことですが、特に国を超える場合、思考の背景にあるコンテキスト(カルチャー)を理解することが重要です。お互いが。

私は2014年12月からおよそ6年半、

  • ハノイ、ホーチミン
  • 案件を出す側・受ける側
  • 保守運営案件、新規案件、自社開発案件
  • ラボ型開発、受託開発
  • エンジニアがいるクライアント、いないクライアント

など様々な組み合わせで、PM、エンジニア、人事、経営などの立場でベトナムに関わってきました。

 

Made in Vietnam のソフトウェア開発を世界品質にすべく活動するなか、試行錯誤してきたこれまでの取り組み、現在の取り組みをシェアしたいと思います。

 
 

Outline/Structure of the Keynote

  • ベトナムのアジャイルを含む開発の現状と何故
  • 抑えるべきポイント
  • これまでの活動・取り組みの紹介
  • 現在進めているチャレンジ

Learning Outcome

  • ベトナムとどう付き合って行くか
  • ベトナムに限らずグローバルチームで開発を行う際に気をつけるべきポイント

などについて気付きがあれば良いなと思います。ベトナムに来る人(特にエンジニア)が増えれば最高です。

Target Audience

どなたでも

schedule Submitted 1 week ago

Public Feedback

comment Suggest improvements to the Author

  • Masayuki Nishida
    keyboard_arrow_down

    Masayuki Nishida / Kei Nakamura - スクラムチームが挑む!未熟プロダクト育成とビジネス成功への道

    45 Mins
    Keynote
    Beginner

    老舗大手製造業生まれの新規SaaSビジネスが1年目で直面した成長の壁、
    モダンアプリ開発会社が加わり組成した新スクラムチームが、ビジネス貢献に取り組み続けて成果を上げ始めています。

    「変化を目指す」老舗事業会社のPOと「変化を加速する」開発会社のScMが、体験や事実、その裏側にあった仲間の支援など、対談形式も交えてお伝えします。

    「スピード優先で事業化にこぎつけスタートしたSaaSプロダクト。その結果プロダクトが、早晩スケーラビリティや持続性を担保できず足踏み状態になる」…そんなビジネスあるある。

    今回題材となるSaaSプロダクトも、スピード優先でビジネスを始めた当初は数十社の顧客と密にやり取りを行い、フィードバックを製品に反映しながら良好な立ち上がりに見えました。
    しかし顧客数が増えるにつれ、事業会社が進めていた日曜大工的開発では開発スピードや品質が市場要求に追いつけなくなっている状態に、事業会社POは悩みます。
    (悩みの一例)
    ・PoCの延長で開発されたプロダクトのテスト、デプロイが人力依存で非効率な状態
    ・インフラやアーキテクチャが大規模顧客を考慮していない中でのエンタープライズシフト企画
    など。
    せっかくビジネスが拡大しそうなのに、さてどうしたものか。。。

    組織的な改善を水面下で続けていた老舗大手企業とモダンエンジニア集団が出会い協力しスクラムに取り組んだ軌跡

    登壇するPO、ScMが本プロジェクトで大切にしてるマインド

    [ PO ]

    対話を通してビジネスが目指していく姿、変化していく市場の生の声、背景を伝え続ける

    [ ScM ]

    POを含めたステークホルダへの状況の見える化と対話の機会を明示的に増やして活用してもらう工夫をしました

     

  • Jumpei Ito
    keyboard_arrow_down

    Jumpei Ito - アジャイル環境における品質プロセス - Janet Gregory & Lisa Crispin(動画放映)

    Jumpei Ito
    Jumpei Ito
    QA Engineer
    WingArc1st Inc.
    schedule 4 weeks ago
    Sold Out!
    90 Mins
    Keynote
    Beginner

    テスターを含むチーム全体(Whole-Team)で、プロセスやプロダクトに品質を作り込む(Build quality in)にはどうしたらよいでしょうか。
    Janet Gregory とLisa Crispinによるこの動画では、W.エドワード・デミング氏が提唱する「ビジネス効率を向上させるためのマネジメントの原則」と、それをアジャイルな職場で実践する方法について詳しく学べます。

     

    W.エドワード・デミング氏が提唱する「ビジネス効率を向上させるためのマネジメントの原則」で以下の2つの原則はJanetのお気に入りです。

    • quality is everyone's responsibility(品質はすべての人の責任)
    • improve quality you automatically improve productivity(品質を向上させれば、自動的に生産性も向上する)

    また、Janetがオリジナルで提唱する原則が以下の2つです。

    • if you focus on quality the speed will come(品質にフォーカスすればスピードが出る)
    • if you focus on speed the quality gets lost(スピードにフォーカスすれば品質が失われる)

    アジャイル環境において品質を考えると、「プロダクト品質」と「プロセス品質」の関係が重要となります。
    JanetとLisaは以下のような内容で特にプロセス品質についてトークします。


    1.Question Askerであるべき
    2.例やテストを使って開発をガイドする
     ・magic bubble(魔法の泡) コード・テスト・自動化
     ・Acceptance Testのループ(受け入れテスト作成→テストの拡大→自動化担当者とペア→テストメソッドの作成→何をテストするのかを明確化→TDDサイクル→ハッピーパスが通るまでリピート→探索的テスト)
    3.エクササイズ(ユーザーストーリーからテストを考える)
    4.アジャイルテスティングの4象限を使ってテストを把握する
    5.探索的テスト、品質属性のテスト、スライディング・スケール
    6.コアプラクティスを使う
     ・継続的インテグレーション
     ・テスト自動化
     ・機能やストーリーの優先順位付け
     ・ビジネス価値を頻繁にデリバリー(いつでも出荷可能なリリース候補を用意する)
     ・品質をデリバリー(コアプラクティスを用いて、会社やチームのあらゆる部分で品質を構築)

     

  • Fujihara Dai
    keyboard_arrow_down

    Fujihara Dai - アジャイルコーチの10年、スーパーアジャイルコーチの10年、ウルトラアジャイルコーチの10年

    45 Mins
    Keynote
    Advanced

    (あとでちゃんとかくかもしれない)

    2010年にフロリダで開催されたAgile conferenceに参加していらい、「よりアジャイルなチームを作るためには?」を考え続けてきたようにおもいます。僕の関心は常に「アジャイル開発」です。

    当初は企業内のアジャイルチームとして活動し、のちにアジャイルコーチと名乗るようになり、開発現場に立ったり、チームや組織開発を考えたり、「どうやったらもっとアジャイルになるか」を考え続けてきましたが、今もアジャイルコーチとして新しい現場に立つたびに、10年前と変わらず悩み続けています。

    10年の経験を得て、これまでにできてきたこと、まだできていないことをふりかえりながら、次の10年をスーパーアジャイルコーチとして現場を成功させ、その次の10年でウルトラアジャイルコーチとして過ごすために必要なことを考えるセッションです。

  • Kazuho Onojima
    keyboard_arrow_down

    Kazuho Onojima - 1500人、110以上のプロジェクトが並走するグローバル企業で品質改善活動に取り組んでいる話

    45 Mins
    Keynote
    Beginner

    スタートアップ企業のソフトウェア・サービス開発や、大手企業の新規事業開発を支援するSun Asteriskの開発拠点はベトナムにあり、約1500名の開発体制では常に110を超えるプロジェクトが同時に動いています。

    私達は最近までプロダクトを高速でデリバリーすること強みとしてきましたが、最近では”品質”を次のテーマとして取り組んでいます。
    品質が企業に与える影響は経営において非常に重要なものであり、その影響は長期的であると考え、
    私達のビジネスモデルの特性をふまえてQA2AQやAgile Testingなどを参考に、以下の観点でSun*のアジャイル品質定義と品質改善活動に取り組んでいます。

        1. 私達が提供するべきプロダクト品質 (技術/製品品質)
        2. 顧客が私達に期待するプロダクト品質 (技術/製品品質)
        3. 顧客がEnd Customer / Userに提供するべきサービス品質 (製品品質)
        4. End Customer / Userがサービスに期待している品質 (特に製品品質)

    今回はそんな私達の取り組みについてご紹介させていただきます。

    #Agile mindset #QA2QA  #AgileTesting  #Scrum #GIST Planning

  • Yoh Nakamura
    keyboard_arrow_down

    Yoh Nakamura - チームの状況にあったいろいろなタイプのスクラムマスターの見つけ方

    20 Mins
    Talk
    Beginner

    「どういう人がスクラムマスターをやればいいんだろうか?」

    この質問はチームがScrumに取り組もうとした時によく出てくることの1つです
    Scrumにあるプロダクトオーナー、スクラムマスター、開発者の3つの役割のうち、特にスクラムマスターはわかりにくいようで、この冒頭の質問が出てくるようです

    しかし、一方で、ScrumGuideには以下にあるようにスクラムが機能するにはとても重要な役割を果たします

    スクラムマスターは、スクラムガイドで定義されたスクラムを確立させることの結果に責任を 持つ。スクラムマスターは、スクラムチームと組織において、スクラムの理論とプラティクス を全員に理解してもらえるよう支援することで、その責任を果たす。

    では、どのような人がスクラムマスターに向いているのでしょうか?
    またプロダクト、チームや組織の状況によってどういうような人がスクラムマスターをするとより良いのでしょうか?

    このセッションでは、「どういう人がスクラムマスターをやればいいんだろうか?」という質問に、ギルドワークスの現場コーチとして70チーム以上(すべてにスクラムマスターがいたわけではありませんが)を支援してきた事例から自分なりの経験や考えをお話できればと思います

    よりよいスクラムマスターと出会える、見つける、なっていくヒントになれば幸いです

  • Takao Oyobe
    keyboard_arrow_down

    Takao Oyobe / kyon _mm - Deep Dive Experts - 達人が見ている世界を覗いてみよう -

    45 Mins
    Talk
    Beginner

    達人たちが見ている世界を覗いてみませんか

    「あの人はこの問題に対してなんて答えるんだろう?」
    「あの人はこの答えに辿り着くまでにどういう思考プロセスを経たのだろう?」
    「あの人の頭の中身が見てみたい!!」
    と思ったことはありませんか?

    同じようなプラクティスや手法を用いていても、人/チームによってまったく違う結果になります。
    つまり現場での成功には、形式的な方法だけでなく、それを扱う人の呼吸、思考、メンタルモデルが大きく影響しているということに他なりません。

    このセッションでは達人たちが見ている世界を覗いてみる実験をします。
    ある分野で研鑽を重ねる達人同士が、お互いにインタビューをすることでお互いの思考を探ります。
    ただのインタビューでは見ることができないDeepな世界にDiveしてみましょう。

  • Michael Migliacio
    keyboard_arrow_down

    Michael Migliacio - 「モンダイ」が現れた!ゲームでアジャイルを練習しましょう!

    20 Mins
    Talk
    Beginner

    プロダクト開発は難しいですよね。コミュニケーションとスキルがとても必要です。よくストレスいっぱいあります。

    でも、もしプロダクト開発がゲームだったら・・・

    コーチとして、開発チームと仕事を面白くなるためにたくさん実験を作りました。

    そのプレゼンには、アジャイルか開発を楽しくなるコツとゲームを紹介します。

  • Woohyeok Aaron Kim
    keyboard_arrow_down

    Woohyeok Aaron Kim - スプリント期間についての考察 : How to Find The Optimal Sprint Duration

    20 Mins
    Talk
    Beginner

    Intro

     現代社会学の本を読むと、ある言葉をよく目にします。それは「機能主義」という言葉です。これは、各役割を担当する人の集合体として社会を理解するというもので、生き残るために細胞が進化を重ねるように、社会も僕たち人間が状況に合わせて絶え間なく仕組みを変えていくという概念です。

    スクラムも同じ観点で理解することができます。人の集まりであるスクラムチームがどれだけアジャイルに時代のニーズに対応できるかで集団の運命が左右されます。僕はここでスクラムの成功の鍵として、スプリントの期間に注目したいと思います。

    スプリントの期間は絶対的なものではありません。よくプロダクトを子どもに例えることがありますが、まさに年齢によって子どものしつけを変えるのと同様に、状況によって常に見直しされるべきものがスプリントの期間です。

    このセッションでは、最適なスプリントの期間を探すために考慮すべき要素は何か、どういう時に期間の見直しをしないといけないかなどの考察を行います。

    時間の経過により変化し続ける条件のコントロールに対し、スプリントの期間がどれだけ重要なものか。

    この20分間の考察で成功の鍵を見つけられるように、みんなで一緒に頑張りましょう。

  • Ryuku Hisasue
    keyboard_arrow_down

    Ryuku Hisasue - 良いチームを形成する方法 〜リーダーのいない組織を大学生が挑戦〜

    45 Mins
    Talk
    Beginner

    このセッションでは,大学のPBL(Project Based Learning)でリーダーのいない組織を形成し,その活動の中でどのようにチームが成長してきたかをお伝えします.

    いま,日本の大学ではPBLという学習方法が広く実施されています.PBLとは,実際にプロジェクトチームを形成してプロダクトを作る経験を得ることによって,チーム開発やチームマネジメントの手法について学ぶことができる学習手法です.私が所属する大学でもPBLのカリキュラムがあり,スクラムを用いてプロダクトを作るという経験を得ました.しかし,私たちのチームはほかのチームとことなりリーダーを決めずに活動してきました.そして,その結果として,とても良いチームを形成できたと感じています.

    リーダーもいなく,開発初心者が集まるプロジェクトで,どのようなことに苦労したか紹介・分析し,どのようにいいチームに進化することができたのかお話ししていきます.

  • Kei Nakahara
    keyboard_arrow_down

    Kei Nakahara - 老舗メーカーにみんなでアジャイルを導入してみました ~「俺がやる!」から「みんなでやる!」に至るまで~

    Kei Nakahara
    Kei Nakahara
    Manager
    コニカミノルタ(株)
    schedule 1 month ago
    Sold Out!
    45 Mins
    Talk
    Beginner

    既存の組織体系やマインドが色濃く残る老舗メーカーで、健全なソフトウェア開発を実現できるよう全社的にアジャイルや要求開発の導入を推進してきました。

    2016年に、ほぼ私一人で始めた活動ですが、今では20名を超えるコーチングチームを組織するに至りました。
    一部の活動は私の手を離れ、完全に社内コミュニティを主体に運営されています。
    さらに、毎年開催している社内のアジャイルカンファレンスは、17年時点は約450名ほどの参加者だったのが20年には倍の約900名にまで増えました。
    さらにさらに、私が支援した社内のサービス開発チームが、SFOにプロポーザルを出すに迄いたりました。

    ここに至るまで経緯や具体的な施策、現在直面している困難と課題についてお話しさせて頂きます。

    現在の途中経過ではありますが、少しでも皆さんの参考になれば幸いです。

  • Sakano Nao
    keyboard_arrow_down

    Sakano Nao / Takeshi Fukasawa / yasuyuki kamitokusari - 【パネルディスカッション】オフショア×スクラム=モダンオフショアの取り組み

    45 Mins
    Talk
    Beginner

    クラスメソッド株式会社では、ベトナムの事業会社と共にクライアントワーク(受託)を行うことも多く、その中でもスクラムで開発することも多いです。

    弊社ではオフショア×スクラムを『モダンオフショア』と称して推進しており、そんなモダンオフショアのリアルな現場を、それぞれ別の案件に携わる3名のスクラムマスターとパートナーであるベトナムのオフショア事業会社から2名(予定)でお話していきます。

    本セッションではパネルディスカッション形式でお題に沿ってお送りします。
    現場の明るい部分だけではなく、暗い部分、成功から失敗まで忖度なく語っていきますのでご期待ください。
    またセッションの最後には、視聴者の皆様より質問を頂きお答えする時間も設けさせていただきますので、そちらも併せてよろしくお願いいたします。

    モダンオフショア/ クライアントワーク(受託)/ オフショア/ 海外/ スクラム開発 etc...
    何かひとつでも気になるワードがありましたら、ぜひご観覧くださいませ。

  • Yuichi Tsunematsu
    keyboard_arrow_down

    Yuichi Tsunematsu - "これから学ぶ" システム思考

    Yuichi Tsunematsu
    Yuichi Tsunematsu
    Manager
    Retty Inc.
    schedule 2 months ago
    Sold Out!
    20 Mins
    Talk
    Intermediate

    ふりかえりをして、改善案を考え、いろいろ手は打っているのに今ひとつ効果が感じられないことってありませんか? システム思考を使うと「ものごとの因果関係を整理し、テコ入れが効果的な箇所(レバレッジポイント)を見つけ、より根本的な問題解決を促す」ことができます。

    因果関係とは「開発者が増える→コード量が増える→開発スピードが上がる」というようなものです。他にも「コード量が増える→技術負債が増える→開発スピードが下がる」「開発者が増える→教育のため開発時間が減る→開発スピードが下がる」もあるでしょう。身の回りで起きている問題は事象はこのような複数の因果関係が組み合わさって起きており「開発スピードが上がらない」といった問題として認知されます。このような因果関係は図にまとめることで複数人で共有し、議論することで問題の真因に迫っていくことができます。便利そうですよね?

    しかしながらこのシステム思考、自分もきちんと勉強したことがなく、人にやり方・使い方を教えるのにも苦労をしています。Scrum Fest Osakaにプロポーザルを出してしまうことで締め切り効果の発揮を期待し、集中して学習・教育資料を作ってしまおうという企みです。"これから学ぶ"は私の現在の状態、そしてこのセッションでシステム思考を学ぶ皆さんの両方にかかっております。

    ※システム思考は広義と狭義のものがあるそうですが、本セッションでは狭義のものを扱います。

    システム思考 - Wikipedia

    このシステムダイナミクスの定性モデルをポピュラーにしたのが、ピーター・センゲの「The Fifth Discipline(ISBN 0385517254、邦訳『最強組織の法則』(徳間書店))で、同書は因果ループによるシステム思考をコアにしながら、ビジネスの組織と人間の行動、学習する組織について論じている。同書を契機にこの因果ループ図を活用したシステムダイナミクスの定性モデリング手法は、「システム思考」として広く利用されるようになった。

  • Yukio Okajima
    keyboard_arrow_down

    Yukio Okajima - 成功と失敗に学ぶアジャイル受託開発の極意

    45 Mins
    Talk
    Intermediate

    特にこの数年、日本の受託開発でもアジャイル手法が普及してきている実感はあります。しかし一方、アジャイル受託開発を、日々の当たり前として定着させる難しさも見えてきました。「顧客との関係」「メンバーの育成」「事業の成長」、これらはそれぞれ長い目で取り組む必要があり、かつ相互にトレードオフを含む適応的な課題でもあります。

    例えば、次のようなシチュエーションにどのように対応すると良いでしょうか。

    • 本来なら受けがたい一括請負によるアジャイル開発を将来有望な顧客から求められたら?
    • プロジェクトがピンチ!火消しをすべきなの?チームにまかせるべき?
    • ウォーターフォールとのハイブリッドの是非について顧客とメンバーの意見が合わないのをどうすれば?

    このセッションでは、受託アジャイル開発を生業とする私たちが、成功や失敗の体験を分析することでたどり着いた「アジャイル開発の組織定着に向けた一つの型」を提示させていただきます。私の立場上、どうしても受注側の視点がメインとなってしまいますが、発注側の方にとっても、ヒントになることは多いかと思います。

  • umisora (Katsutoshi Murakami)
    keyboard_arrow_down

    umisora (Katsutoshi Murakami) - スクラムマスターが去る日。

    20 Mins
    Talk
    Intermediate

    スクラムマスターがチームから離れられない。というのは事実なのだろうか。

    勇気が足りないだけなのだろうか?思い上がりなのだろうか?

    2年に渡って関わってきたチームからスクラムマスターとしてのロールを卒業することになった私が

    自立したチームにおける卒業に向けての取り組みと、その後の現状について共有させていただきます。

     

    2019年夏から新米スクラムマスターとして、コーチングを受けながらビルドアップした開発チーム。

    今ではLarge Scale Scrum (LeSS)に踏み入れるくらい成長したチーム。

    自立し、改善し、プロダクト価値を高めるための行動を取り続けている攻めるチームから、

    私はスクラムマスターというロールを降りることにしました。

     

    新たなるチームの旅立ちを迎え、ScMが離れる為にやったこと、チームの状況についてお話します。

  • Daisuke Kasuya
    keyboard_arrow_down

    Daisuke Kasuya - スクラムを軸に据えたキャリア戦略

    45 Mins
    Talk
    Intermediate

    幸運なことに、昨今のITエンジニアには多様なキャリアが存在します。わたしたちは、自分の得意分野を掘り下げ、また新しい分野を開拓し、およそ40年ほどの職業人生を歩んでいくことになります。

    スクラムという分野に目を向けると、「スクラムマスター」といった役割がまずは目に付きますが、「スクラムマスター」を専任で置いている組織はまだそんなに多くありません。では、スクラム(もしくはアジャイル)をスキルの中心に据えたキャリアの選択は難しいことなのでしょうか? わたしはそうは思いません。

    フロントエンドを得意とするエンジニア、インフラを得意とするエンジニア。この人達は「フロントだけ」「インフラだけ」を頼りにエンジニア人生を全うするでしょうか。おそらくそのようなことができる人は稀だと思います。皆それぞれ自分の得意分野を中心に据え、その周辺のスキルもうまく組み合わせながら多様なキャリアを築いていくのが一般的でしょう。

    スクラムについてのスキルも当然同様で、「スクラムマスター」で生涯を終えることを目指すのではなく、スクラムについてのスキルを得意分野として軸にしつつ、多様なキャリアをつくっていくことができるはずです。

    顧客に価値を提供できるソフトウェアを「上手につくる」ことに課題を持っている現場はたくさんあります。スクラム(またはアジャイル)を得意とする人は、これからもうしばらくの間は重宝されるのではないかと思います。

    このセッションでは、わたし自身のキャリアの経験を交えながら、スクラムについてのスキルを軸にキャリアをつくっていくにはどうすればいいか、について考えてみたいと思います。

  • 徳冨 優一
    keyboard_arrow_down

    徳冨 優一 - アジャイル開発の学び方

    徳冨 優一
    徳冨 優一
    代表取締役
    Degino Inc.
    schedule 2 months ago
    Sold Out!
    20 Mins
    Talk
    Beginner

    アジャイル開発に興味のあるみなさん、どうやって学んでいますか?

    XP の白本から始まったアジャイル開発。その後、たくさんの本が出版されてます。本に書いてあることは良さそうなのですが、実際にやろうとすると分からないことだらけだったりしませんか? スクラム開発をやってるとつもりだった自分のプロジェクトが "ミルクボーイがアジャイルを説明したら" のネタになっててハッとしたりしませんでしたか?

    そんなアジャイル開発の入り口にいる人たちに向けて、私がどうやって学んできたのか? 学び続けているのか? XP 白本の発売から 20 年の道のりをお話したいと思います。入り口から一歩進むきっかけにしていただければ幸いです。

  • Keisuke Ookura
    keyboard_arrow_down

    Keisuke Ookura - エピック大臣から始めるLeSSの導入

    20 Mins
    Talk
    Intermediate

    私たちはバックオフィス向けのSaaSを開発しているスクラムチームです。私たちは複数チームでスクラムを実践していくためにLeSS(Large-Scale Scrum)を採用しています。

    最初から全てのプラクティスを導入することは難しいため、まずは顕在化していたプロダクトオーナーのボトルネックを解消することから始めることにしました。

    この課題を解決するためにエンジニアがプロダクトオーナーの領域に越境するエピック大臣制を導入しています。(エピックとは複数のユーザーストーリーを束ねたユーザー価値の最大の単位を意図しています)

    エピック大臣がどのようにして誕生し、プロダクトオーナーのボトルネックを解消していったかを紹介させて頂きます。

  • Akiko Iwakiri
    keyboard_arrow_down

    Akiko Iwakiri / Junki Kosaka / Yuko Kondo / Koji Shimada / Tatsuya Sato / Yasuo Hosotani - あなたの一歩を後押しした本やあなたの手掛けた本について話してほしい!「旅するAgile本箱」LT #2 @スクラムフェス大阪2021

    45 Mins
    Talk
    Beginner

    昨年のスクラムフェス大阪で好評だった「旅するAgile本箱LT」再び!

    旅するAgile本箱は、これからアジャイル開発に取り組もうとしている人たちや既に実践している人たちのために、関連書籍を段ボール2箱、会社やイベントへ貸出す活動です。 これまでに24ヶ所へ旅してきました。 本のセレクトは、アジャイル開発実践者の投票により成り立っており、含まれている本の中には、一般に「アジャイル」「スクラム」や「ソフトウェア開発」に分類されない本も混じっています。 それら含めて、この本箱にある本たちは実践者を何らかの形で助け本たちです。

    今回の旅するAgile本箱LTも、実践者の皆さんを後押しした一冊、ないしは、心震えた一冊、ご自身で手がけられた一冊、かけた思いの丈を、語っていただきます!
    また、トーカー募集中です。紹介したい本がある方は、岩切までご連絡ください!

    ●お声がけした方々

    ・島田 浩二さん『ユニコーン企業のひみつ』
    ・細谷 康夫さん『Ultimate Agile Stories - 10th Anniversary』
    ・鳥居 雪さん:ダイバシティな絵本のご紹介
    ・佐藤 竜也さん『達人プログラマー 第2版』
      などなど

    ●ハッカーライフラボスタッフ
    ・司会:コサカ ジュンキ
    ・配信:近藤 佑子

  • Hiromi Morikawa
    keyboard_arrow_down

    Hiromi Morikawa - 創業145年の日系大企業でのアジャイルへの挑戦

    20 Mins
    Talk
    Beginner

    145年の歴史を持つ大日本印刷株式会社。
    時代の変化に適応し、印刷という名前からは想像できないほど、ものからシステム、SI案件から自社事業まで幅広いものづくりを行っています。

    そんななかで新規事業のシステム開発を担う、たった5人のスクラムチームからはじまり、
    現在では会社全体になかまができ、外部コーチの力を借りながらアジャイル推進を行うまでになりました。
    新規事業の開発チームしかいなかった状況から、プラットフォーム開発や受託開発での検討の話題にもなっています。
    当初は1チームしかなかった開発チーム。チームと人材は徐々に増え、会社としての取り組みが加速しています。

    開発チーム内での実践から「アジャイル推進」へ役割を変え、
    どのようになかまを作りムーブメントを広げていったのか、大企業内で推進に向き合ってきたなかでの工夫や苦労をお伝えできればと思います。

    大きな組織のなかで試行錯誤している事例のひとつが、みなさんの参考になれば幸いです。

  • umisora (Katsutoshi Murakami)
    keyboard_arrow_down

    umisora (Katsutoshi Murakami) / Masataka Sugiura - プロダクトバックログを作ってみよう!!

    45 Mins
    Workshop
    Beginner

    スクラム開発だ!!!!はもう古い!今は「プロダクトマネジメント」だ!

    何かしらの価値あるプロダクトを作る為に必要なのはプロダクトバックログである。

    スクラムはバックログに始まりバックログで終わると言っても過言ではないだろう。

    どれだけ開発が良くても作っているものに価値がなければ意味がないのである。

     

    と書籍で散々煽られるスクラムですが、ではプロダクトバックログはどうやって作っていくとスムーズなのでしょうか?

    マネーフォワード京都開発拠点で何度もトライしているプロダクトバックログの作成ワークを

    ワークショップとして疑似体験を提供してみたいと思います。

help