新しい！と思った知識は実は昔にも存在しているものがとても多い。しかしうまく引き継がれていなかったために「発掘」「再発見」される。
こういう事象に対して、過去をググらないから、、と切り捨てるのは簡単だが、情報が溢れてくるにつれて有益な一次情報は埋もれ、ツールを書いた巨人たちが共通の常識として持っていた知識は引き継がれず、経験者がびっくりするようなテクニック（自称）が技術と呼ばれているのは当たり前の光景になっている。もはや「どうしてこうなっているの？」という質問に「調べなさい」とインターネットに任せきることが適切ではなくなっているフェーズに入っていると言っても過言ではない。
私たちエンジニアは新しい技術を追求していくとともに、そこまでに至る道筋を整備していくことも新しい責任となってきているのではないか？
老人会として昔話に花を咲かせるのはこういったカンファレンスの醍醐味ではあるが、実はそこで共有されている知識にはものすごい価値がある。そして私たちが昔参考にしてきた資料たちは次々にアクセス不能になっていっており、歴史を紡いでいくことは喫緊の課題でもあるのだ。

このセッションでは、思った以上にどうでもいいようなことに価値があるという認識をみんなで共有し、経験者に向けては如何に自分たちが蓄えている知識や経験を体系立てた形で残していくのか、その時に何を注意すればいいのかということを整理し、新人に向けてはどのように過去を踏まえるべきなのかという心得のようなものを伝えたい。

転職先でいきなり管理職ポジションに就任する、いわゆる「パラシュート人事」は、うまくワークしないことが多いとされています。スタートアップに転職してわずか数日後、そんなつもりじゃないのにマネージャー（= 事業責任者）になってしまった私の<最初の100日>を振り返りつつ、モッシュピットの渦中で突き上げた拳の血潮を共有させてください！

対象者

• 新たに管理職に就任した方、特に転職直後にマネージャーになった方
• ミドルマネージャーやリーダーシップを必要とするポジションの人々

話す内容

• コミュニケーション戦略
• チームのリビルディング
• 「文化の中心」としてカルチャーを作る
• Small Winをどうやって積んでいくか
• 自分の「ニッチ」を見つめ直す

ソフトウェアを書いていく際、関数やメソッドのレイヤーからマイクロサービスのレイヤーまで、さまざまなレイヤーで私たちはシステムを分割していきます。しかし、ただ分割すれば良いというものではありません。分割に失敗すると、「ひとつひとつの部品はたしかに小さくシンプルに見えるけれどコールグラフはめちゃくちゃで読みにくい」というようなシステムができてしまったり、「たったひとつの部品のパフォーマンス問題や障害がサービス全体の障害を引き起こしてしまった」ということが起こってしまいます。

この分割の仕方がうまいソフトウェアエンジニアは「センスが良い」と評されたりしますが、その「センス」の正体とは一体なんなのでしょうか？

本トークでは、「良い分割とはどのような分割なのか」「悪い分割とはどのような分割なのか」を平易な例を交えて、それらの例から見えてくる原則を見出していきたいと思います。

対象者：

• システム設計の中で分割の指針がわからなくて困っている方
• 自分ではセンスの良い分割ができている自信があるが、設計レビューなどで他人の設計をレビューするときに「それが悪い分割である理由」をうまく説明できないと感じている方
• ソフトウェアの分割に興味がある全ての方

Debounce 処理というのはクライアントでよく使われる技術です。 高頻度で呼び出されるイベント（キー入力やマウスの移動、ウインドウのサイズ変更）などを制御するテクニックのひとつです。たとえばJavaScriptのライブラリLodashに実装されていたりそれなりにクライアント側では使われる技術です。
そんなDebounce処理をサーバサイドで実装したので、そのお話をしようと思います。
Debounce処理自体の説明から、 クライアントで処理すべきものをなぜサーバサイドで実装しなくてはいけなかったのかの背景の説明、 実際にどうやって複数のサーバで実装しているのか、なぜ3回も実装したのか、そして4回目の実装の構想などをお話します。
今回のようにクライアントサイドではよく使われるけどサーバサイドではあまり使われない、もしくはその逆の技術などは色々あると思います。みなさんのなかで「あ、もしかして俺が知ってるあの技術、実はこっちに応用できるのでは？」とか考えるようになるきっかけになれば幸いです。

本トークではイベントソーシングライブラリを使わずにイベントソーシングを実現したコードをベースに解説することで、その基本動作原理をわかりやすくお伝えします。

イベントソーシングはシステム上の出来事をイベントとして永続化することでシステムを構築する手法です。
システムをイベントでとらえることは伝統的なステートソーシングに比べて、多くの利点をもたらします。

たとえば、システムの全ての状態変化を時間を追って追跡することが可能となることはひとつの利点です。
何らかの問題が発生した場合には、発生したイベントのシーケンスをたどることで問題の原因を容易に特定できます。
ちょうどGitのログをたどるのと同じイメージです。
この特性はシステムの運用を確実に楽にします。

その他にもイベントデータはシステム間の連携を疎結合にします。
また、永続化されたイベントデータを利用して、あとからBIツールと連携するといった芸当も可能です。

このように便利なイベントソーシングをベースにして、システムを構築する場合、多くはイベントソーシングライブラリを活用することになります。
イベントソーシングライブラリを活用すると、深くその仕組みを理解せずとも扱うことができます。
しかしながら、こういった動作原理を覚えておくことは有用です。
動作原理を学ぶのに手っ取り早い方法は自前で実装してしまうことです。

そこで、本トークではイベントソーシングライブラリを使わずに実装した例をもとに、その動作原理を深堀りし、イベントソーシングに求められる要件などについてお話します。

本トークにより、イベントソーシングに対するイメージがブラックボックスではなく、身近なものとしてシステム開発のお供になれば幸いです。

今、現場で「なんかうまく行ってないなぁ」ってプロジェクトがあるなら、それは立て直すチャンスです。

実際にどのように立て直すのか。
どうやって目の前の課題を解決していくのか。
ソフトウェアの知識は組織改善にも通じます。

実際に開発組織、事業部、組織全体と、この2年半のC（超）T（トラブル解決する）O（おふぃさー）としてやってきた学びと壮大なる物語をご紹介します。

対象者

• チームが上手く行ってないけどなんとかしたいなって思っている人
• ステークホルダーと如何にコミュニケーションとればいいか悩んでいる人
• 物事を前に進めたいのにうまく行っていない人

話す内容

• コミュニケーションとSBIモデル
• ビジョンと期待値調整とガイドライン
• シンプルな構造はインターフェイスを導く
• とにかくなんかいい話