Interested日本のSIerと呼ばれる世界では、まだまだウォーターフォール勢力が強く、スクラムをはじめとするアジャイル開発の手法は、身近とは言いがたい状況かと思います。本を読んだり研修を受けてスクラムのことは知ってるけど、身近なプロジェクトはウォーターフォール前提ばかりで、実践の場がないと悩んでいる人もいるのではないかと思います。私たちのチームでは、ウォーターフォールでの大規模プロジェクトの中で、顧客や上位マネジメントとの関係は変えずに、チーム運営をスクラムで行うという試みを行いました。チームリーダーとしての運営上の課題、悩みを解消する試みとして始め、できなかったことも多々あるものの、一定の成果は出たと考えています。スクラムは、実践し、その中で考え、悩むことでしか上達できないと思います。いう点で、スクラムを知った初心者にとって重要なのは、実践できる場があることだと思いますが、スクラムが根づいていない組織では、そのような場を探すのも一苦労かと思います。どんなプロジェクトにもスクラムが合っているわけでは決してありませんが、身近な所でも実践はできるという気づきになればと思い、私たちのチームの試みについて報告します。Outcomeスクラムに合ったプロジェクトを探すのではなく、身近な所で実践の場を探し、すぐにでも始めようと考えられるようになる。スクラムをやったという内容は、正直誰でもいくらでも話せると思います。その観点から、このセッションの特異な点とは何なのでしょうか?一般の視点から、非常に興味があります。Replyお返事が遅くなり申し訳ございません。ご質問の点ですが、確かに「やってみた」という意味では、やったことがある人なら誰でも話せるという部分はあると思います。スクラムの適用が進んでいない組織が日本では少なからず存在すると考えており、その要因の1つに、自分たちの仕事や組織はスクラムには向かないと考えていることがあると感じています。実際、他の方のプロポーザルを見ても、SIerでのスクラム実践には旧来の手法を前提にした社内制度や上位層、社員に対し、どのように対応するかが壁になっている様子がうかがえます。私の周囲でも、そのような傾向がある一方で、実践してみると制約と思っていることはたいした問題ではなく、「単なる思い込み」あるいは「やらないための理由付け」ではないかと思うようになりました。本件では、実践者の観点で「確かにできる」「できない理由などない」と思ってもらうことを意識してお話しできればと考えています。Reply従来の手法から抜け出せない人たちが、自ら考えゴールを目指す機会になると良いですね。MinsKeynoteIntermediateある日本人ソフトウェアエンジニアが、アメリカ移籍後に体験したソフトウェア開発の変遷と学んだことをお話しします。会社全体で運用して見えてきた組織課題の解決の仕方について、お話したいと思います。妨害リストを運用するからこそ、客観的に「問題vs私達」にフォーカスすることができます。MinsTalkIntermediate全社にカイゼン文化が浸透していて、それぞれの現場で独自のカイゼンが実践されています。データ作成、インフラ、新規ビジネスなど、あらゆる部門で日々カイゼンが繰り返されています。総務や広報・販促のメンバーも「スプリント」「WIP」「レトロスペクティブ」など、アジャイル用語を日常的に使っており、コモンセンス化しています。一人の人間の力だけでそんなソシキカイカクはできるわけありません。そのリテンションのコツやマンネリ化を打破する方法など、根底に流れる価値観や私が実践する「たった一滴の魔法」を紹介します。会社も身体もリーン体質になる魔法です。皆さんと楽しく体を動かしながら、一緒に体験していきたいと思います。(名前は怖いですが、内容は恐くないですヨ!)イベント終了後、私たちが知らなかったデイリースクラムの一面を発見出来るかもしれません。Hell」をもとにしたワークショップです。StudyBeginnerこのセッションでは、アジャイルコーチとして様々な現場のふりかえりを観察、ファシリテートしてきた経験から得た“ふりかえり”の始め方と続け方をお話します。”ふりかえり”の目的は大きくは以下の2つです。自分達の仕事のやり方をもっとうまくできるようにすること(うまくできるやり方を考えるために)仕事の手を止めて立ち止まることこの目的を実現するために様々なことにファシリテートするスクラムマスターは意識することがあります(できれば参加者全員が)。どのようなデータを収集すればよいか?どういう話し合いのやり方をすればよいか?継続的にうまくできるように気をつけることは何か?また以下のような"ふりかえり"あるあるに出会うこともあります。ふりかえりといえばKPTとばかりに同じやり方をしてマンネリしてしまううまくできるようにするアイデアが実行されないなんとなく続いているんだけど効果がわからないこのようなトピックをお話することで、みなさんのふりかえりをよくするヒントになればと思います。StudyBeginnerぼくがディレクターをつとめる、Mackerelというプロダクトの開発チームは、東京オフィス・京都オフィス・愛知にあるエンジニアの自宅の3拠点体制で、3年以上開発を続けています。日常的にリモートチームで開発をしているのですが、リモートワークはメリットばかりではありません。このセッションでは、「リモートワークの難しさ」に焦点をあてます。リモートワークの何が難しいのか。チーム開発においてどのような困難や問題点があるのか。それでも僕たちがリモートワークを選択する理由やメリットは何なのか。赤裸々にお話しようと思います。StudyBeginnerモブプログラミングとはチーム全員で、同じ仕事を、同じ時間に、同じ場所で、同じコンピューターで行うことです。日本においても、2017年に一気に話題となりました。そのきっかけとなったモブプログラミングという働き方で紹介した楽天のモブ=チームがその後どうなったのかについてお話します。私達のモブでは、時間を決めてワークショップ形式で行うのではなく、朝来てから帰るまで働き方として実施しています。そのため、開発だけでなく資料作りや営業やモブプログラミングの体験会などすべてにおいてモブワークをしています。スクラムを中心としたアジャイル開発を精力的に行ってきたメンバーがモブプログラミングを通してどのように変化したのか実際に仕事の成果が出せたのかモブとその外の関係性はどうなのかモブ=チームのその後(※今後の活躍次第)などについてお話したいと思います。スクラムとモブプログラミングは、チーム全体のアプローチやチームビルディングという点で共通項も多い一方で、別の視点で仕事の本質やチームの本質について考えるきっかけになりました。モブプログラミングに興味がある方はもちろん、そうでない方にとってもチームについて考えるきっかけを得られるようなセッションにしたいと思います。StudyBeginner作るものに納得感がない、いつも納期に遅れる、改善ができない...このような問題を解決してチームワークを発揮するために、サイボウズでは2016年10月から私が所属するkintone開発チームでスクラムを導入しました。チーム全員が未経験の状態でスクラムマスターになり、沢山の壁にぶつかりながら試行錯誤を繰り返してきました。このセッションではサイボウズでのスクラム導入で取り組んだ活動をふり返りながら、開発プロセスや品質・チームの文化に起きた変化をご紹介します。他チームや他部署のみならず総務や営業の現場にまで及んだマインドセットの変化・アジャイルプラクティスの導入についてもお話します。アジャイルの考え方は開発以外の現場でも活用できることを実感し、現場改善や組織変革のヒントにしていただければと思います。PLoPで挙げられているパターンです。チームのコミュニケーションツールとして色々な現場で行われているお手軽な「オヤツ神社」ですが、チームが自分自身で管理・改善できる自己組織的な活動拠点でもある奥が深いものです。オヤツ神社の運営は簡単ではありません。現場もいろいろあるので、神主がどのようにオヤツ神社を実践しているかを聞いて、パターンの一端を感じてもらいつつ、明日には現場で“上手くいく”オヤツ神社を設置できるようになる発表にする予定です。最後にはみんなでオヤツ神社を建ててグランドフィナーレを迎えます。カッコいいオヤツ神社を建てられる技術はスクラムチームで働く我々にとっては必須スキルです。開発する、というもの。8月の募集開始後すぐに定員となってしまうほどの大人気ぶりでした。卒業後、何がしたいかモヤモヤ悩んでいるメンバーばかり。いわゆるモヤモヤ女子でした。誰もサービスの企画などしたことなどありません。そんな彼女たちが、プロダクトオーナーとなって開発チームを牽引し3ヶ月、サービスのプロトタイプまで作るほどまでに成長しました。参加者の皆さんと一緒に考える30分にしたいと思います。MinsTalkBeginnerスクラムやアジャイルソフトウェア開発の関係で「サーバント・リーダーシップ」という言葉を良く耳にする人も多いかと思いますが、しかし実際具体的にサーバント・リーダーはどのような特性を持っていて、どのように行動しているか等について聞くチャンスはあまりないのではないでしょうか。このセッションでは、サーバント・リーダーシップの詳しい定義、またサーバント・リーダーのスキルを向上させる方法について紹介します。サーバント・リーダーシップに関して、日本のマネージャーのどのような面がこれに適しているのか、そしてどの側面に改善する余地があるのかについてもお話しします。StudyBeginner何かを変えようと思っている。勉強会を開いてみたい。そんな事を考えるスタッフは社内にいると思いますが、「言って怒られたらどうしよう」「勉強会を開くのは、ちょっと怖い」などが頭をよぎり、一歩踏み出せない状況にいるスタッフがいるかもしれません。本セッションでは、周りを巻き込み継続し次につなげれるような心理的安全性を確保する活動の、想い、経過、時期に応じた対応に関してお話できればと思います。ReportIntermediate私達のチームは2016年までメトリクスの活用、スプリント期間の短縮、くじ引きで決めるPOやSM、などのプラクティスを通して改善を繰り返してきました。スクラムガイドもどんどん破りました。このチームはScrumが難しいなんて思っていませんし、誰でも出来ると信じています。チームが開発する製品は大きく変わりましたがScrumが難しいなんてことはありませんでしたし、なによりこのチームのエッセンスを大学生40名に導入したところなんと1週間で1日スプリントをモノにしました。Scrumが難しいのは幻想だったのかもしれません。我々のチームはこういったことを通して2017年にいくつかのプラクティスを確立しました。スプリント期間は1時間へ、チーム内ボトルネックへの対応時間は25分以内を保証、人的リソース活用の損益分岐点を常に意識できる開発プロセスです。結果、1週間でレビューを35回以上、振り返りを30回以上行っています。1週間で改善した項目は最大で20アイテムにおよび、それらのムダ取りによって6ヶ月間で最大2倍の成果を生み出しています。チームのパフォーマンスを最大化するために私達の計画的な学び方、偶発的事象からの学び方などをScrumの文脈でご紹介します。協調学習過程としてのスクラム。欲しいものを、どうやって知るか。MinsTalkAdvanced「人は、学び続ける動物である。いえるかというと、人が問題を解いていたり、新しい問題の解を見極めたりする時どういうことが起きているかを詳細に観察してみると、人は、何かが少し分かってくると、その先にさらに知りたいこと、調べたいことが出てくることが多いからだ。人はなにも知らないから学ぶのではなく、何かが分かり始めてきたからこそ学ぶ、ともいえる。P.13-14)多くの人がスクラムを利用して開発するものは、たぶんなんらかのソフトウェアサービスで、その先には利用者がいると思います。アジャイル開発やDevOpsでどれだけ技術的に研ぎ澄まし、円滑にリリースができるようになったとして、ターゲットとしている利用者像が間違っていれば、成果に繋がらず、投資や予算が尽きた時点で終わりです。過去のソフトウェア開発は、作ってすぐには顧客に届けることなんてできない前提で作られてきました。そのために、じっくりとテストを重ね、ビジネスインパクトを計算し、エンドユーザーに届くときには「絶対に使い物になる」ものを作ろうとしました。現代、作ってすぐユーザーに届けることは当然の事になりました。そのために、テストの自動化、クラウド、DevOps、A/Bテスト、カナリアリリース、マイクロサービスなどのプラクティスが普及してきたのです。プロダクトオーナーシップは汎用化が非常に難しい分野です。うまくいく方法は一つではないし、売れるということはすなわちユニークな優位性があるということであり、すなわちコピーできない。できたら簡単に優位性は失われるからです。その考え方まで理解を深めれば、取り入れられる部分が出てきます。本セッションでは、大手企業の中で、新規の事業開発を手がけられてきたパネリストの皆さんが、どのように予算をとり、新しいエンドユーザーの仮説を検証し、マーケットにアプローチして、小さな成功を掴み取ってきたか、話し合ってみたいと思います。(NTT西日本)本セッションプロポーザルに対してコメントにて質問をいただければ検討いたします。「改善をしているはずだけどトラブルが起きてからの事後対処になっている」などの経験をしたことはありませんか。当初想定していたプランで進めてみたけれど思っていたように作業が進められなかったり、始めたときには全く想定していなかった予想外の手戻りが多いのは作業プロセスのデザインに原因があるからもしれません。「プロばこ」はチームの作業プロセスのデザインと合意形成のフローをワークショップ形式で体験します。理想はチームで行う作業は一度決めたら変更せずに完了させたいところですが、現実には制約条件や前提条件を見落としていたり、気づかなかったりと認識できている情報からでしか作業プロセスを組み立てることはできません。計画時の作業プロセスをデザインする上で考慮が必要な条件や後からになって現場の作業を止めないように柔軟に作業プロセス自体を進化できる作業プロセスとするための考慮点を知ることができます。作業プロセスのデザインをチームで行うことでチームでの作業プロセスの合意形成を経ることで押し付けでない作業プロセスをチームのものとして取り入れ方も経験します。ReportIntermediate楽天において複数の新規・中規模サービスを担当しているECインキュベーション開発部を担当しています。配下組織の多くがアジャイル開発を導入していて、数年経過しました。アジャイルプロセスが進行すると改善は自然と開発に組み込まれますが、最近この進化の度合いが緩やかになり、一段上の組織を目指すには工夫が必要ではないかと思い至りました。その課題に対して部署横断の組織KPI目標を導入した結果、アジャイルの改善に期間テーマを付与すること、またその成果を共有による相乗効果を創出することが出来てきています。この事例の紹介とともに、複数アジャイル開発組織の運営において現在取り組んでいることを紹介できればと思います。StudyBeginner日本においてアジャイル開発プロセスは大分浸透して来ましたよね?そしてご存知のとおり、その中で最も認知度が高いのがスクラムです。ご存知のとおり、その中で最も認知度が高いロールがスクラムマスターです。(異論は認めます)さてこのスクラムマスター、主な役割はPO、Devチーム、組織を支援することです。この「支援」というのは奥深く、現場の状況によってやるべきことは千差万別だと思います。それ故、スクラムマスターが支援しているつもりでも実際のところ的を外していて結局のところただの雑用係と扱われたり、なかなか効果が出なくてモチベーション下がってしまったり、評価が伴わず心折れてしまったり、と報われづらい現実を目の当たりにすることがあります。そこで、フリーランスとして私が今まで流れ歩きながら関わったり見てきたりした現場のスクラムマスターの実態や事例に触れながら「スクラムマスターの理想と現実」を考え、ひいては「あなたの現場における理想のスクラムマスター像」のヒントが得られるセッションにしたいと思います。MinsTalkIntermediateScrumではプロダクトバックログを用意し、そこからスプリントが始まることが前提になっています。新たなプロダクトやプロジェクトを開始する際には最初からプロダクトバックログが用意されているわけではなく、ほかにも準備をしなければいけない項目が多数あります。本セッションでは最初にスプリントを開始する前までにやるべきことを過去のコンサルティング事例を踏まえて解説します。Zuill氏らが作り上げた、全員が同じ時に、同じ場所で、同じコンピュータ上で仕事をするソフトウェア開発手法です。準備するのは大きなディスプレイと、PC1台(2台あるとなお良い)。長机と、人数分の椅子。1人がPCを操作するドライバ、残りの人はドライバのガイド役、ナビゲータを担当します。15分くらいでドライバを交代しながら、みんなでプログラミングをします。以下の動画をみるとその様子が良く分かると思います。ConfEngine。