location_city Osaka schedule Jun 26th 10:00 - 10:45 AM place 金沢 people 8 Interested

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

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

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

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

 
 

Outline/Structure of the Talk

  1. アジャイル受託開発を始める
    1. アジャイル受託開発の定義
    2. 難しさの本質。顧客とベンダーの二人旅
    3. 現在地を知る
    4. エゴを捨ててお互いが向き合うために
  2. アジャイル受託開発を続ける
    1. 受託開発の成功って何?失敗って何? 
    2. ビジョンとしての「なんでアジャイル受託をやるの?」
    3. 「パートナーシップジャーニーマップ」によるマクロ視点マネジメント
    4. 事例にみるアジャイルパートナーシップジャーニー 
      1. ウォーターフォールからアジャイル
      2. 受託から共創
      3. 未経験チームによる冒険
    5. 同じプロジェクトは二度とない
    6. プロジェクトを積み上げても事業にはならない
    7. 失敗したアジャイルと成功したウォーターフォール。どっちが良い?
  3. アジャイル受託開発に終わりはあるか
    1. 内製化支援の是非
    2. 今後のSIer/受託開発ベンダーに期待される役割

Learning Outcome

  • アジャイル受託開発(事業|組織)のマネジメントに必要な視点
  • 所属組織にアジャイル開発を浸透させたいエンジニアに向けたヒント
  • 良い顧客、良いベンダーの見分け方、見つけ方

Target Audience

組織的にアジャイル開発に取り組むマネージャやエンジニア/アジャイル開発を組織に展開しようとするあらゆる方

Prerequisites for Attendees

特になし

