トーク

プロダクトコードを書くと対になって書かなきゃいけない「テストコード」。今まで、「ルールとして存在していたからテストコードを書いていた私」が「あれ・・・？テストコードあるとめちゃくちゃ安心なのでは・・・？」「テストコード・・・スキ！！！」となった経緯を話します！
この発表で「テストコード書くのが好き！」「うんうん、そうだよね、テストコード最高だよね」となってくれるのを願い・・・！☆彡

普段お世話になっているフレームワークですが、その中身についてちゃんと見てますか？私は全く見ていませんでした・・・。
今まで恩恵を与えてくれていたフレームワークがどのように実装をされているかを見ることによって、より「スキ！」となりたい！
なので！今回、Laravelの実装を読んでみて、「ここの処理スタイリッシュだな〜〜」「学びがあった〜〜」となった部分をシェアハピします！！
この発表を聞いて、「自分もちょっぴり読んでみようかな」って人が増えると嬉しいです！

NoSQLのような可用性・柔軟性を持ちながらSQL・トランザクションをサポートすると言われているNewSQLの導入事例が最近目につくようになってきました。
ですが、NewSQLと既存のNoSQLとの違い、また実際どのようなメリットがあるのか、よくわからない部分も多いと思います。
今回の発表ではNewSQLの1つであり、MySQL互換のTiDB(タイデービー)をPHPのアプリケーションからつないで使ってみるところまでを、発表したいと思います。

アプリケーションエンジニアの視点から調査した以下の内容をまとめて発表予定です

• NewSQLの歴史
• NewSQLの概要
• NoSQL, RDBとの違いとNewSQLのメリット
• Cloud Spanner, CockroachDB, TiDBの比較
• TiDBをPHPから動かしてみる

1番最初にOSSにPRを出した時に、皆さんは緊張されませんでしたか？僕はしました笑
PRを出すのはこの方法であっているのだろうか、的外れなPRではないだろうか…などなど。
このセッションでは、OSSにPR出すのにあたってまずは翻訳から参加することで心理的なハードルが下がったり、翻訳も案外勉強になってしまうことを、翻訳のtipsと共にお話しします。

新卒・若手エンジニアのみなさん、長期のタスクに取り組む際、プランニングやタスク分割で失敗したことはありませんか？
長期のタスクを計画的にこなしていくために、適切なプランニング・タスクの分割は欠かせ無いものだと思います。
しかし、新卒1年目の私には

「プランニングって何？」
「タスク分割ってどうやるの？」

とわからないことが多くありました。
はじめのうちは見積もりをしみてたけど、実際の対応工数はそれよりも多くかかってしまったりと難しいこともありましたが、先輩や上長のアドバイスを頂きながら少しずつ改善していきました。

本LTでは、私がPHPプロダクトのバグ改修などの業務内での経験を通じて学んだ、以下のことについてお話します。

• タスクをすすめる上でどんな情報を準備する必要があるか
• 長期タスクをスプリントサイクル（1週間）にどう落とし込むか

みなさんは、外国のチームと開発をしたことはあるでしょうか？

オフショア開発では予想できないハプニングや思いがけないアクシデントが多々生じます。
私は、現在所属しているチームに参画して以降、PHPでの開発をともに進めているオフショア先のベトナムチームとの窓口を4年担当し、情報共有不足による失敗や、
遠隔メンバとの距離感や温度感の違いによる認識齟齬をはじめとする様々な出来事を経験しました。

しかし、4年担当した今でも想像しない出来事が発生するのがオフショア開発です。
基本的な確認事項などを抜かしてしまうだけで、予想外の事態が発生します。
本セッションでは、そんなオフショアにおけるハプニングやアクシデントを紹介し、それらを回避するノウハウなどを実例を交えてお伝えできればと思います。

目指せBot芸人！！
エンジニアであれば誰でも面倒な作業は自動化したくなるものです。
忘れそうな業務、何かをトリガにした作業、定期的なチェック...
これらのことを頭の片隅に置きながらの業務は、気が散って仕方がないのではないでしょうか。
自動化できることを自動化し、普段業務で使っているチャットへ通知することで、考えないでいいことを思考の外に追いやり、本来の業務に集中することができます。

とはいえ、急に自動化を始めようとしても、何を自動化すれば幸せになるのか、イメージができない人も多いかと思います。
本セッションでは、実際のBot活用例をもとに、Bot にどのような活用例があるのかを紹介します！！

