札幌で開発している「Dr.Sum」という純国産データベースエンジンをどのように開発しているかをお話しさせて頂きます。

ところで、データベースエンジンをどのように開発しているかを皆さんご存じでしょうか。

データベースを使った業務システム開発やデータベース設計については、本になっていたり、Webに色々と情報が載っています。

ただ、データベースエンジンそのものの開発についてはほとんど情報がありません。（私が知らないだけかもしれませんが。。。）

そんなベールに包まれたデータベースエンジンの開発をどのように開発しているのかを紹介します。

開発当初は実装だけやって、テストは他の会社にお願いと丸投げする開発を行ってきました。

ただし、これでは品質の良いプロダクトは生み出せないことを様々なイタイ失敗を経験しながら、より良い開発プロセスに少しずつ改善してきました。

アジャイル開発のエッセンスを取り込みつつ、自分たちなりにカスタマイズした開発プロセスを紹介します。

データベースエンジンは複雑な集計やデータ更新のSQLを扱います。

もし間違ってデータを格納したり、誤った集計結果を返したら大惨事！

そうならないようにテスト自動化がとても重要です。

テスト自動化をどのように行っているか、開発中に実行される自動テスト環境をどのように構築しているかも紹介します。

データベースエンジンというニッチな領域の開発プロセスの話ですが、

開発者とQAが協力し合いながら札幌でがんばって開発している会社があるんだというところをお届けできればと思います。

スクラムマスターのトレーニングを完了した直後にスクラムマスターがハマる罠。
その一つに、トレーニングで得た知識をそのままチームに適用する！というものがあるのではないでしょうか？
知識の押し付けですね。

私も初めてスクラムマスターに挑戦したとき、思いっきり失敗しましたw
トレーニングでこう教わったからこうなんです！！！
あぁ、恥ずかしい…

月日は経ち1年半後、新チームの立ち上げに関わることに。

初挑戦の失敗と、それまでの経験を活かして取り組むことを心に誓い臨んだチーム作り。どのように取り組んだのでしょう？

知識の押し付けで失敗した初挑戦。
それなら、知識は教えない！教えるにしても最小限。

体験を最大限に活かす！

開発者にスクラム経験者が1人いたものの、はたして教えるより体験重視の方針で上手くいくのでしょうか？

チーム開始時点でのスクラムの意識はこれくらい。

• スクラムのイベントは全部やってみよう
• スクラムの作成物は全部作ってみよう

各イベントと各作成物の概要だけ伝えて、いざスタート！

当然のことながらスタート時点ではイベントをこなすだけ、プロダクトを作るだけ、とりあえずやってみてます！の活動が続きます。

そんなチームですが、
チームで良い活動をしていこう！
良いプロダクトを作っていこう！
そんな気持ちは持っています。
ふりかえりも真剣にしています。

真剣に取り組んでいるので、
ふりかえりで、課題がどんどん出てくる。
出てきたものを少しずつ改善していく。
上辺の改善だけではダメだと気づき、意味を考えるようになる。

形だけで始めたスクラムが、いつの間にか、

スクラムの良さに気づき

チームで取り組んでいる状態に。

本セッションでは、2年間毎日書き留めたチームの活動記録とふりかえりを元に、チームがどう変わっていったのか、チームメンバーの視点を中心にお話します。
スクラムマスターとしてどう関与していったのか、ちょっぴり入れられればなとも目論んでいます。

企業運営をアジャイルにする、という文脈でよく語られる、「Beyond Budgeting」(脱予算経営) というのをご存じでしょうか。多くの企業で一般的な年次予算(もしくは半期、四半期)の管理方法を見直して、よりダイナミックに、各現場に任せる形で企業内の資金を運営していこう、という取り組みです。2000年代に北欧の銀行などで取り組まれ、BBRT (Beyond Budgeting Round Table) というコミュニティがその普及啓蒙を担っています。

