トーク

「傾聴」というキーワードを耳にした事がある人は多いでしょう。
これは何者で、なぜ必要とされるのか。自分なりに納得感を持ていますか？
ノウハウやテクニックとしてではなく、本質的な価値についても深く考えられていますか？

カウンセリングの大家カール・ロジャーズは、対人支援(カウンセリング)の現場において、聽く側に求める態度・資質を原則化しています。
それが「無条件の肯定的関心」「共感的理解」「自己一致」からなる、中核三原則です
これを元に、「人の話を聴く」とはどういう事か、その基礎的なマインドについて紹介します

想定対象: マネージャーやリーダーになりたての人など

・個対個の場面で、話が一方的になりがち / 関係性が深まっている感じがしない
・他者を援助する際に求められる要素を、感覚的にではなく理屈で抑えておきたい
・人の話を聞くのにすごく疲れたり、相手の感情に振り回されがちだと感じる

チームが大きく、成長してくると属人化の問題は付きものです。
この問題を放置しておくと知識の溝はどんどん深まっていくばかりです。

そこで弊社は１つの取り組みとして「会議の内容を視覚化する」ようにしてます。
アーキテクチャやドメインに詳しい人の知識を可視化してキャッチアップしやすくしたり、これからキャッチアップするメンバーは具体的にどの領域の知識が不足しているのか客観的に把握しやすくすることができます。

この登壇では具体的に弊社はどのような工夫をしてMTGしているか紹介します

・議事録でMTGのリアルタイム可視化
・インフラ構成図をベースに監視ログの可視化
etc

Symfonyが誇る素晴らしい公式入門書『The Fast Track - 基礎から最速で学ぶ Symfony 入門』
日本語化されていて誰でも読んで、試し、学ぶことができます。

この入門書は、単なるCRUD操作だけでなく、デプロイ、テスト、非同期、ワークフロー、API、SPA、ローカライズ、Redisセッション、RabbitMQメッセージブローカーなど入門書としては盛りだくさんのボリュームです。

とても素晴らしい入門書ですが、初心者には環境構築という厚い壁が立ちはだかります。

Dev Containers を使って簡単に環境を構築するための方法を紹介します。

Cloud RunとはGoogle Cloudが提供するマネージドサービスです。
1つのコンテナイメージでサービスが立ち上がり、最小は 128MBのメモリ・1vCPU・1インスタンス（0にもなる）から始まり、サービスの拡大とともに最大1000インスタンスまでスケールアウトすることもできます。
そんな始めやすさと拡張性を兼ね備えたサービスです。

そんなCloud Runに夢中になった私が
「Cloud Runのここが良い」
「Cloud Runのここを気をつけよう」
など、実務などで得た経験なども交えながらお話したいと思います。

想定する対象者
・Cloud Runって聞いたことあるけど、あまり知らない方
・コンテナ一つでサクッとサービス立ち上げてみたい方

お話すること
・Cloud Runの推しポイント
・本番運用していくなかでの気付き

お話しないこと
・他のCaaSとの比較

概要

弊社はQAエンジニアもいますが、品質の保証はQAに任せっきりにするのではなく、チーム全体で保証しようといった取り組みを始めました。
そのために行なっている取り組みを新卒一年目のエンジニアがお話しします。

話すこと

• エンジニアが書いているテストをQA、PdMへ展開するための取り組み
• テストを充実させるための取り組み
• テストコードを書くときのルール

話さないこと

• テストデータの整備
• CI/CD

ある日思い立ってぼくは https://tyotto-rurou.tips/ というメディアを立ち上げました。
これまで正直WordPressを侮っていました（ごめんなさい）が、メディアを構築・運用し始めると
なんと学ぶことの多いことか、と本気で驚きました。

WordPress自体の機能の多さ・拡張性の幅広さ、そして、 Cloudflare や Google Cloud といった
クラウドの利活用に非常に向いている素材であると感動すらしました。セキュリティ面の補強もいろいろな
工夫の仕方があることにも気がつきました。

本LTでは、自身のこうした体験記から得た、Webサイト運営の勘所をお話しできればと思います。

