このセッションは公募型セッションです。

みなさん何事においても「初めて」があると思います。初めて自転車に乗った時、初めて包丁を握ってキッチンに立った時、初めて好きな人とデートした時、初めて生まれたばかりの我が子を抱っこした時、初めてコードを書いてコンパイルを通してコンパイラに怒られた時……。

このセッションでは貴方のそんな「初めてアジャイルに出会った」その馴れ初めを伺いたいと思います。誰しもが初めてはあったはずなのに、いつの間にか荒くれ者のアジャイルモンスターに揉まれて、プロポーザルを出すのが当たり前！みたいな"力"を感じていませんか？

そんな群雄割拠で百戦錬磨なあなたも素敵ですが、もっとピュアピュアで色んなことに翻弄されて、ただただ目の前のことに頑張ってひたすら現状を良くしたくて、いろんな思いを抱えながら試行錯誤した結果、なんとなくアジャイルにたどり着いてしまった(※筆者たちの妄想です)最初のあなたの気持ちを応援したい！それはきっとこれからアジャイルという言葉を知る誰かの助けになると信じています。

本セッションの主旨は以下です。

• 一番最初に「アジャイル」と呼ばれる何か(あるいはそれに準ずる何か)を知った時の気持ちやシチュエーションを教えてください
• それを知ってあなたがどう変わったかを教えてください
• 今のあなたから見て、当時のあなたにひとことだけ声をかけるとしたら何か、を教えてください

だいたいお一方5分程度お話を伺う予定です。公募が足りなくてお話いただける方が不足している場合には、こちらからお誘いをさせていただこうと考えております。その際にはご快諾いただけますと幸甚に存じます。

事前アンケートはこちら。一人で多くのご意見お待ちしております！！

https://docs.google.com/forms/d/e/1FAIpQLSfAw7beUDxwCYfZ83FbVB_zyIoxnOOPNxAE52nDozXRZ_xBuQ/viewform?usp=sf_link

ハジメテノアジャイルはなんでしたか？ 貴方のハジメテノアジャイルは。

ワタシにとってはこれがそう。だから、今、嬉しくて。

タイトルは「もしも食べ専エンジニアがThe DevOps ハンドブックを読んだら」など、ほか候補やより良いアイデアがありそうかなと思っていますのでぜひコメントでご意見ください！

私は妻と小学生の男の子二人、トイプードルの娘の5人暮らしなのですが、我が家の料理隊長である妻がアメリカに１年間行くことになりさぁ大変！　食べ専エンジニアの私が残された4人分の3食を毎日なんとかすることになりました！

食べ専から日々の料理を作ること、いやいや作ることと食べることだけではなく後片付けや調達、作ることとそれにまつわる運用、、、

あれ？これってDevOpsの原則が参考になるんじゃない？

というわけで手に取ったのが仕事で過去手に取った『The DevOps ハンドブック 理論・原則・実践のすべて』です。

このセッションでは、The DevOpsハンドブックに記載されている3つの道、すなわち①フローの原則、②フィードバックの原則、③継続的な学習と実験の原則、を通して、料理のワークフローの中でどのようにDevOpsの原則を実践してきたかの体験談をお伝えします。

数年にわたり、仕事や家庭で、制約（ボトルネック）を見つけ改善するという活動をしてきました。

制約を見つけ改善すると言っても、それは言うほどたやすいことではありません。たとえメトリクスでのモニタリングを実施していて、そこに状況を表すデータが存在していたとしても、そのデータをどう解釈し、意味付け、課題設定するかは一意に決まることは稀で、実際にとても苦労を伴う営みです。

これまでの改善活動を振り返ると、本当は制約と捉えるべきではないものを制約として認識し、それに他のプロセスを従属させ全体として最適ではないプロセスを取ってしまったこともあります。また、誤ったものを制約と認識していたと途中で気づき、課題設定と対策をピボットしたことも一度や二度ではありません。

そうした試行錯誤の中で、徐々に自分の中に何を制約と捉えるべきかという勘所が身についてきたように思います。（ただし、これ自体が思考制約であることも否定できませんが）

このセッションでは、私がそれらの試行錯誤を繰り返した中で見えてきた制約の見つけ方、言い換えれば一見制約と見えることをどのように捉え、「突破すべき制約」なのか「従属させるべき制約」なのかを見極めるかの勘所について、仕事として携わっているプロダクト開発の事例を踏まえてお伝えします。

「自分たちが制約だと思っているものは本当に制約ですか？」この問いにドキッとした方は、ぜひ私の経験した事例を通して制約との上手な付き合い方を一緒に考えてみませんか？

2019年にマネージャーとして任用されてから、様々なことに戸惑い、失敗してきました。

特にたくさん失敗して悩んできたのは、この二つでした。

• 「自分のグループのあるべき方向がうまく示せない。。。」
•  「グループとしての成果がまとまりがない気がする。。。」

そんな中で色々な情報をキャッチアップしたり、現場で数年もがいたりしているうちに、だんだん自分のやり方がわかってきて、（まだまだ失敗も試行錯誤もしているけれど、）以前よりも上記の悩みは軽減した状態になっています。

この取り組みをする上でベースになっているのはGMOペパボ株式会社の栗林健太郎さんの「やっていき、のっていき」です。振り返ってみると、コンテキストは違いつつ、自分なりにこの考えをどう実現するかを模索してきたように思います。