PHPer であれば、PHP を使って明日からでも Bot を作成/運用できます。
あなたも Bot を作って Bot 芸人を目指しませんか？

既存サービスにフレームワークを導入するとなると、さまざまな障壁が立ちはだかります。
導入によるコスト、品質への影響など。
弊社では、リリース後21年目になるレガシーサービスにLaravelを導入しました。
このセッションでは、Laravel導入のためのアプローチ方法や、戦略、手順、その結果を共有させていただきます。
レガシーサービスだけど、フレームワークを導入してみたい開発者向けの内容となります。

既存サービスにフレームワークを導入するとなると、さまざまな障壁が立ちはだかります。
導入によるコスト、品質への影響、ビジネスサイドとの合意形成など。
弊社では、リリース後21年目になるレガシーサービスにLaravelを導入しました。
このセッションでは、導入に至った経緯、ビジネスサイドとの調整、戦略、アーキテクチャ選定、導入手順とその結果や成果などを紹介させていただきます。
レガシーサービスだけど、フレームワークを導入してみたい開発者向けの内容となります。

みなさん、あなたが保守しているコードベースで一番バグが混入しやすいファイルが何か知っていますか？

このトークでは、保守容易性指数（Maintainability Index)とGitHubのコミット数を用いて、
保守性が低くて、よく変更されているファイル(= バグが混入しやすいファイル)を見つけ出す方法についてご紹介します。

Rectorを使うと、簡単にコードの書き換えを行うことが出来ます。
「FWのバージョンを上げたから新しい記法に対応しよう」とか「新規にヘルパーメソッドを定義したから、既存コードもこちらを使うようにしたいな」なんて場面で、コマンド1発で実現できるのです・・！

自身のプロジェクトの固有の書き換えルールを定義し、活用できたらとても便利だと思いませんか？
例えば「新しいコーディング規約を定義したから、それに沿ったコードに直すぞ」なんて作業を自働化できたら嬉しいですよね。

独自ルールの作成方法、利用方法をLTで紹介します！

みなさん Composer 使ってますか？使ってますよね〜〜〜？？
Composer のようなパッケージマネージャのおかげで、パッケージの依存関係を明らかにしたりパッケージの依存関係や実行環境の依存関係にあわせてパッケージを適切なバージョンにアップデートすることもできます。

一方で、定期的にパッケージのバージョンアップを行うのは手間ではあります。その一手間を減らしてくれる dependabot や WhiteSource Renovate といった自動でパッケージのアップデートを Pull Request にしてくれるツールが登場します。

本トークでは、 Composer を利用しているプロジェクトにおいて、 WhiteSource Renovate を用いたアップデートに関する Pull Request の自動作成戦略についてお話しできればと思います。

世は大 Laravel 時代を迎えています。業務でも Laravel を採用している会社はそれなりにいるのではないでしょうか。
しかし、「依存を増やす」ということは「障害点を増やす」ことと同義です。
「Laravel は安定しているからロックインされてもいい」とみなすことも出来ますが、業務では「最悪の場合」も想定して選択していく必要があります。
DDD の文脈では（私は DDD 初心者ですが）、ビジネスロジック(ドメインロジック)を重要視します。フレームワークはビジネスロジックをサポートしますが、直接依存しない方が安全です。
このトークでは、「いつでも Laravel を捨てることもできる疎結合な設計」を紹介します。

対象者

• OSS フレームワーク・ライブラリを利用する全ての皆様
• アプリケーションを疎結合にしたい方

成長するためにアウトプットというのは非常に重要ですが僕のまわりでは
・プライベートで開発ほとんどしてないからネタがない
・公開できるようなネタがない
・とにかくネタがない
ということが非常に多いです。

僕も最近はプライベートで開発できてないので、めちゃくちゃ気持ち分かります。
でも我々は日々業務で技術に触れていますし、日々学んでいますよね？
だったらそれをアウトプットすればいいのです！

もちろん業務で得た知識をそのまま一般公開することはできませんし危険です。
外部に出してはいけない情報もあるでしょうし、場合によっては情報漏えいにも繋がります。
そういう知識をアウトプットするには「抽象化する」ことがとても重要です。

本セッションでは「知識の抽象化」の仕方を実際に僕が経験したことを例に説明します。
このセッションで少しでもアウトプットへのハードルが下がると嬉しいです！