AWS Lambda PHP！って言い続けている僕ですが、スループットは出る！とも言い続けています

実際スループットには満足してますし、運用には支障が出ていません

でもEC2と比べるとどうなんだろう…？と思ったので比べてみることにしました

EC2にはPHPを運用出来るレベルのインスタンスサイズを選んで、無理しない範囲で公平性を保ちスループットの比較を行ってみます

• お話すること

  • 比較のレギュレーション
  • パフォーマンス比較結果

• お話しないこと

  • パフォーマンス結果の考察

• お約束できないこと

  • 厳密な公平性

とある案件で「Google Cloud で、Laravelアプリを」というオーダーに巡り会いました。
「AWS Fargate 上に Laravel プロダクトを載せる」ことをやりきっていた自分は、
Compute Engine ではなく Cloud Run 上に、Terraform module を利用して構築することにしました。

やると決めてから、Google Cloud のインフラを、初めて IaC で構築していきました。

このLTでは、その過程で感じてきた

• それまでに慣れていたAWSとの様々な違い
• Terraform module を利用することで手軽にクラウドインフラを組み上げることができる素晴らしさ

といったあたりの、新サービス構築事例をご紹介したいと思います。

Design Doc とは、開発者がコーディングに着手する前に、ソフトウェア設計の基本的な要点を説明するためのドキュメントです。
新しく追加する機能の設計を Design Doc を用いてドキュメントにしてきましたが、不慣れなうちは質の低い Design Doc を書いて、シニアエンジニアに指摘されてきました。
そんな自分の失敗を振り返る発表をしたいと思います。

話すこと

• 要約で伝わるようにする
• Design Doc で Approve を貰うことが目的ではない
• 体裁が整ったものが良い Design Doc ではない
• とにかく手を動かす

弊社では月に一度、各々が揃ってリファクタリングする日を設けています。

みんなが積極的にリファクタリングを行い、どんどんリリースしていくお祭り、それがリファクタリングデーです。

この発表では、実際どのようにリファクタリングデーを開催しているか、運用していく上で得た知見などをお話します。

プロダクトコードと対になって書かなきゃいけない「テストコード」。
今まで、「ルールとして存在していたからテストコードを書いていた私」が「あれ・・・？テストコードあるとめちゃくちゃ安心なのでは・・・？」「テストコード・・・スキ！！！」となった経緯を話します！

好きになる前の私「何でアプリケーションコードと、テストコード、2回同じことを書くんだろう・・・」
好きになった後の私「テストコードがあるから自分の実装に自信が持てる、バグらない自信あるかもしれんこれ」

この発表でテストコード書くことにピンと来てない人がちょっと書きたくなるな、となってくれるのを願い・・・！☆彡

概要

テストのメリットは「変更に強い」「動作の保証」「仕様書代わり」などが挙げられますが、この恩恵は保守フェーズを待たずにコードレビュー中から受けることができます。
レビューを受ける側はレビュー反映後の動作確認がしやすい、レビューを行う側はプログラムの構造が見やすくなりレビューの正確性と速度が上がるなど、双方にメリットがあります。
本トークではユニットテストを通じてコードレビューの効率を上げる方法をご紹介します。

トークの対象者

• コードレビューを行う人
• ユニットテストのメリットがイマイチわからない人

トークの目的

• コードレビューの心理的ハードルを下げる
• ユニットテストを書く人を増やす

話すこと

• コードレビューを受ける側/行う側双方におけるユニットテストのメリット

話さないこと

• テストコードの書き方
• PHPUnitの使い方

時代の進化によって、我々は様々な文明の利器を獲得してきた。

火🔥
石器🪓
電気💡
車🏎️

そして令和現在、、、、

🐘🌪️🐘🌪️PhpStorm🐘🌪️🐘🌪️

だがしかしPhpStormは便利すぎるが故に、飼い慣らすことが難しい。
時代の利器を手にしたとしても、使い方がわからねば宝の持ち腐れである。

PHP Conference 2022 で意外と要望が大きかった、PhpStorm の便利ショートカットをLTで披露しようではないか。