そこで自分がやってきことを振り返りつつ、自分が悩んだこと、失敗、そこから考えてどう変えていったかをお伝えします。

改善したいこと、たくさんありますよね？

でもいっぺんには解決できませんよね？　どこから手をつけますか？

このセッションでは、我々がタウンワークのネイティブアプリ開発チームが数年間戦ってきた技術的・プロセス的な課題とその対応についてご紹介します。

我々の対峙した課題と、その解決策の一例は下記の通りです。

• テストにめちゃめちゃ時間がかかる
  • ならば自動化！は本当に正しい、のか！？
    • 取り組んだ「手動テストの効率化」
    • デグレを防ぐ意味での自動テストの導入
• プロセス上のムダがどこにあるのか見えない？
  • Scrumを頑張る？ Kanbanやってみる？
  • 開発案件が「生まれてから役目を終えるまで」の一気通貫のモニタリング
• クラッシュレートが上がってきた？
  • アプリのクラッシュレート改善とそのモニタリング
• 人が、人がたらねぇ
  • アプリのSwift化
  • ハイブリッドオフショアチーム構想
• バグを出さないために速度を犠牲にせざるを得ない
  • 我々が出すべきアウトカムってなんだっけ？
  • 質とスピード
  • 今のプロセスは足りない？適正？やりすぎ？

これだけ読むと、課題と解決策がマッチしていないように感じるかもしれません。我々がなぜこれらの課題にフォーカスし、どうそれを捉え解決策を練っていったのかのコンテキストは当日のセッションで補完しながらお伝えできればと思っています。

改善したいこと、たくさんありますよね？

でもいっぺんには解決できませんよね？　どこから手をつけますか？

このセッションでは、我々タウンワークのWEBグロースハックチームが数年間戦ってきた課題とその対応についてご紹介します。

我々の気づいたボトルネック解決策と取り組み

• 技術的内容
  • フロントエンドの手戻りが多くて開発速度が上がらない！
    • 破綻したjsのリアーキ
  • スピードをアップさせてSEOパワーを担保せよ
    • GSU対応
    • CDN導入
    • CWV指標改善
• プロセス的改善
  • チームの分断で個別最適化！？
    • 企画・開発の一体化
  • もっと機敏に動き舞わないかなぁ
    • 朝会2.0
  • メンバー育成によるボトルネックの改善
    • 成果物リレーボトルネック改善
    • 知識の属人化改善
  • ボトルネックが検証に？
    • ABテストの稼働率モニタリングと、それに他のプロセスを従属させる

My Wife Went To U.S.

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

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

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

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

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

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

このセッションについて

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

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

コミュニケーションは難しい

同じプロダクト開発に関わっているとしても、開発チーム内には多かれ少なかれコミュニケーションの問題があります。

• なぜあんな事言うんだろう？？
• 意味のない指示にうんざり
• 否定されてばっかりでモチベーションが上がらない
• 全然メンバーが助けてくれない
• 一緒に仕事していると、チームメンバーと仕事に求めてるものが違う気がする
• なんかアイツの言い方が腹が立つ

感じる問題は様々な形で現れますが、これらの問題の一因には、人と人（あるいはチーム）とのコミュニケーションの難しさがあります。コミュニケーションは難しいんです。話している内容以外に知らなければならないことが多すぎます。

ルール化してコンテクストの共有

他者とコミュニケーションするときに、相手が話した内容だけでなく、相手のバックグラウンド、コンテクストなど様々な情報が共有されていないと、コミュニケーションロスや、意図しない誤解を生みかねません。

そこで、「コミュニケーションにルールを作る」ことでコミュニケーションロス、誤解を減らすことができるのでは？　という考えから、コミュニケーションに「プロトコル」を持たせる、という工夫があります。

Core Protocols

コミュニケーションのルール化のため、チームで自力でルールを策定することも可能ですが、何もないところからルール化するのにはそもそも大量のコミュニケーションが必要になり、現実的ではありません。（ルール化できるくらいコミュニケーションわかってれば苦労はないのだ）

そのような問題に対応するため、コミュニケーションをルール化したものが公開されているものもあります。私は、GNU-PLで提供されている Core Protocols(コアプロトコル) http://www.mccarthyshow.com/online/ というルールを利用していました。

このセッション

本セッションでは、Core Protocolsの内容を紹介した後、私が経験した多国籍チーム（シンガポール人、マレーシア人、日本人の混成チーム）でそれをどのように利用してきたか、それによってどのようなメリットがあったかをご紹介します。その上で、Core Protocolsの有効性、使いどころ、ハマった時の解決法をシェアします。

Core Protocolsが、あなたのチームのコミュニケーションの問題を改善に役立ちそう！（あるいは役立たなそう！）と判断ができるような体験をシェアできるセッションにしたいと考えています。

 分社して早数年、依然レガシーを極めるリクルートジョブズ。

その中に突如転職してきたアジャイルサムライこと @nawoto 。

初めてのメンバー、初めての言語、初めてのチーム開発。

そして突然はじまったリモートワーク。

人と、組織の思惑が絡み合う中、いかにしてこのチームはリリースまでこぎつけたのか。目まぐるしい展開の中で @nawoto が下した決断は！？

混迷の半年間が、各メンバーの口から語られる。

衝撃のラストを見逃すな！！