毎年米国で行われている Agile Conference では、2014年にImplementing Beyond Budgeting (日本語訳: 脱予算経営への挑戦)著者の Bjarte Bogsnes 氏をクロージングキーノートに招聘して、話を聞いています(講演ビデオ)。彼は企業会計の専門家であり、石油掘削ベンチャーのStatoil社の企業会計に携わっています。その講演では、Statoil社での実践を中心に、アジャイルの時代の経営のイノベーションについて話しています。また、BBRTが公開している、12の原則についても紹介しています。

私は、2022年8月に、Joe Justice氏のアジャイルハードウェア開発の研修に参加したのですが、テスラ社やSpaceX社が行っている脱予算経営について、紹介してくれました。その際に、日本ではあまり脱予算経営が紹介されていないと感じましたので、本セッションを思い立ちました。予算管理というと、スクラムの現場からはちょっと遠い話と思われるかもしれませんが、「予算を申請する」「苦労して上司を説得する」「上司も苦労して経営陣を説得している」という作業にはほとんどの人が携わっていると思います。このやり方を根本的にシンプルにしましょうという考え方で、私たちの日々の活動について、一考を促すものだと思います。特に小さな企業は、既存の大企業の予算システムマネしてもアジャイルにはなれません。

本セッションでは、Agile 2014  での Bjarte 氏の講演をなるべくそのまま紹介しながら、必要な補足をしていきます。脱予算経営について、一緒に勉強してみませんか？

"名詞" では 「"名詞"、"名詞"、"名詞"」をまとめてなんと呼んでいるでしょうか？

みなさんはどれくらいスクラムを知っているのか？すっとその知識を出せるのか？不安になったり、どうやって成長すればいいのか悩んだりしたことがあるかと思います。

資格取得、読書、ワークショップ、業務での取り組みさまざまなものがありますが、その中でもライトに取り組めるのがクイズです。今回はみなさんにスクラムのクイズを出してその知識や引き出し方を確認してもらえればと思います。

当日は10問前後からなる問題をだしてDiscordで最も早く回答してくださった方を勝者とします。また誤答によるペナルティはありません。

「QAさんからバグを指摘されたので、このバックログアイテムはDoneにできませんでした」
これはQAエンジニアである私が度々出会う、最もモヤッとする言葉です。

なぜこのような発言が出るのでしょうか？

これはテストによって発生したフィードバックを、開発者が「差し込みで発生した作業」と捉えてしまうからではないかと考えています。自分の手で実装したものなのに、自分ごとにできなくなってしまう瞬間があるのです。

開発者の実装が完了した後、1Sprint遅れでQAエンジニアがテストを行うやり方を採用しているアジャイルチームを時折見かけます。これはあまり推奨できるやり方ではありません。
QAチームがテストを実施している頃、開発チームの心はすでに後続のバックログに向いていて、テスト対象となっているアイテムは「すでに終わったもの」と認識しているからです。

しかし、たとえ1Sprintの中で実装からテストまで行ったところで状況は変わらないでしょう。「QAにテストを任せた瞬間に心が離れてしまう」という点は同じだからです。

また、QAエンジニア自身にも甘えや油断が発生しているのではないでしょうか？
あるバックログに対して要件に不明な点があったとき「これはテストをするときに確認すればいいか」と解決を先延ばしにしてしまうことがあります。やがてそれがSprintの終盤にバグとなって吹き出すのです。

考えられる解決手段は2つあります。

1. 開発者自身でテストを行うこと
2. 実装に着手する前に、要件の解像度を上げること

今回は後者についてお話ししたいと思います。

バグの多くは、要件の認識ずれによって引き起こされます。
そしてその認識ずれは、プロダクトに関わる各ロール (PO、開発者、デザイナー、QA、etc.) が細かく対話を重ねることで解消できるものも多いでしょう。

テストだけが品質保証の手段にあらず。
重厚なテストに頼りすぎず、より早い段階で対話を重ねることで品質を担保するチームにシフトしていきませんか。