今やソースコードをgitで管理しているのは当たり前の世の中になりました。
gitのcommitを俯瞰で見ることで
・誰がどれくらいcommitしているのか
・対象期間に1番commitしてるのは誰なのか
・このリポジトリに関して1番詳しいのは誰なのか
などを知ることができます。
このセッションでgitのcommitの集計方法を学びましょう！

昨今のプロダクトの改善・開発を実施していくためには、データを可視化・分析することはこの時代必須といえます。
特に、アプリケーションエンジニアにも一定のリテラシーが求められている時代だと考えられます。
しかし、そのために必要なデータはRDB、ログなどの様々な形式、場所にあり横断的な分析をすることは容易ではありません。

そこで、私たちのアプリケーションの分析環境をBigQueryに構築したエピソードをもとに、以下の知見についてトークします。

• embulkを使ったBigQueryへの転送パターン
• 便利な集計クエリのパターン
• BigQueryの権限管理ついて
• BIツールのLookerを用いたデータ監視について

NoSQLのような可用性・柔軟性を持ちながらSQL・トランザクションをサポートすると言われているNewSQL（Cloud Spanner, CockroachDBなど）の導入事例が最近目につくようになってきました。
ですが、NewSQLと既存のNoSQLとの違い、また実際どのようなメリットがあるのか、よくわからない部分も多いと思います。
今回の発表ではNewSQLの1つであり、MySQL互換のTiDB(タイデービー)をローカル環境でセットアップして、PHPのアプリケーションからつないで使ってみるところまでを、発表したいと思います。

アプリケーションエンジニアの視点から調査した以下の内容をまとめて発表予定です

• NoSQL, RDBとの違いとNewSQLのメリット
• TiDBをPHPから動かしてみる

突然、元気に呼びかけて申し訳ありません！
言いたいことは掲題のとおりでございます。

Web業界やソフトウェア産業、とっても忙しいと思うんですよね。
やる事が多い！巷では、やれアジャイルだ、リーンだ、DXだ・・・と騒がれて久しい。
なんでも、「コードを書いてりゃOK」ではないような雰囲気がムンムンしちゃって。
「視座の高さ」「視野の広さ」がより求められている感じがします。

そんな幅広い職業に居る我々の「生産性」ってなんでしょうね？
(私、ここ1年ほど、職場でそんなことばっか考えてる。)
そのヒント、書籍「LeanとDevOpsの科学」にあります。
価値を届ける、確実性を上げる、無駄を削ぎ落とす・・「それって何？」に真っ向から向き合った1冊です。
ソフトウェア開発の「生産性」について考える、「改善」について考える、そんな取っ掛かりになるように書籍の紹介をします。

「(登壇はしてみたいが)話せるネタがない…」と思った事はありますか？

「高度で専門的な内容でなくても、他の誰かにとっては嬉しかったり、興味深いものである可能性が存分にある！」というのが個人的な考えです。
何であれ「話してみたいな」と思ったなら、それは登壇への第1歩です！

このLTで、過去の経験・感覚を踏まえて、自分自身が「どう考えてネタ作りをしたか」をシェアしてみようと思います。
「なんだ、その位なら話せることがありそうだぞ！！」という気持ちになってくれたら幸いです！

届けたい人

• 登壇などをしてみたい！けど、どんな事を話せば良いのだろう…が不安な方
• 無限にプロポーザルを出したい人

届けたいこと

• テーマを考える際の着眼点
• 気楽にプロポーザルを出すぞ！というリラックス効果

話さないこと

• 資料の作り方やプレゼン術みたいなもの

コードレビューは難しいですね！
異なる考え方・レベルにある他者同士、ぶつかってばかりではいられないけど「何も言えない」のでは意味がない─
そんな複雑で繊細な仕事に、どう向き合えばよいでしょうか？

本セッションでは「レビューは何が難しくて、"怖い"のか」について考えます。
その上で、コミュニケーションやチーム作りの分野にヒントを求めて「明日からできそうなこと」を紹介します。

以下のような書籍をヒントの元として想定しています(一例)。

• アジャイルプラクティス
• 学習する組織
• NVC 人と人との関係にいのちを吹き込む法
• あなたのチームは、機能してますか？

お届けしたい事

• 「威圧したい訳ではない！でも妥協もしたくもない！！」を両取りするためのヒント

扱わない事

• プログラミングの知識、技術
• コードのクオリティを高めるためのノウハウ