schedule Submitted 2 months ago

  • Mitsuyuki Shiiba
    keyboard_arrow_down

    Mitsuyuki Shiiba - 誰も嫌な思いをしない変化

    45 Mins
    Keynote
    Beginner

    僕はこの10年間、色々なチームでスクラムをやってきました。でも、ちゃんとスクラムができたことはありません。それで良いんだろうなと思っています。そして、前に進むための選択をし続けているなら、それはもうスクラムと言ってしまってもいいんじゃないかと思っています。

    昨年サポートを依頼してくれたチームは、いくつかの課題を抱えていました。見にいってみると(と言ってもオンラインですけど)、全員が「しっかりがんばらなきゃ!」と全力で改善に取り組んでいたのに、うまく噛み合っていない状態でした。そんなチームも、今はもう「仕組みを改善する仕組み」がチームの中にできている状態です。自分たちで毎日、より良い開発ができるように試行錯誤しています。なにより、ひとりひとりが前を向いて自分に何ができるかを考えているのがとても良いなぁと思いながら見ています。

    そのサポートの中で、自分が今回挑戦したのは「誰も嫌な思いをしない変化」です。できていないことを指摘するのではなく、今みんなができることを見て、その頑張りがうまく噛み合う場所を一緒に探すことで、そのような変化を実現することができました。組織やチームに変化をもたらすということについて、今の自分の中にある2つの軸と、自分が実際に何を見て・どう捉えて・次の行動を選択しているのかという観察と選択のループを、以前の自分が陥っていた問題をまじえて、お話します。

    これまでの発表では、少しキレイに見える部分をすくってお話してきましたが、今回は自分の内側に触れてみようと思います。あんまり見せるものでもないかなとは思うんですけど、スクラムフェス大阪だから良いかなと思って。色んな人たちとの出会いの中で、少しずつ変化してきた自分の考えや、内側で起こっていることをお伝えします。たぶん今後は、もうこんな話はしないんじゃないかな。

    楽しんでもらえると嬉しいです。みなさんにお会いできるのを楽しみにしています!

  • Michael Migliacio
    keyboard_arrow_down

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

    20 Mins
    Talk
    Beginner

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

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

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

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

  • Yoh Nakamura
    keyboard_arrow_down

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

    20 Mins
    Talk
    Beginner

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

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

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

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

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

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

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

  • Kei Nakahara
    keyboard_arrow_down

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

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

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

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

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

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

  • Masanori Kawarada (Mark Ward)
    keyboard_arrow_down

    Masanori Kawarada (Mark Ward) - 独立QAチーム1年戦記:スクラムの外からチームと組織の品質を創る道 / An Independent QA Team's 1 Year's War: Way to Create Quality of the Teams and the Organization from the Outside of Scrum

    45 Mins
    Talk
    Intermediate

    English follows:

    「Scrum@Scale(S@S)を取り入れた100名ほどの開発組織で、スクラムに入らない独立したQAチームが活躍している」と聞いたら、もしかしたら奇異な感じを受けるかもしれない。スクラムではチームであらゆることが完結することを理想とするため、当然テスター(QAエンジニア・テストエンジニア ・などなど)もスクラムチームに入るべき、と考える方がスクラム実践者にとっては自然だからである。あえて、その自然に逆らって、私たちQAチームは独自のビジョンを掲げた「ビジョナリー・QA(Visionary QA)」として、独立した立場から品質向上という成果を上げようと奮闘している。このトークではそんな私たちQAチームの1年戦記をありのままに扱いたい。

    開発プロセスの高速化が進み、多くの企業でアジャイル開発が取り入れられ、過去の当たり前が当たり前でなくなっている中で、QA界隈ではどうやって価値を提供するか頭を悩ませている。あくまでもテストにこだわる者もいれば、スクラムマスター・プロダクトオーナーの視野を得るべく資格を目指す者もいる。2009年に翻訳出版されたリサとジャネットによる『実践アジャイルテスト(Agile Testing)』(翔泳社)は国内のテスターに広く読まれているが、最近版元品切になっていることもあり、手に入りにくくなっている。

    さて、テスターは異質な存在のひとつとして見なされている。ご存知の通り、スクラムガイドにはテストやQA活動をどのように行うべきか、言及されていない。3つのロールに「テスター」の文字は無い。よって、テスターのあり方はそれぞれの組織で模索するしかなく、特にテスターをスクラムチームに含めるべきか否かという議論は継続的に行われている。先にもあげたように、スクラム実践者にとってはテスターがスクラムチームに入ることは自然であると感じられ、実際そのようにしている組織が多いが、それぞれにメリット・デメリットがあることから、あらゆる組織で通じる答えは今のところ無さそうだ(テスターとして仕事をしてきたメンバーがスクラムチームの開発者の一員としてどれだけクロスファンクショナルに動けるか、という点が特にネックなように思える)。

    このトークは、独立した立場で動くことを選んだQAチームの話だ。スクラムチームにテスターを迎え入れねばならないと思っている方にはそうでない可能性を示す一方で、やはりスクラムチームに開発者としてテスターを加えるべきだと結論づけるオーディエンスもいらっしゃるかもしれない。スクラムチームとテスターの一筋縄ではいかない関係を、1年間の実例をもとに、一緒に考えようではないか。

    "In a 100-strong software development organization which runs Scrum@Scale, an independent QA team works well." ––it may sound strange to you. Ideally, in Scrum, everything should be done in one scrum team, so it is natural for Scrum practitioners that testers (QA engineers, test engineers, etc.) should join a scrum team. Daring to go an unnatural way, our QA team struggles to achieve quality improvement results from an independent standpoint as "Visionary QA" with its vision. I want to treat our QA team's year-long battle story as it is in this talk.

    Development processes are getting faster and faster. Many companies are incorporating agile development. The commonplace of the past is no longer the norm. In this fast-changing age, the QA industry is struggling to figure out how to deliver value.  Some testers are more concerned with testing, while others aim for the certification to learn a Scrum Master/Product Owner's perspective. The excellent book, "Agile Testing" by Lisa Crispin and Janet Gregory (Addison-Wesley), which was translated in Japan in 2009 by the domestic publisher Shoeisha, has been widely read by testers in our country. Recently, however, it isn't easy to get due to out of print.

    Testers tend to be seen as one of the heterogeneous entities. As you know, there is no mention in the Scrum Guide on how testing and QA activities should be done. There is no "Tester" in the three roles of Scrum. Therefore, each organization has no choice but to explore the nature of testers. In particular, there is an ongoing debate on whether or not testers should be included in Scrum. As mentioned earlier, it seems natural for Scrum practitioners to have testers join Scrum, and indeed many organizations are doing so. Still, since each has its advantages and disadvantages, it seems that we don't have an answer that works for all organizations at the moment. One of the problematic points appears to be how well testers can work cross-functionally as a "Developer" in Scrum.

    With this session, which is about a QA team that chose to work independently, some attendees who feel testers should join a Scrum team may get a chance to notice the other possibility, and others may conclude that Scrum teams should still include testers. Let's take a look at the tricky relationship between Scrum and testers with the help of a year's worth of examples.

  • Tomonori Fukuta
    keyboard_arrow_down

    Tomonori Fukuta - 組織文化醸成の理想と現実〜田舎で15年スクラムしたらカルチャーバブル爆発するでしょ!え、しないの?〜

    20 Mins
    Talk
    Advanced

    ちんもです。

    ちんもが所属する企業グループには、社会に誇れる理念と(野中さん流に言うと)腹にズシンとくる価値観や行動原則があり、併せて組織文化を醸成するための様々な施策が実施されています。

    組織文化醸成のための部署(!)があり、毎週の様に動画が配信され、経営陣から新人に至るまで、組織文化に関する理解度把握アンケートやe-larningを繰り返し、価値観や行動原則の実践が評価制度、表彰制度に組み込まれるなど、まあやれることは全部やってるんじゃないかと思います。

    じゃあもうグループ社員全員「価値観の体現者!」とか、「創業者の意志を継ぐもの」、みたくなってるかというとそういうわけでもないんですよね。それだけ文化をつくるということは難しいのだと思います。ところで弊企業の掲げる価値観、最近すごくアジャイルぽいやつに変わりました。え、変わっていいもんなんだっけ?あ、そうですか。あなたも変えたいんですね。いいけども。

    一方でちんもにはちんもなりに生きているなかで、アジャイルと出会い、現状をそうではない方向へ変えていこうとするなかで、その手段としてちんも風アジャイル組織の文化を産み出そう、広めよう、としてきたのかもしれません。

    そんなこんなで入社して4半世紀、曲がりなりにもチームをリードするようになってからは15年、そういうことをしてきたわけです。

    しかし僕は文化をつくろうとしたのだろうか。軽々しくそんなことは言えるのだろうか。

    ただ、己がやりたいことをやるために、周囲を巻き込み、だまくらかし続けてきただけのことではないのか。僕がいなくなったらそれまでなのか。では今お前がやり続けていることはなんなのか。

    個人が自分の周囲に存在する文化を変えようとする試みと、企業が掲げる文化はどう交わるのか。

    自律的に発生する既存組織文化への抵抗組織文化たるカルチャーバブルは、企業の文化をどうしちゃうの?

    15年をふりかえり、チームの文化と企業の文化に結果的に影響があった可能性が高いと思われる行動を洗い出し、そこから何かしら見えてくるものを探してみたいと思います。

    (長々と書きましたが、本発表は「田舎で十年スクラム」シリーズであり、ちんもとその仲間たちの定点観測コンテンツとなっております)

  • Kazuki Mori
    keyboard_arrow_down

    Kazuki Mori / Takahiro Kaneyama - ふりかえり手法のおもちゃばこ〜最近生まれた新しいふりかえり手法をお届け!〜

    45 Mins
    Talk
    Advanced

    みなさん、ふりかえりは楽しんでいますか?
    うんうん、いいですね!私はすっっごく楽しんでいます!!

    この2-3年、ふりかえりのことを発信する人たちが増えてきました。
    日本で初開催された  ふりかえりカンファレンス では、22名もの人がふりかえりの想いや新しい手法を語っています。
    また、ふりかえりamでも、Podcastの中でゲストが様々な手法を紹介してくれ、新しい手法も生み出されています。

    日々、新しい手法が生み出されているふりかえり。

    このセッションでは、近年生み出された手法を紹介していきます。
    どれも楽しくわくわくする手法ばかりですので、気になる手法を真似してみてくださいね!

  • Fujihara Dai
    keyboard_arrow_down

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

    45 Mins
    Track Keynote
    Advanced

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

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

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

  • Yuya Kazama
    keyboard_arrow_down

    Yuya Kazama - 開発が加速していくために、テストコードを書き始める前から考えるべきテストの話

    Yuya Kazama
    Yuya Kazama
    QA Engineer
    BizReach Inc.
    schedule 2 months ago
    Sold Out!
    45 Mins
    Talk
    Beginner

    システム開発において、テストは切っても切り離せない存在です。
    しかし、「カバレッジを満たすために書いている」「テストコードは書いたが、本番でトラブルが多発している」となっていませんか?
    実は、テストコードを書き始める前に既に勝負は決まっています。

    本セッションでは、実際に例題を使って皆さんにも考えてもらいます。そして、作業ではないテストについて“体験”し“実感”してもらいます。

    本セッションの体験を通じて、「開発エンジニア」「テストエンジニア」がともに考えて作り出す、一歩先行くテストの世界をご紹介します。

  • Yusuke Amano
    keyboard_arrow_down

    Yusuke Amano - すべての社会人に知ってほしい仕事の基礎としてのアジャイル/スクラムの話

    Yusuke Amano
    Yusuke Amano
    ScrumMaster
    Cybozu
    schedule 2 months ago
    Sold Out!
    45 Mins
    Talk
    Beginner

    アジャイルやスクラムについて学び始め、実際に取り組むと、その原則や考え方がソフトウェア開発の領域に閉じないことを日々実感します。原則を日々の仕事・生活に活かすことは重要ですが、「アジャイル」という言葉は抽象度が高く、開発のイメージも強いため、一般化してエッセンスを伝えるのに苦労している方も多いのではないでしょうか。

    スクラムマスターとして、開発に限らず組織の全員が、アジャイル/スクラムの原則を理解して、実践できるよう支援することは重要な活動です。サイボウズでは、数年前から新卒の全社員(+希望者は誰でも)向けの基礎研修としてアジャイル/スクラムの話をインプットしています。

    こちらのセッションでは、サイボウズ社内で実施している研修(講義)を社外向けに再編成したものをお届けします。アジャイルやスクラムの考え方をベースに、エンジニアに限らず、チームワークを高め、成果を届ける仕事の進め方の基礎となる考え方・プラクティスを紹介します。

  • Koki Kawagoi
    keyboard_arrow_down

    Koki Kawagoi - スクラムマスターの任命&育成法の紹介2 〜学習科学に基づいた解説を添えて〜

    45 Mins
    Talk
    Intermediate

    皆様は、組織でスクラムマスターをお願いするときに困ったりしていませんか?
    また、スクラムマスターが、成長していると感じますか?

    多くのチームの見てきましたが、スクラムマスターの任命時から育成において
    うまく仕組みが作れている組織はあまりありません。

    スクラムマスターの任命にうまくいかなかったり、育てられないと、
    スクラムチームのアウトプット・アウトカムの向上がすごく遠回りになってしまいます。

    そこで、これまで私が実施してきた方法を学習科学の観点から解説しながら、
    スクラムマスターとしての任命から育成の方法について紹介します。

  • Yuichi Tokutomi
    keyboard_arrow_down

    Yuichi Tokutomi - ゲームのように学ぶアジャイル開発

    Yuichi Tokutomi
    Yuichi Tokutomi
    CEO
    Degino Inc.
    schedule 5 months ago
    Sold Out!
    20 Mins
    Talk
    Beginner

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

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

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

  • Junki Kosaka
    keyboard_arrow_down

    Junki Kosaka - スクラムから見る野中郁次郎先生と組織変革

    20 Mins
    Talk
    Intermediate

    RSGT2021をきっかけに2冊の本を読みました。

    『知識創造企業』と『ワイズカンパニー』。

    この中で語られている、
    組織がよりいきいきするを、みんなで実現することに
    とても魅せられてしまい、野中郁次郎先生のファンとなりました。

    20年前に語られていた野中先生のお話を、
    スクラムを学んだ目線で読み解いてみると、
    非常に面白い要素がたっぷり詰まっていました。

    野中先生は、1986年に『The New New Product Development Game』という、
    スクラムの原点となった論文を書かれたことでも有名です。

    そんな切っても切れないスクラムと野中郁次郎先生について、
    にわかファンのJ.Kが熱狂したポイントを語り尽くします。

  • Takeshi Kakeda
    keyboard_arrow_down

    Takeshi Kakeda - 個人から始める変化 〜 IKIGAIマップ、マルチ・ポテンシャライト、ザ・メンタルモデルを入口にして〜

    Takeshi Kakeda
    Takeshi Kakeda
    Owner
    Zensow
    schedule 2 months ago
    Sold Out!
    90 Mins
    Workshop
    Intermediate

    a4310d2b6582d11a5058a7031d619a09.png

    チームを「アジャイルなチーム」にどう変容させるかという点に苦慮されている方は多いと思います。

    「チームの動きがなかなかうまくいかない」「あの人が変えられない」「自分のやり方が間違っている」などと悩んでいる方もいるのではないでしょうか。

    そんな時は、一呼吸おいて「チーム」や「他者」ではなく「自分の内面」に目を向けてみましょう。

    本セッションでは、チームではなく個人、他者ではなく自分に着目して「自分が変わることで、チームが変わる」という可能性を探ります。

    登壇者は、2000年から、XP、スクラムをはじめとする様々なソフトウェア開発、アジャイルの手法・思想・価値体系、パタン・ランゲージやネイチャーオブオーダーなどの周辺の思想も含めて探求してきました。そして現在着目しているのが「個人の変容」です。

    Kent Beckは以前、来日した時に「Social change starts with you.」と言う言葉を残しています。本セッションでは「自分が変わる」ということはどういうことなのかをワークを通じて探求していきます。

    まず最初に、IKIGAIマップによって自分の今を客観視してみます。IKIGAIマップは自分の今の人生の様子をざっくり俯瞰することができるツールです。

    その後、「マルチポ・テンシャライト」という「器用貧乏」を肯定的に捉える考え方をご紹介した後に、自分の内面に目を向けるワークをおこないます。

    最後に、「ザ・メンタルモデル」をヒントにして、自身の無意識の振る舞いがどのような現実を作っているのかを見つめます。

    自分を内観することで、どのように認知が変わるでしょうか?「そこにあるものを、ある」と認めることで何が変わるでしょうか?

    そして、結果として自分の周囲がどう変化するのでしょうか?

    様々な手法や考え方を紹介しながら、他者ではなく自分を見つめ、チームが変わるのではなく、自分が変わることで世界が変わるという意味とはどういうことかを一緒に探求しましょう。

     

     

  • Takao Oyobe
    keyboard_arrow_down

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

    90 Mins
    Talk
    Beginner

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

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

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

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

  • eroccowaruico  
    keyboard_arrow_down

    eroccowaruico   - 戦いません勝つまでは(弱虫が学んだ大切なこと)

    45 Mins
    Talk
    Beginner

    開発のマネージャー職として採用されたはずなのに、
    気がつけばなぜかユーザー部署でのオペレーター業務をやらされ、
    エンドユーザーからの電話を取ることになった弱虫のeroccowaruico。

    サポート対象はバグだらけで仕様も不明確で資料もない大規模展開システム。
    エンタープライズ環境に理解のないシステム開発部署とエンドユーザーの板挟み。
    そして僕に下される開発部署とのコミュニケーション禁止の判断。

    嫌なことから逃げることしか出来ない弱虫はチームのメンバー、そしてエンドユーザー、何より自分を守るためにユーザー部署内で小さなプロダクトマネジメントとエンジリアリングマネジメントを行い、ユーザー部署からそのシステムを支えるプロダクトを作り上げ、数万人のユーザーに届ける事にしました。

    理不尽にも思える状況の中、ユーザー部署内でひっそりとプロダクトマネジメントとエンジニアリングマネジメントの手法を適用し続ける。
    その目的とその中で起こした変化をお話しします。

    (本発表は守秘義務に反しない内容とするため、脚色や匿名化を行なった内容となります。実際の会社名、案件内容は一切お話できません)

  • Tsukasa Yokoyama
    keyboard_arrow_down

    Tsukasa Yokoyama / Koichi Yanagimoto - 俺たちのDiRT - 継続的な訓練と振り返りで障害対応力をUPしよう

    45 Mins
    Talk
    Intermediate

    私達は、楽天グループ内の様々なサービスから利用されるプラットフォーム系サービスを幾つか担当しており高いSLAが期待されています。

    そのため万が一システム障害が発生した場合、迅速な原因追求と復旧作業が必要となります。

    その反面、トラブルシューティングスキルは属人化しやすく体系立てて引き継ぐのが難しいという課題を感じていました。

    そこで、私達はDiRT(Disaster Recovery Training)と呼ばれるプラクティスを参考にし、定期的にStaging環境で擬似的な障害を発生させObservabilityの改善や、レポーティングまで含めたプロセスの見直し、モニタリングツールやシステムそのものの改善を行うため(障害訓練→振り返り→対策実施)を繰り返しています。

    今回は我々の活動についてご紹介させていただきます。

  • Akiko Iwakiri
    keyboard_arrow_down

    Akiko Iwakiri / Junki Kosaka / Yuko Kondo / Noriyuki Nemoto / Ryutaro YOSHIBA (Ryuzee) / Koji Shimada / Tatsuya Sato / Yasuo Hosotani / YUKI TORII - あなたの一歩を後押しした本やあなたの手掛けた本について話してほしい!「旅するAgile本箱」LT #2021

    90 Mins
    Talk
    Beginner

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

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

    今回の旅するAgile本箱LTも、実践者の皆さんを後押しした一冊、ないしは、心震えた一冊、ご自身で手がけられた一冊、かけた思いの丈を、語っていただきます!

    ★旅するAgile本箱LT2021:発表順(予定)

    1. 前説:旅するAgile本箱って?
    2. 細谷 泰夫さん『Ultimate Agile Stories - 10th Anniversary』
    3. 根本 紀之さん 『ソフトウェアテスト技法練習帳』
    4. 鳥井 雪さん  「ダイバシティな絵本」のご紹介(順不同)
      『王さまと王さま』 『いろいろいろんなかぞくのほん』 『ふたりのママの家で』 『ジュリアンはマーメイド』 『タンタンタンゴはパパふたり』『ねえさんの青いヒジャブ』『300年まえから伝わる とびきりおいしいデザート』
    5. 吉羽 龍太郎さん「エンジニア的翻訳術」
    6. 近藤 佑子さん 「大学生に『書くこと』の授業をしたときに引き合いに出した本」
    7. 佐藤 竜也さん『達人プログラマー 第2版』
    8. 島田 浩二さん『ユニコーン企業のひみつ』
    9. 結び

    ●ハッカーライフラボスタッフ
    ・司会:コサカ ジュンキ
    ・配信:アジャイル札幌のみなさん

  • aki matsuno
    keyboard_arrow_down

    aki matsuno - コミュニティ活動で得られた知識と希望~オンライン勉強会に半年で200回参加して感じたこと~

    aki matsuno
    aki matsuno
    engineer
    -
    schedule 2 months ago
    Sold Out!
    20 Mins
    Talk
    Beginner

    完全未経験&文系でソフトウェア開発の道に飛び込んで3年半、仕事で少しずつ成果が出せるようになったものの、度重なる挫折と大きな無力感を抱いていた自分は、藁にも縋る想いでオンライン勉強会への参加を始めました。

    そこで出会ったのは、アジャイル開発をはじめとしたソフトウェア開発を豊かにする多種多様な知見と、常に変化を楽しんでお互いに刺激を与え続けているコミュニティの方々でした。

    素敵な出会いに囲まれた自分は、焦燥感から参加していた勉強会が楽しくなるばかりか、これまで嫌いだった"学ぶ"という行為が楽しく感じられるようになりました。
    気が付くと、物事を継続することが苦手だった自分は毎週勉強会に参加して毎日読書するようになり、200回の勉強会参加&100冊弱の読書をしていました。

    そして、コミュニティの方々と一緒に学びを深めるにつれ、知識が身につくのみならず"自分自身と向き合うこと"の重要性を意識するようになりました。

    今回は、自分がアジャイル開発や様々な学問から学んだ知識やもらった希望、そして自分に多数の知識と驚くほど大きなエネルギーをくれたコミュニティの方々の話をしてみようと思います。

  • Yotaro Takahashi
    keyboard_arrow_down

    Yotaro Takahashi - もしもエンジニアリングマネージャーが妻のアメリカ出張を一年間経験することになったら

    45 Mins
    Talk
    Intermediate

    My Wife Went To U.S.

    それは突然のことでした。「ねぇ、4月からアメリカ行っていい?」

    そこから始まる父と小学生の息子2人、トイプードルの娘1人との1年間の情熱ワンオペ育児。たくさんの不安がよぎります。しかし、この困難に正面から立ち向かうことにしました。自分の道具箱にはエンジニアリングマネージャーとしての経験があります。これをどうにか活かすことはできないかと取り組みを始めます。

    エンジニアリングマネージャーが家事育児にトライしてみると?

    実際に取り組みを始めてみると、自分のこれまでのエンジニア、マネージャーとしての経験が多くの場面で活かせることに気がつきます。実際に経験したものの一例は下記のようなものです。

    • あ、冷蔵庫行ったり来たりすると面倒だな(TPSのムダの発見と解消)
    • 仕事をどう調整つけようか、不安がる実家の親をどう安心させようか(ステークホルダーへの透明性)
    • ホットクック(自動化)
    • 水回り、お金払ってピカピカになるととってもアガるし効率がいいな(アウトソース)
    • 料理代行、ただ作ってもらうだけだとそんなに楽にならないな(リーンソフトウェアの「全体を最適化する」)
    • 大根が嫌い? なら千切りにして味噌汁に入れたらどうなるかな?夕飯で試そう(高速に実験&学習する)

    これらの活動を通して、苦労していたワンオペ育児もだんだんと楽しく、より良くなるように感じています。また、今までの経験・知識をワンオペ育児へ再適用することで、これまでの経験にもより深い理解にたどり着きました。

    このセッションについて

    このセッションでは、私が実際に経験した家事・育児での困難さを、自分のエンジニアリングマネージャーとしての経験から見たときにどう見立てられるのかを学び、どう戦っていったのかを話します。その中でのフィードバックループを回す中で、自分が持っているアジャイルやソフトウェアの知識もより深い理解にたどり着いたように感じたので、その学びについてもシェアします。

    アジャイルな思想や方法論をどのように適用したら良いのかがわからず困っている人がもしいれば、このセッションを聞いてみませんか? ソフトウェア開発とは全く異なる対象領域ですが、アジャイルな家事育児を通して、理論と実践、思想と方法論がコネクトできるヒントになると思っています。もちろん日々の家事・育児に悩んでいる人も参考になるTIPsが多いと思いますので、参考にしていただければ幸いです。

help