スクラムマスターのロールを学び続けることは、スクラムを離れてもこれからの時代に求められるチームビルディングにつながっている

1. スクラムとの出会いと学び
2. スクラムは人生そのものと思った翌月にスクラム終了した話
3. 2年ほどチームと共に育つことを支えたくれた人と言葉
4. アジャイルジャパンの安田さん講演からの社長に「Joy,Inc化しよう」と言ってみた話
5. 今～スクラムからは離脱しているけどチームビルディングと所属組織の変容に口出しする末端社員になった話

医療従事者向けの書籍「コンコーダンス　患者の気持ちに寄り添うためのスキル21」から、相手の行動変化を促す対面コミュニケーションの考え方とスキルを共有します。

「コンコーダンス」とは「調和」「一致」を意味する英語であり、「患者の価値観やライフスタイルに、患者にもたらされる医療や福祉のあり方が、調和する」ことを表す医療用語でもあります。

「コンコーダンス」という言葉は1997年に英国国立薬剤師会により公式の場に登場したとされます。薬の飲み忘れや通院の中断などのノンコンプライアンス問題への対策から始まりましたが、服薬行動にとどまらず、健康問題における当事者と専門家の関係性やその成果を示す概念へと広がっていったそうです。

書籍は英国で地域精神看護師向けに開発された技術集「コンコーダンス・スキル・マニュアル」の影響を受け、に日本人向けに調整したものとあります。自己主張が苦手な日本人向けのスキルが追加されています。

書籍は医療従事者向けの技術集ですが、コーチングなどのエンジニア間で語られるコミュニケーションスキルとの共通項が多くあります。服薬行動などの「行動を変えてもらうために相手に納得してもらう」考え方／スキルが体系的にまとまっており、医療に関する知見がなくても理解しやすい内容です。

本発表では、コンコーダンスを紹介し、エンジニアへの応用の可能性について話します。また、書籍にあるスキルを抜粋して紹介します。

自分は、2020/11/1〜2022/9/22の間で、1,019回のカンファレンスやイベント(勉強会)に参加してきました。(2020年 : 55回 / 2021年 : 439回 / 2022年 : 525回)

どのカンファレンスやイベントも学びや刺激に溢れる素晴らしいものではありましたが、参加し始めたての頃は、自身や自身の周りに大きな変化が起きるわけでもなく、正直参加するメリットをあまり感じにくい状態でした。

しかし、カンファレンスやイベントに参加している人を観察したり、イベント参加を太い経験にするための工夫を自身で考えて試行錯誤していくうちに、徐々にカンファレンスやイベントの経験が行動変容に繋がるようになり、次第にカンファレンスやイベントに参加する意義を大きく感じられるようになっていきました。(イベントに参加する意義を感じられると共に、イベントに参加する頻度も増えていきました)

本セッションでは、イベント参加を太い経験にするために自身が行ってきた試行錯誤や、カンファレンスやイベントの種別ごとにどのように工夫するポイントを変えているか紹介することで、皆さんがカンファレンスやイベントで得られる経験をより太くし、参加者がカンファレンスやイベントをこれまで以上に楽しめるような話をしていきたいと思います。

確約・集中・公開・尊敬・勇気、これら5つのスクラムの価値は何もアジャイル開発の現場に留まるわけではございません。スクラムの考えを実践することは、エンジニアであっても非エンジニアであっても、キャリアの形成や人生に大きく寄与する可能性を秘めております。

非エンジニアであり、人材育成・組織開発に関わる企業の経営者として、自身のキャリアを少しふりかえりながら、スクラムの価値基準がどのように人生に寄与したかをお伝えしたいと思います。

学びのポイントとして、「勇気を出して自身の目で一次情報として経験する（もちろんオンラインもOK）こと」です。どこかで誰かが話していたことを又聞きしたり評論したりするのではなく、現地・現物を大切にすることで、きっと見えてくる世界があると信じております。

