トーク

株式会社ウィルゲートで、24新卒エンジニア向けに「エンジニア基礎」という研修を実施しました。
今回、社内で新卒エンジニアやベテランエンジニアからも大好評だった研修を、PHPカンファレンス福岡で特別に再構成して皆さんにお届けします！

バックエンドやフロントエンドの知識といったテクニカルスキルの習得よりも、エンジニアとして重要なのは、 成長していくために必要なスタンスやマインドについて知ること です。

このトークでは、2時間の研修から特に重要なポイントに絞ってお話します！

話すこと

• なぜエンジニアとして成長するために「スタンス・マインド」が大事なのか
• エンジニアとしての基本心構え「プロ意識」
• コミュニケーションの心構え
• キャッチアップスキル
• 作業するとき全般大事なこと
• コード書くとき全般大事なこと
• 継続的な成長をするために

My talk in the conference is about why we need to code ? Why we need Generative AI ? Why coders always rely on ChatGpt and other open AI. Why programming language are difficult to understand ? Will AI replace the coders ? These are the sub domains , I want to talk in the conference .

私は現在VPoEとして、開発メンバー18人の1on1を毎週行っており、マネージャー時代も含めて3年以上メンバーとの1on1を続けてきました。

その中で、急成長する人は、1on1の使い方、上司の活用方法が圧倒的にうまいことに気づきました。

本セッションでは、VPoEの視点から様々なタイプの1on1を通して得た、急成長する人の1on1の特徴をまとめ、それを実践するための方法について話します。

こんな人におすすめ

• 1on1はしているけど、いまいち成長実感がわかない
• 1on1で何を話し、どう成長に繋げればよいかわからない
• なぜ1on1をするのかよくわからない
• 圧倒的に急成長していきたい人

エンジニアがサービスを理解するタイミングは、果たして機能開発やバグ修正に限られるのでしょうか？
私はそれに加えて、機能を整理する際にも深い理解が必要だと考えています。

実際、既存のリソースを統合または削除する行為は、機能追加やバグ修正と比較してもより高いリスクを伴います。
なぜなら誤って必要な機能を削除してしまった場合、予期せぬ障害につながる可能性があるからです。

そのため、これらの作業を安全に進めるには、インフラやドメインを含む広範な知識が必要不可欠です。
本トークでは創業当初から運用されているサービスの統合や整理を通じて、サービスそのものへの理解を深めた経験を共有します。

PHPStan、知っていますか？

PHPStan（PHP Static Analysis Tool）は、コードを実行せずに検査できる静的解析ツールです。
あなたの書いたコードの良くないところを探して、こういうふうに直すといいよって教えてくれます。

「なんかCIめっちゃ落としてくるめんどくさいやつだ」

今までPHPStanは導入されていたし、一旦従って何気なく使ってきました。

でもコイツ、思っているよりもめ〜っちゃすごかった。
PHPのバージョンアップに取り組み始めてから、PHPStanがあるってこんなに嬉しいんだ……！！と感動しました。

このLTを聞いた皆さんは、「PHPStanがあるとなんで嬉しいの？」から「PHPStanってマジですごい！！」になるでしょう！

わたしはかれこれ20年ほどエンジニアとして生活を営んでいます。その過程で様々なアクシデントや環境の変化に見舞われまれたことからの気付きとして、職業人として「力」を得るのは長期的な研鑽が欠かせず、つまり日々のトレーニングいかんによって成長度合いが左右されるということです。

10年代は闇雲に行っていて、それはそれで間違いではないものの、20年代に入ってからは先達から得た教えからトレーニングを3つの指標をモニタリングすることで確実な効果を得ています。

このセッションでは、具体的にどのような指標を使っているのかと、実際につけている記録からエンジニアリングとしてのプロセスの実践例を示します。

この皆さんが長く成長し続けるためのヒントになると信じています。

私はベトナムにグループ会社があるグローバル企業に所属しています。
今年2月頃に、日本開発部のエンジニア達でベトナムへ行き、ベトナムのエンジニア達とハッカソンを開催しました。

日本とは文化も言語も違うエンジニア達と、どうコミュニケーションをとりながらハッカソンに挑んだのか、
実際のベトナムでハッカソンをした貴重な体験談から学んだ異文化コミュニケーションの壁の乗り越え方をお話します。

「レガシーなコードは嫌」「リファクタリングして認知負荷の低いコードにしたい」と思っていませんか？
でもいざリファクタリングして、使ってないと思って消したコードが実は使われてて危うく障害になりかけたり、
テストコードを書こうにも、テストコードが書きづらいためにリファクタリングし辛いことも多々あるはずです。

