株式会社に入社しました。して、私は多くのことをイチから手がける必要がありました。テスト自動化に関する現状の把握、課題の明確化、達成すべき目標の提示、関係各者との協力関係の構築、そして施策の実施...。入社したばかりの人間がやることとしては、なかなかタフなミッションに見えるかもしれません。いざ始めてみると、自身の当初の想像をはるかに超えて、私は非常にスムーズにこれらを実施することができています。私がこれまで培ってきた、スクラム・XP・リーンなどのアジャイルの知識・経験の多くが、上記ミッションの実現に大いに活用できることが分かったためです。アジャイルの知識・経験は、新しいチャレンジを行う上で、非常に強力な武器となり得ます。当セッションでは、新しい会社・役割・ミッションのもとですぐに成果を出すために、また新しいチャレンジを行うために、アジャイルの知識・経験をどのように活かしていけば良いのかについて、自身の経験に基づいて具体的にご紹介させていただきます。して活動していくために役立つ、テスト自動化のスキルと方法論についてもお話させていただきます。Outcomeより大きな業務上の成果を出すために、自身のアジャイルの知識・経験を具体的にどのように活かせばよいのかを考え実践できるようになる。実際に成果を出すことができるようになる。新しいチャレンジを、確信を持って行うことができるようになる。Audience自身のアジャイルの知識・経験を活かして、より大きな業務上の成果を出したいと考えている人。新しいチャレンジを行おうと考えている人。Attendeesスクラム・XP・リーンなどの、アジャイルの実務経験を1-3年程度お持ちの人。投稿して採択された論文です。テスト自動化が、アジャイルな組織文化を構築するためのキーとなる可能性を持つことについてまとめたものです。しての活動のベースとしている考え方でもあります。発表させていただいた資料です。マネジメント層・デベロッパーとの協力関係を構築する上で、メトリクスが非常に効果的であること、またその具体的な活用方法についてまとめています。Reply投稿していただいてから大分経ってしまったのですが、個人的にコメントさせていただきます。一本プロポーザルを書けるのではないかと思いました。株式会社に入社しました。エンジニアやアジャイルのコミュニティの中で、キャリアパスについて語られることはあまり無いと思います。自分の偏見かもしれませんが、CSPOやCSPを持っている方は、当然アジャイルコーチやトレーナーになるもののように思っておりました。そこを、あえて肩書に「アジャイル」や「スクラム」と付かないポジションへ移ったこと、しかしながらそこでも尚、それまでの経験が役立つということを伊藤さんが示されたことで、アジャイルコミュニティの人たちにキャリアの多様性を感じさせることができるのではないかと思いました。いう思いから、上のプロポーザルからキャリアパスに関する部分にフォーカスし、別のプロポーザルとして出せるのではないかと思いました。投票の締切まで残り少ない中、票が集まるか読めないのです。キャリアについて整理し、まとめることは伊藤さんにとっても意義あることかと思いました。良ければ、新しいプロポーザルの投稿のご検討をお願いします。Replyコメントありがとうございます。持っている人間のキャリアパスとしての特殊性があると考えています。予定では、この点をこのセッションの導入部で3分ほどお話するつもりです。キャリアの観点についてまとめることは、私も興味があります。一方で、現時点だと社内調整が間に合わない可能性が高いこと、また採択されても1人1セッションという制約があると伺ったことがあることから、次回のプロポーザルで出させていただきたいと思います。Reply投稿ありがとうございます。実行委員としてではなく、個人の意見として以下のコメントを書かせていただきます。Craftsmanship」カテゴリに持っていくのもよいかなと思いました。(例年、技術セッションは少なめという傾向はありますし、ジョナサンの本が受けているようですのでタイミングも良さそう。伊藤さんとしては今更のテーマかもしれないですけど....)職場が変わって変わったところは、個人や会社の状況に依存するのでケーススタディ的になるのですが、むしろ、変わらなかったところに普遍性があるのかなと、推察いたしました。SETとしてプロダクトオーナーシップに寄与する、というところが主眼であれば、プロダクトオーナーシップでもよいと思います。一つの意見として参考になれば幸いです。Craftsmanship」カテゴリへの移動を前提に、内容を見直してみます。MinsKeynoteBeginner今回のRSGT2018、キーノートスピーカーのリチャード・シャリダンの著書『ジョイ・インク』の言葉を引用します”働いているときも、休んでいるときも、子供の学校にも、教会のコミュニティにも、家族のあいだに、国家に、誰もが喜びを求めている。人間は自身を超えるものを目指し、お互いにつながろうとするように、生まれついている。むかうために、仲間を求め、知見を求め、このカンファレンスならば得られるのではないかと思い、参加されたのだと思ってます。誰もが自分の人生のリーダーです。会社全体で運用して見えてきた組織課題の解決の仕方について、お話したいと思います。妨害リストを運用するからこそ、客観的に「問題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目標を導入した結果、アジャイルの改善に期間テーマを付与すること、またその成果を共有による相乗効果を創出することが出来てきています。この事例の紹介とともに、複数アジャイル開発組織の運営において現在取り組んでいることを紹介できればと思います。ReportBeginner日本のSIerと呼ばれる世界では、まだまだウォーターフォール勢力が強く、スクラムをはじめとするアジャイル開発の手法は、身近とは言いがたい状況かと思います。本を読んだり研修を受けてスクラムのことは知ってるけど、身近なプロジェクトはウォーターフォール前提ばかりで、実践の場がないと悩んでいる人もいるのではないかと思います。私たちのチームでは、ウォーターフォールでの大規模プロジェクトの中で、顧客や上位マネジメントとの関係は変えずに、チーム運営をスクラムで行うという試みを行いました。チームリーダーとしての運営上の課題、悩みを解消する試みとして始め、できなかったことも多々あるものの、一定の成果は出たと考えています。スクラムは、実践し、その中で考え、悩むことでしか上達できないと思います。いう点で、スクラムを知った初心者にとって重要なのは、実践できる場があることだと思いますが、スクラムが根づいていない組織では、そのような場を探すのも一苦労かと思います。どんなプロジェクトにもスクラムが合っているわけでは決してありませんが、身近な所でも実践はできるという気づきになればと思い、私たちのチームの試みについて報告します。StudyBeginner日本においてアジャイル開発プロセスは大分浸透して来ましたよね?そしてご存知のとおり、その中で最も認知度が高いのがスクラムです。ご存知のとおり、その中で最も認知度が高いロールがスクラムマスターです。(異論は認めます)さてこのスクラムマスター、主な役割はPO、Devチーム、組織を支援することです。この「支援」というのは奥深く、現場の状況によってやるべきことは千差万別だと思います。それ故、スクラムマスターが支援しているつもりでも実際のところ的を外していて結局のところただの雑用係と扱われたり、なかなか効果が出なくてモチベーション下がってしまったり、評価が伴わず心折れてしまったり、と報われづらい現実を目の当たりにすることがあります。そこで、フリーランスとして私が今まで流れ歩きながら関わったり見てきたりした現場のスクラムマスターの実態や事例に触れながら「スクラムマスターの理想と現実」を考え、ひいては「あなたの現場における理想のスクラムマスター像」のヒントが得られるセッションにしたいと思います。ConfEngine。