そして経験したことは、せっかくなのでふりかえってみましょう。ポイントは一人でふりかえる内省だけでなく、仲間と一緒にふりかえってみることです。経験したことを仲間にオープンにすることで、きっと何かフィードバックを得られ、新たな気づきや学びに繋がるはずです！

本セッションでは、ふりかえって見たらスクラムの価値基準をもとにアレやコレやを個人や組織レベルで実践してきた経験を元に、皆さんのキャリアや人生がほんのちょっとでも豊かになるためのTipsをお伝えしたいと思います。

こんにちは、世界。

私は、テストの街「葛飾」を運営者の一人、”ただのテスター”のおおひらです。

みなさん、イベントを楽しんでいますか。

最近、スクラムフェスなど、大規模イベントが増えていますね。

ただ、大規模イベントが増えていることはとても喜ばししいですが、なんとなく物足りなさを感じることはないでしょうか。

特にオンラインだと、発表の視聴はワイワイするし、あとで発表動画を見直して勉強になるけど、ただそれ以外は。。。で、もっと能動的に楽しみたい！と思っている人もいるかもしれません。（オンサイト参加でも、発表を視聴するだけで帰るだけだと、物足りないかもですね）

そんなときこそ、「DIY縦軸」です。

”縦軸”とは、24時間テレビのマラソンのような、バラエティ番組でメインコンテンツに合間に挟まれる続き物のサブ企画のことをいいます（諸説あり）。
参考：https://detail.chiebukuro.yahoo.co.jp/qa/question_detail/q1151175311

「DIY縦軸」では、”縦軸”という仕組みを応用して、イベント中に自分が考えたサブ企画を勝手にやり、能動的にイベントを楽しむ考え方です。

今回は、この「DIY縦軸」を実践した私の事例を紹介したいと思います。

ぜひ、みなさんも「DIY縦軸」実践し、イベントを能動的に楽しみましょう。

Metrics on employee happiness, theoretical value, and work not done are just plain dumb. I will reveal the metrics that you need. That mean something. And that get results. Join us as we discover THE BEST AGILE METRICS!

アジャイル開発/スクラムを導入しているあなた、こんな発言を耳にしたこと、発言したことはないでしょうか？

• 「当事者意識を持って！」
• 「スクラムには階層は存在しないから、指示待ちせずに行動！」
• 「それはアジャイルじゃない！」
• 「ふりかえりはしなきゃダメだよ。」
• 「チームは自己管理型(※)なんだから～」

こんな言い方ですと、チームのメンバは委縮してないですか？あなたの「アジャイル」価値観を押し付けてないですか？

私は、複数のスクラムチームでの開発を通じて、アジャイルマニフェストを読んだだけ、スクラムガイドを読んだだけ、で出来るほどアジャイル開発/スクラムは甘くはないことを痛感してきました。

・ドキュメントの文面だけを捉えて行動しても、それは薄っぺらいものになってしまう

・背後にある理念を理解しないと、ただの「作業指示」になってしまう

・やらされ感を感じ、チームの雰囲気が悪化してしまう

その結果、Be Agileを目指しているつもりが、Do Agileになり、気づけば「押し付けアジャイル」になってしまった。

こうなってしまうと、負の連鎖は止まらない。なんとか悪循環から脱出したいと思い、押し付けアジャイルは「ダメ。ゼッタイ。」をスローガンにカイゼンを始めてみた。

このセッションでは、私がスクラムマスターとして、開発メンバとして、複数のスクラムチームで経験/目の当たりにしてきた

「押し付けアジャイル」による失敗事例、アンチパータンとそれらを生み出していた根本原因、

そして、悪循環からの脱出に向けた改善に向けた取り組みについて、お話します。同じ悩みを抱える方々のご参考になれば幸いです。

※自己管理型とは、