このセッションでは、そういったレガシーなコードに対し、どのようにリファクタリングをしていくとよいか、具体的なテクニックについて話します。

話すこと

• そもそもレガシーコードをリファクタリングをするかしないかの判断
• 使ってなさそうな関数には生存確認のログ埋め込み
• でかい処理にはまず単純な関数分割
• 改修頻度が高く重要なロジックからテストコードを書く

日々レガシー開発の現場で闘っているみなさん！おつかれさまです！
自分も20年以上の歴史があるプロダクトの開発に関わっていたり、過去にはフレームワークのリプレイスに携わったりと、さまざまな問題に悩まされる毎日です。

そんなある日のカンファレンスで、同じようなレガシープロダクトに関する発表を聞いて思いました。
「ああ〜わかる〜あるある〜」
（ん？もしかして自分が思ってるあの悩みやこんなつまずきも、もしかしてあるあるなのでは？）

レガシー開発あるある、言いたい！！

というわけでこのLTではレガシー開発あるあるを紹介します。
あるある or ねーよ！ など、皆さんの共感や感想交えて盛り上がれたら嬉しいです！

私はこれまでにPHPを全く書いたことがありませんでした。そんな私がPHPerKaigi 2024に参加しようと考え、せっかくだからLaravelで簡単なWebアプリを書いてみようと考えました。
RubyとRailsのエコシステムにどっぷりな開発者が、PHPそしてLaravelに入門して感じたことを話します。

そしてここからがこの発表の本題ですが、プログラミング言語またはフレームワークのコミュニティに新規参加者を増やすにはどうすればいいでしょうか。PHPerKaigiの懇親会で出会った、Rubyを学び始めたばかりの方からの意見など様々な方と話して考えたことを話します。

このトークでは、「このようなことができるかもしれない」というアイデアを投げかけることが限界でしょう。このトークを聞いた皆さんからも意見をもらえると嬉しいですし、あとでゆっくり考えてもらっても嬉しいです。

皆さんは「Azalea（アゼリア）」というPHPフレームワークをご存知でしょうか？
…すみません、多分知っている方はほぼいないと思います。
なぜならこれはサイボウズのGaroonというプロダクトで使用されている独自フレームワークだからです。

GaroonはPHP4の時代から提供されてきた、20年以上の歴史を持つプロダクトです。
昔はフレームワークの選択肢もなく、Garoonでは独自のフレームワークを構築して開発がされてきました、それがAzaleaです。
Garoonは今でも同じフレームワークで動いています。これはやばいです、色んな意味で。
このトークでは、なぜ今でもこのフレームワークが使われ、動いているのかについてお話しします。

■ 話すこと

• Azaleaの提供している機能について
• Azaleaは時代に合わせてどう変わっていったか
• AzaleaとLaravelを比較してみた

2、3ヶ月程度かかる大きめの機能開発も任されるようになったとき、「設計をどのようにすればいいか分からない」「大きい変更のタスク分割が難しい」と悩むことがあると思います。
全体の機能を一度にまるっと作ってからリリースしようとすると、プルリクエストが肥大化しレビューが複雑になり、見落とされた不具合や障害が発生しやすくなってしまいます。

このトークは、その悩みを解決する具体的なテクニックを、設計やタスク分割に慣れていない方に向けて順を追って説明します！

話すこと

• なぜ、デプロイ頻度が大事なのか？
• 細かくデプロイするためにインタフェースを設計しよう
• 安心して実装に取り組めるように、テストコードを先に書こう
• インタフェースごとにタスクを分割して実装しよう

-- 〇〇さん、次このプロジェクトに参画して開発してください
私は初めてプロジェクトに参画することになった。
-- 〇〇さん、進捗はどうですか？
進捗を聞かれてもいつでも答えられる。
-- 〇〇さん、作業終わったみたいだから次この機能開発してくれる？
開発タスクも順調にこなしてるし、よくわからないけどプロジェクトのマイルストンも順調に進捗してるらしい。

「あれ？でも、この機能って前にやった機能といっしょに開発したほうが早かったな。それにあのカンファレンスで聞いた〇〇って技術でもっといい感じにできたかもな。」
「でもテックリードでもPMでもないし、機会が回ってきたときでいっか。」

本当にそれでよかったのでしょうか？
このセッションでは、メンバー目線での情報がプロジェクトにとっていかに重要か、メンバーでもプロジェクトにもっと貢献するテクニックを話します。

みなさん、PHPカンファレンス登壇してますかー？
私はまだ登壇したことがありません！

