location_city Osaka schedule Jun 26th 01:00 - 01:20 PM place スポンサー#1 people 6 Interested

開発チームの改善

開発者からTechLeadになると、チームもシステムの一部だと気づきます。

ソフトウェアシステムを改善するように、私達はチームというシステムを改善することでユーザへより良い価値提供ができるようになります。

 

Tech Leadになったばかりの頃は、まだチームの問題を認識できておらず、ソフトウェアシステムの改善を行うことでチーム改善をしていました。

この改善は容易で、わかりやすいですが、問題の核にアプローチできず、部分的な問題を解決するにすぎません。

そのため一度立ち止まり、チームで話し合い、チームの問題を明らかにし、取り組むことにしました。

スケジュールと実績の乖離

私達のチームでは、開発スケジュールに対して実績が大幅に超えることが多々ありました。

正確なスケジュールを引くことは不可能ですが、一方でこの状態は望ましくありません。

実績が超える原因の多くの理由は、想定外の修正や要件です。

この問題に対処するために、チームでスケジュール作成に取り組むことにしました。

 
 

Outline/Structure of the Talk

  1. チームでの見積もりの改善
  2. チームでの開発方法の改善

Learning Outcome

  • チームの問題を解決するときの最初の走り方の例を知ることができる。
  • チームでスケジュールを引く方法・利点を知ることができる。

Target Audience

チームの問題に取り組み始めた人