2020 年版ではスクラムチームの⾃⼰管理に重点を置き、「誰が」「どのように」「何の」作業をするかを選択できるようにした。

～スクラムガイド２０２０より～

https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-Japanese.pdf

"You better bring it!

Oh, it's already been broughten!"

The purpose of cheerleading is to support and encourage their team to achieve peak performance - they give the team the extra oomph to carry them over the goal line! The cheerleaders not only support and celebrate the wins, they also encourage the team when they need to push through their trials and tribulations. Cheerleaders build the hype of the team fans by creating infectious energy, just imagine your stakeholders hyped up because of your awesome team!

In this session we will take lessons from professional cheerleading and apply them in an agile team context.

We will cover the 3 pillars of agile cheerleading - chants, dances, and symbols and explore the fundamentals and benefits of an agile cheer so that you can super-charge your teams.

BE! AGILE! BE! BE AGILE!

A fundamental and critical skill for any agile coach or leader is the pursuit of the fine art of "Zero F***s Given" ZFG. In contrast to how ZFG is often described on the interwebs, ZFG does not mean "I don't care"! ZFG is a mindset that embraces a myriad of concepts: fear, empathy, objectivity, neutrality, bias, drama, emotional intelligence, and more! Understanding the philosophy of ZFG will empower you to embrace this powerful skill so that you can become a more effective agile coach and leader. 

Global Day of Coderetreat は、仕事を離れて、ソフトウェア開発と設計を練習するイベントです。無料で参加できます。美味しいランチとおやつが付いてます。きっと、忘れていたプログラミングの楽しさを思い出す機会となるでしょう。

書籍「ヘルシープログラマ - プログラミングを楽しく続けるための健康Hack」を参考にして、私は計測とふりかえりを繰り返しながら健康のリファクタリング（身体的負債の解消）を行なっています。

基本的には1週間スプリントで以下を繰り返します。

• 計画づくり
• エクササイズとストレッチを実行
• 自分の身体のさまざまな数値を計測
• ふりかえり

とはいえ、理解は容易ですが実践は難しいのはスクラムと同じです。
継続するためには、楽しみを見つけること。
実行した結果が数値として見えてくる、身体や心の調子が良くなってくる。
自分自身の変化を感じとれるようになると、健康のリファクタリングが楽しくなってくるでしょう。

本ワークショップでは、私が実際に行っている健康のリファクタリング方法の解説をします。

また、計測項目として使えるフィットネスのユニットテストを実際に体験してもらい、肩こりや腰痛解消に効くヨガのエクササイズやストレッチを紹介します。

参考図書「ヘルシープログラマ - プログラミングを楽しく続けるための健康Hack」より

健康の定義

• 健康な人物とは、ライフスタイルから病気を生じさせてしまうリスクが低い人物のこと

アジャイルダイエット宣言

• お仕着せのメニューよりも個人の好みを
• 得意なダイエットよりも栄養素のバランスを
• トレンドへの追従よりもカロリーの計測を
• ダイエットのプランへのこだわりよりも、自分自身の環境への対応を

３つの質問

• 昨日、健康促進のために何をしましたか？
• 今日、健康促進のために何をしますか？
• 健康であることを阻害する要因が何かありますか？

フィットネスのユニットテスト

• 1.5マイルウォーク/ラン
• プッシュアップ
• ハーフシットアップ
• シットアンドリーチ
• 体組成

30人超所属するスクラムチームの開発で7年目に突入しました。

守・破・離の「離」に到達し、独自の文化を形成しつつ運営しております。
参画当初の方々は、それぞれの道を歩み始めており現状チームにはあまり残っていません。

「離」から生まれた独自のプロセスで、現状プロダクト開発を行っております。
プロダクトを止めない開発を行いつつ、大規模なチームのカイゼンは試行錯誤の連続でした。

今一度「守」から、「守・破・離」を振り返り、より高みに到達できるチーム、プロダクトをより大きく育てるべく日夜試行錯誤中。