これまで私はPHPカンファレンスに参加し、登壇者の皆さんのプレゼンテーションを楽しみながらも、自分自身が登壇することには一歩踏み出せませんでした。。
しかし、あるきっかけが私の心を動かし、登壇に向けたハードルを一つずつ乗り越えてきました。その過程で得た経験や気づき、そして成長の過程を皆さんにご紹介します！

登壇に興味があるけれども踏み出せない方、自分の学びを話してみたいけれど不安を感じている方、ぜひこのLTでお待ちしております！

私は今、受託開発の会社に勤めていますが、受託開発だと複数案件に関わることはあるあるだと思います。
ただ、参画したタイミングや状況により様々なポジションや開発言語で案件をかけもつことがあります。
時にはマネージャーとして管理を行い、時にはメンバーとして開発を行う。イレギュラーな事態は毎日発生し、考えていた進捗まで中々届かない。。
このLTはそんな中で自身を管理しつつ各案件をなるべく燃やさずに進めている方法をお話します。

PHPには様々なフレームワークが存在します。
Laravel, Symfony, CakePHP, BEAR.Sunday etc..
Composer化したライブラリが、特定のフレームワークに依存してしまっては、利用ユーザーが限定されてしまうことになります。
汎用的にライブラリが扱えるように機能提供できたら素晴らしいことです。
本トークではとある自作ライブラリをフレームワークを乗り換えしても利用可能な様に見直しを行うことを題材に試行錯誤する内容を発表します。

日時はクライアント、サーバ、データベースといった要素間で「旅」をします。
また、ある日付から1ヶ月後や2年前といった計算には、想像以上に多くの考慮が必要です。
本トークでは、それぞれの要素での日時の安全な扱い方を具体例と共に解説します。

話すこと:

• タイムゾーンにおける問題と解決策（DBはPostgreSQLを中心に）
• SPAでの日時のクライアントとサーバ間通信
• PHPで実装された「危ない」日時操作を「安全な」日時操作に置き換える方法
  • 例に出すコードの問題点と解決策
  • date()からDateTimeクラスへの移行など
• これらのテスト方法

ターゲット:

• 日時操作をコピペしている方
• 文字列操作で日付を生成している方
• より良い日時を扱うの方法を学びたい方

うるう年のこの機会に一緒に日時の扱いを見直して、安全な操作方法を学びましょう。

【概要】
システムの保守運用は出来ても自分自身のメンテナンスはおざなりにしてしまう...そんなことありませんか？
システムの健康はエンジニアの健康あってこそです。
自分という唯一無二のシステムを、長期的かつ安定的に維持するためのヒントをご紹介します。

【トークの対象者】
・健康管理に興味がある人
・健康を維持して各地のカンファレンスへ飛び回りたい方

【トークの目的】
・健康管理に興味を持つエンジニアを増やし、長く元気に楽しく働いてもらう

【内容】
・自分という唯一無二のシステムを知ろう〜自分自身にドキュメントはない！試して動かして検証しよう
・食事・運動・睡眠〜合う方法を探すためには自分自身をよく知ること！行動と結果を振り返ろう
・外からフィードバックを受けよう〜プロでも機械でも、客観的な目線は大事です

【話さないこと】
・医学、栄養学に関する知識

さる3/9、PHPerkaigiで行った「BEAR.Sundayの分散キャッシングフレームワーク」の講演に、「映画のようだった」「とてつもない伝説」など、聴衆の心を動かしたような感想が寄せられました。

本講演ではこの講演の舞台裏をメイキング形式で語ります。元のスライドを用いて、技術的課題への取り組みが普遍的な問いかけと開発者の情熱につながる道のりを紹介。松尾芭蕉の思想、多くの伏線、比喩や例え話、映画的構成、言葉選びの工夫、AIの活用など、創作の裏側を交えながら、開発者として私たちが何のために何のシステムを作っているのか、その本質を問います。

aspida を使用して、REST APIのバックエンドを型安全に呼び出すLTを発表をします

発表の流れ
aspida とは
• aspidaは、REST APIを型安全に呼び出すためのツールであり、簡単にAPIクライアントを生成できるライブラリです。

URLベタ書き
• APIエンドポイントを直接書く方法を使っていこれはミスのリスクが高くなります。

自作でバックエンドの型作成
• バックエンドの型を手動で作成する必要がありました。しかし、バックエンドが変更する度に手間がかかります。

Swagger + aspidaで楽々型作成
• Swaggerを使ってAPI仕様を定義し、aspidaを利用することで、自動的に型安全なAPIクライアントを生成できます。

まとめ

発表しないこと:
• Swaggerの詳細な説明
• REST以外の型安全な呼び出し方