schedule Submitted 1 month ago

  • Yoh Nakamura
    keyboard_arrow_down

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

    20 Mins
    Talk
    Beginner

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

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

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

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

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

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

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

  • 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

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

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

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

  • 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マップは自分の今の人生の様子をざっくり俯瞰することができるツールです。

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

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

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

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

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

     

     

  • Ryuku Hisasue
    keyboard_arrow_down

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

    45 Mins
    Talk
    Beginner

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

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

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

  • eroccowaruico  
    keyboard_arrow_down

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

    45 Mins
    Talk
    Beginner

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

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

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

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

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

  • Ikuo Odanaka
    keyboard_arrow_down

    Ikuo Odanaka - ニガテ意識を塗り替える〜いかに組織を変えていくか〜

    45 Mins
    Talk
    Intermediate

    自分が所属するチームでアジャイル開発に取り組み始めたのが数年前。

    新しくアジャイル開発に取り組みたいけれど、どう始めたらよいかわからない。実際に取り組んでみたけど、うまくいかないところがある。社内でそういった状況のチームから相談を受けることが、だんだんと増えてきました。

    一方で、導入に対するモチベーションが一様に高い、というわけではありませんでした。社内で勉強会や相談会を開催しても、来る人は来るし来ない人は来ない。相談にやってくるのも、課題を課題として気づいている人たち。
    積極的に「アジャイル開発は嫌だ!」と反発を受けることはありませんでしたが、消極性や無関心、というものがアジャイル開発を組織に浸透させていくにあたって課題となっていました。

    消極性や無関心の背景にあるのは、ニガテ意識。なにやら難しそうだと思っていたり、過去にアジャイル「っぽい」やり方に取り組んでうまくいかなかった経験が、変革の障壁となっていたのです。

    そのニガテ意識を塗り替え、変革へと向かう仲間を増やしていくためにはどうしたらいいのか。私が現在取り組んでいるアプローチは、大きく分けて2つあります。
    1つは、ボトムアップでの変革を支援すること。ふりかえりやインセプションデッキ作成などを支援し、成功体験を積んでもらうこと、そして自走することの後押しをしています。
    もう1つは、トップダウンで変革への動きを推進すること。これはごく最近始めた取り組みで、社内向けの「アジャイル研修」を企画し実践しています。

    この2つの取り組みを中心に、組織を変えていくために行っている取り組みについてお話させていただきます。

  • Mori Yuya
    keyboard_arrow_down

    Mori Yuya - シン・仮説検証 70,000枚の付箋で分かった仮説検証のエッセンス

    20 Mins
    Talk
    Beginner

    2012年に翻訳発売された『リーン・スタートアップ』を皮切りに仮説検証という考えが身近になりました。観察して仮説を立てて確かめるプロセスを通して、より効果的な手をうち、問題の解決やプロダクトの売上の成長につなげていく考えです。

    仮説検証は特別な行為ではなく、私たちは日常的に「いまこうなっているから、これをしたらこうなるだろう」と推論しています。これも仮説検証です。

    しかし一方でこんな声も聞きます。

    「仕事の中で仮説検証はやってみているけれど、本当にこれでいいのかいまいちピンとこない」

     

    私は『リーンスタートアップ』の登場以前から仮説検証の虜になり、この10年のあいだに書いた付箋だけで7万枚を超えました。そこで分かったことは、ちょっとしたポイントで善し悪しが大きく変わってしまうということです。

    このセッションでは仮説検証の質に悩んでいる方に向けて仮説検証のエッセンスを共有します。時間のかかる仮説検証のテクニックとは異なり、普段使いできるため日常で無理なく使えます。一言で、ここを押さえるだけですごくよくなるキモをお伝えします。

    特に、次のような仮説や問題定義を目にする方には抜群に役立つと思います。
    「時間がない」「スキルがない」「チームがうまく連携できていない」

  • Yoshio Miyake
    keyboard_arrow_down

    Yoshio Miyake / Koki Kawagoi / manami Ozawa - チームでものづくりするときに、心のなかで起こっていることを上手く使うには?

    90 Mins
    Talk
    Intermediate

    みんなで協調してものづくりをするときに、ひとりひとりの心の中では、どのようなことが起こっているでしょうか?それぞれの人のなかで、言語的であったり、イメージ的であったり、並行的に動いているのです。それを上手くものづくりに活用するための情報を認知科学の視点からお伝えできたらと思います。

    みなさんが、わかりやすく理解するためのアクティビティもご用意できたらと考えています。
    人数に応じて、少し参加者同士で話していただくかもしれません。

  • Shusuke Fujii
    keyboard_arrow_down

    Shusuke Fujii - コロナ禍における宿泊業の苦闘~ピンチをチャンスに変えた開発戦略

    Shusuke Fujii
    Shusuke Fujii
    Hotel
    Hoshino Resorts
    schedule 2 months ago
    Sold Out!
    45 Mins
    Talk
    Beginner

    星野リゾートでは、企業の発展とともに、開発の内製化の促進を進めており、海外展開など次の局面を迎えていた。
    しかし、2020年に入ると、全世界に混乱をもたらされたコロナの影響を受け、宿泊業には大きな打撃をもたらした。
    もちろん、星野リゾートも例外ではなく、今後にむけた開発は全て白紙になるだけでなく、事業の継続も危ぶまれる状況に陥った。

    そのような状況から、以下にして組織が同じ方向を目指し、短期間でリリースする体制を作り上げることで、危機的状況を脱し、飛躍できたのかをお話します。

  • Muneyoshi Iyama
    keyboard_arrow_down

    Muneyoshi Iyama - プロダクトの品質とユーザ視点の品質を考えてみる

    Muneyoshi Iyama
    Muneyoshi Iyama
    Engineer
    NTT COMWARE Corporation
    schedule 2 months ago
    Sold Out!
    20 Mins
    Talk
    Beginner

    NTTコムウェアはNTTグループの一員として、長年インフラを支えるキャリアグレード品質のシステムを提供してきました。
    そんな我々が変化への適応を求められる今の時代において、アジャイル開発でプロダクトを開発する際に考えている『品質』について一部ご紹介します。

    「つながってあたり前」「止まらないことがあたり前」というビジネス側やユーザーの期待と、アジリティ・価値を両立するために、
    参考にしているモデルや取り組み方の考えなど、アジャイル開発の品質を考えている方々にとって参考になる知見を提供できればと思います。

  • Yosuke Matsuura
    keyboard_arrow_down

    Yosuke Matsuura / Ken Matsumoto / Yasunobu Kawaguchi - 人間中心型リーダーシップ戦略論 ~ 過激な感情表現で関係を壊さないために

    45 Mins
    Talk
    Beginner
    本セッションでは、ゲーム制作会社で1メンバーとして新しい取り組みをしていくために重要なソフトスキルについて学びます。
    まずは、第一歩として、個人からできるコミュニケーションの改善について学んでみましょう。
    
    1. 修羅の国でのコミュニケーション入門 - 自分は悪くない、から脱却しよう
    2. 過激な反応で関係を壊してしまう前に - Emotional Science
    3. リモートワークは効果も問題も拡張する
    4. 責任に目を向ける - 責任逃れの構図
    5. チームの4つの毒
    6. アジャイル戦略論 - 何かを始めるときの6つのステップ
  • Yuki Misumi
    keyboard_arrow_down

    Yuki Misumi - チーム バーサーカーズ 〜狂戦士になれと言われた僕らの、がむしゃら1日スプリント

    Yuki Misumi
    Yuki Misumi
    Software Engineer
    Freelance
    schedule 3 months ago
    Sold Out!
    20 Mins
    Talk
    Beginner

    人生初の開発現場は、6人のバックエンドチームがFAPI-CIBAという世界最先端の認証認可サーバー実装をしながら、モバイルアプリや銀行業務システムの開発まで担当する戦場でした———

    毎日変わる要求と仕様。政治の絡む技術選定。立ち塞がる大量のRFC文書。

    僕たちは、高速でアップデートするチームになる必要がありました。スプリント期間は、2週間から1日になり、モブプログラミングには、知識の新陳代謝が組み込まれました。肥大していく技術分野に追いつくために、勉強タスクを設けて学びを共有しました。

    具体的な使いどころに関して、1日スプリントはプロダクトの方向性が定まっていない時に大変効果的でした。プロダクトオーナー側から細かいフィードバックが生まれ、プロダクト像がかたどられていくためです。モブプロは、新しい技術分野の実装時に、開発メンバー間の理解のキャッチボールを促した点で有用でした。

    このセッションでは、そんな狂戦士の如く戦場を舞った、ぼくらの取り組みと考察を1日スプリント/モブプロ導入事例として共有します。

    プロジェクトが始まったが、漠然とした課題解決方針のみで具体的な仕様はだれも言えない。。
    誰も対象の技術分野の経験がない。。
    これらの状況にある方にとって、日々の働き方のヒントになるような内容にしたいと思います。

  • 中村 薫(Kaoru Nakamura)
    keyboard_arrow_down

    中村 薫(Kaoru Nakamura) - リモートワークの課題をモブワークで解決する試み

    中村 薫(Kaoru Nakamura)
    中村 薫(Kaoru Nakamura)
    CEO
    HoloLab Inc.
    schedule 2 months ago
    Sold Out!
    45 Mins
    Talk
    Beginner

    リモートワークの課題をモブワークで解決する試み

  • Kazuyuki Taniguchi
    keyboard_arrow_down

    Kazuyuki Taniguchi - 鳥取のド田舎出身PMが見つけたチーム形成術!お風呂の焚き方

    Kazuyuki Taniguchi
    Kazuyuki Taniguchi
    ProjectManager
    NISSAY IT
    schedule 2 months ago
    Sold Out!
    20 Mins
    Talk
    Beginner

    金融系IT子会社にてプロジェクトマネジャーで奮闘中の谷口です。

    出身は鳥取県で、山奥に生まれ、子供のころのお仕事は薪でお風呂を焚くことでした。裏山から薪を取ってきて小屋に保管し、夕方になると薪にマッチで火を点けお風呂を沸かしていました。暑い夏の日も、雪が積もる寒い冬の日も、毎日・毎日、お風呂を焚くことが日課でした。

    そんな子供時代を過ごした私が、社会人となりエンジニアとしてシステム構築を担当し、大型のリニューアルを任されるPMとなった最近、ふと感じたことがあります。プロジェクトを成功させるカギは、「人」と「計画」。なかでも、多様な人で形成される「チーム」が担っているということです。そしてそのチーム形成は、子供のころのお風呂を焚くということとと、まさに考慮すべき点が一致していたのです。

    ・プロジェクトでは多種多様なメンバーが集まってきます。最初からやる気があるメンバーもいれば、モチベーションを下げていたり、口数少ないメンバーもいます。お風呂を焚く時だって同じです。全部が全部燃えやすい木はありません。中には湿っている木、なかなか火が付かない木、すぐに燃え尽きてしまう木、様々。

    → そんな多様なメンバーにたいして、どのように心に火を灯していければいいでしょうか。

    ・仕事だから強制すればよいという考えもあるかもしれません。ガスバーナーを使いますか?

    → それは、パワハラです。それ以上に、決して最後まで赤々とした炎で燃えることはないでしょう。

     

    今回のセッションでは、私自身が子供のころに経験した「お風呂を焚くこと」をテーマにして、チーム形成の試行錯誤をお話しします。チーム形成に絶対的な正解はありません。ただ、私の試行錯誤を、お風呂焚きのストーリーを通じて、みなさんと一緒に考えていくことができればと思います。

    世の中には「知識やツール」を知っているだけの人は数多くいます。でも、大切なことは「失敗しながらも実践していく」ことだと思います。

    聴講者のみなさんと、心の炎を扱うお話ができればと思います。

help