長期間継続＆大規模チームの状況、新たな取り組みの１つの事例になれば幸いです。

あじゃてく（Agile Tech Expo)のみなさんと発行した「ぼくのアジャイル100本ノック」
めでたく8月に発行に至りましたが、結果的に100章、450ページの本になりました。

本書の内容は、
「アジャイルの具体例を知りたい」「成功例も、失敗例も、困ったことも」「実体験を！聞きたい！」
「スクラムやってみた」「JTCでスクラムって無理じゃね？」etc…
参加者の経験、体験、知見のぎっしり詰まった、パワーのある本になりました。

アジャイルに関する色々をまとめるという本企画を通じて、
・参加者が得た体験
・コミュニティが得たこと
・本がもたらした成果、届いた先　という観点でお話しします。

普段とは違う「アウトプット」をして、参加者（寄稿者）が得た体験、
自分の知識の棚卸や整理ができたといった大きなメリットがありました。

コミュニティで本を作るということの意義の点では、
活動記録としての本という媒体、そしてコミュニティで発行することにより、
パワーのある本を作り、広く届けることができました。
また、コミュニティがそのスキームを獲得・経験することで、次回企画にも活用できます。
約60人の参加者がゆるく、でも一つのテーマについて考える機会にもなりました。

「本の執筆」という形のアウトプットの意義と、それがもたらす効果、ブログや登壇との違いをご紹介します。
インプットも重要ですが、知識・経験をアウトプットしてみましょう。
それが、聞いてくれた人の背中を押すことになれば最高です。

本を作り上げるという行為は、様々な技術要素を含む「プロダクト開発」そのものです。
本に取り上げる（文字になる）技術的内容以外にも、
ネタ出し（≒伝えたいネタを探す、想定した読者に届けるためのマーケ）、執筆≒開発、
それ以外にも、デザインやプロモーション（SNS告知など）を小規模に実体験できます。
通常のプロダクト開発では「全体のごく一部」にしか関われないことも少なくありませんが、
一気通貫にすべてを体験できるレアなチャンスです。

さらに、「合同誌」であれば、複数の著者、あるいはデザイナーや校閲など様々な立場でチームができます。
今回は企画・編集（+本文執筆も）という立場でしたが、
スケジュールの設定や、著者へのフィードバックなど、
約60人の執筆者みんなが原稿を気持ちよく出すための工夫もあります。

また、本書をはじめいくつかの技術同人誌を持ち込んで、
現地で頒布もする予定ですので、ぜひ見てみてください。

https://oyakata.booth.pm/
これまでに作った合同誌はこちら。様々なコミュニティのメンバーがいます。
合同誌ならではの内容面での広さや、いろいろなトピックスで本が書けるということを見ていただければと思います。

https://note.com/ayanaru/n/n07a5bf761d42
https://note.com/oyakata2438/n/nf62de9a7f0ff
ぼくのアジャイル100本ノックの概要・理念

ダイキン工業 テクノロジー・イノベーション・センター（TIC）にて立ち上げられた、若手だけの開発チーム。

これまでのベンダー任せの開発に風穴を開けるべく、自分たちの手でサービスを成長させていく、という強い決意のもとで結成されました。

システム開発の経験が少ない中、さまざまな試行錯誤をしながら前進していきます。

最初は動作するシステムを実際にステークホルダーに見せることから始まり、少しずつスクラムのプラクティスを実践しながら、アジャイルな開発チームへと成長してきました。

1スプリントで何も完成できない、見積もりが外れまくる、そんなありがちな失敗を繰り返しながらも着実に成長し、今では安定したベロシティを維持するだけではなく、プロダクトゴールをステークホルダーとともに設定し、自らシステムの価値を切り開いていく、とても心強いチームの成長してきました。

そんな若いチームの試行錯誤だらけの成長記録を、各チームの若きリーダーを中心に振り返ります。