真の意味でPhpStorm🐘🌪️を、獲得しよう！

皆さんは社内勉強会は開催していますか？
勉強会の効果は、モチベーションが上がる・コミュニケーションが活発になる、などいいこと尽くめですよね！！

私の会社では30人規模ほどの社内勉強会を8年くらい継続していますが、
初期の頃は発表ハードルが高く、同じ人が発表したり、そもそもあまり発表者が集まらない、などの課題がありました、、！
「どうやったら発表してくれるかな？」という観点で改善を重ねた結果、今では溢れんばかりの応募です。
このLTでは「社内勉強会を開拓する」「発表者の発表ハードルを低くする」ノウハウを紹介します！

◆ 話すこと
取り組んできたハードル下げ方法「相談枠」「若手オンリー枠」「推薦枠」「カテゴリー絞り」「資料ハードル下げ」など・・・
その中で効いたアクション・効かなかったアクション

昨今、マイクロサービスを始めとした分散システムの活用が当たり前になってきました。
その際にシステムで何がどのように起きたかを考える、Observabilityもの世の中になってきたように感じます。

一方でコロナ禍でリモートワークを始め分散した環境での労働が当たり前になってきましましたが、人に対するObservabilityは十分に足りているのでしょうか？
今回のトークでは人を分散システムとして捉えて、Observabilityという観点からどのような環境で、どのようなコミュニケーションをしていくと健全になっていくかを提示できたらと考えています。

PHP8系がリリースされたり、逆にPHP7系のサポートが切れたりしてきた世の中。更にコンテナを利用して開発環境を統一する世の中です。
そんな新しいものと関わっていきたいと思いますよね。ただ世の中にはそんな潮流に逆らうシステムは数多くあります。
新卒入社してから関わった古き良きシステムの自己流の向き合い方だったり、保守する際の観点の話ができればと思います。

皆さん振り返りしてますか？改善のために振り返りは欠かせないですよね。
振り返りにはいろんなフレームや考え方がありますが、私が提案したいのは時系列KPT（勝手に呼称）です。

言わずともしれたKPTですが、プロジェクトの振り返りなどに活用するにはプロジェクト期間が長かったりすると初期のころに何をしていたかなど忘れてしまい、有効に振り返れないという問題があります。
この時系列KPTではそのような課題を解決できます。

現在私が BABYJOB 株式会社で開発を担当している保活サービス「えんさがそっ♪」は、ドメイン駆動な設計スタイルで開発を行っています。
具体的には Laravel + オニオンアーキテクチャでの設計・実装を行っています。

私自身はこれまで単純な MVC 構成のアプリケーション開発経験のみで、ドメイン駆動な設計スタイルのアプリケーション開発を行うのは初めての経験です。

最近、ドメインの構造などについて再検討する機会があり、ドメイン駆動設計の戦術面への関心が高まりました。
技術的な調査を進めている中で、PHP でのドメイン層の実装戦術として Symfony（Doctrine）に興味をもち、入門してみることにしました。

この発表では Symfony（Doctrine）でのドメイン実装戦術について、Symfony に入門してみて分かったこと、分からなかったことを発表します。

いつものようにデプロイしようとすると、突然落ちる CI ワークフロー。
Pull request の時点ではテストは通っていたはず…。
落ちたワークフローを確認してみると、 apt-get update が落ちている、だと…？

突然このような状況に陥っても慌てないようにするために、普段あまり意識することのない apt コマンドとリポジトリの関係について、そして最終的に何がエラー原因だったのか体験談を共有したいと思います。

海外チームとのオフショアでは、少し特殊なコミュニケーションスキルが求められます。

単純なタスクを依頼するだけではどちらにも悪意がなくても想定外の落とし穴にハマってしまい、なにかしらの手戻りが発生してしまうため、タスクの依頼以上の情報提供や、サポートが必要になります。

どのような状況でどんな問題や認識齟齬が発生するのか、またどのようなアクションを取ることで認識齟齬を回避できるのか...　オフショアチームとのやりとりを3年続ける中で得た知見を、NGパターンとOKパターンを提示しながらわかりやすくお話しします。