PHPカンファレンス2019参加レポート［後編］

12月1日、東京都大田区産業プラザPiOにて「PHPカンファレンス2019」が開催されました。本稿ではその模様をお届けしています。最終回の今回は、郡山さんのRESTに関するセッション、サイボウズとSkillCampのセッション、ライトニングトークをレポートします。

郡山昭仁さん「REST 6+4の制約」

フレームワーク「BEAR.Sunday」の開発者であり、フリーランスエンジニアの郡山昭仁さんはRESTの制約について話しました（発表資料⁠）⁠。

RESTやHTTPを誰も意識していない

マーシャル・マクルーハンの「誰が水を発見したのかは知らないが、それが魚でないことだけは確かだ」という言葉とSteve Klabnikやロイ・フィールディングのブログを引用して、我々が普段利用している技術について意識していないことについて説明しました。

そもそもRESTというものはロイ・フィールディングが2000年に発表した論文が元になっており、その論文に定義されていることがすべてです。50年以上の歴史があって様々な文脈で語られるオブジェクト指向プログラミングやMVCの定義を一言で言い表すのが難しいものではないとします。

なぜWebが成功したか

Webの成功要因として、次の4つのアーキテクチャ特性を挙げました。

低い参入障壁

利用も作成も簡単
マニュアルもコマンドの暗記も不要
テキストエディタで作成できる

拡張性

クライアントの動作に悪影響を与えることなくWebサイトを変更できる
時間と共に変化するユーザーの要件に対応し、長寿命なシステムを意図する

分散ハイパーメディア

データとともに次にできる操作をサーバーが伝え,データと同じように扱う
クライアントの動作を壊さずサーバーの動作を変更でき、サーバーとクライアントが疎結合である

インターネット規模

無秩序なスケーラビリティを実現する
異なる部分がそれぞれ独立して配備できる

RESTの制約を通じてRESTの本質を理解する

RESTを理解する上で重要な4つのインターフェース制約と6つのアーキテクチャ制約、そしてその制約の前に立つNull制約やアプリケーション状態、リソース状態について説明しました。こうした制約を理解した上でいかにしてシステムを設計するかについても話は及びます。構築しようとしているシステムに必要な特性を洗い出し、必要な制約を選択していくことが重要であると強調します。

また、REST APIを設計する際にApplication state diagramを活用できることも示しました。そしてAPIで使われる言葉の意味、分類、関係を人間だけでなくマシンも理解できるようにするツールとしてALPSを紹介しました。

最後に、郡山さんは「新しいものに飛びつくのではなく、今ある技術を深く理解して積み重ねていくのが重要であり、技術の背後に何があるか、どういう人々がどういう意図で作っているかを理解することが必要である」と発表を結びました。

杉山祐一さん「改善失敗から学ぶ、レガシープロダクトに立ち向かうチーム作り。」

サイボウズの杉山祐一さんは、「⁠改善失敗から学ぶ、レガシープロダクトに立ち向かうチーム作り。」というタイトルで発表しました（発表資料⁠）⁠。

変更前の開発体制

はじめに、杉山さんが入社した時の体制について話しました。

当時はプログラマ同士のやり取りは、リーダーを含めて3人とだけ取れる状況だったそうです。コードに集中できる良い環境とも言えたのですが、闇も見えたとのことです。たとえば次のようなことです。

「このコードは読みにくいので、リファクタリングしてもいいですか」とリーダーに尋ねると、リーダーは「技術的負債箱に入れておいて」と伝え、実際に負債箱を覗いたところ既に100件以上が溜まっている状況だったそうです。「⁠負債箱に入れたらリファクタリングを開始してよいのか？」とリーダーに尋ねると、リーダーからは「次のバージョンの開発まで待って優先度をきめて実施する」旨を伝えられたと言います。

これは、社内の開発が数か月単位でのウォーターフォール開発だったためです。開発単位の中で難しい状況が発生していたために、このようなことが起きたと説明しました。

スクラム導入と失敗

杉山さんはこのような開発を改善すべきと考え、スクラム開発を取り入れようとしました。ただ、すぐに解決することはなかったようです。

スクラム開発はスプリントを繰り返す開発手法なので、とりあえず2週間ごとのイテレーションで回してみたそうです。数回回してみたところ、理想と現実のバーンダウンチャートで状態を確認すると、タスクの残り数が増え続け、消化が全く進まない状況を示してしまいました。

これは、スクラム開発が「計画」「⁠実施」「⁠振り返り」を行う開発手法であるにも関わらず、チームの中で「振り返り」を全く行っていなかったことが原因だったとのことです。

スクラムで振り返り：QAチーム編

振り返りの結果、さらに判明したのは「QAとプログラマで認識が違っていた」ことでした。これを踏まえ、QAとプログラマを完全に分けていた体制から、QA＋プログラマの１チームで開発を進める手法を取るようになったそうです。

その結果、実装を始める前に、実装範囲とテスト範囲を確認できるようになりました。またプログラマの知識とQAの知識を共有することで、お互いの作業が理解できるようになり、以前よりも開発が進めやすくなったと言います。さらに、スプリントの範囲の中で、プログラマ側がテスト範囲を理解できるようになったので、改善提案をしやすくなったとのことでした。ただ、以前に比べて、プログラマがコードだけに集中できなくなったというデメリットも挙げていました。

スクラムで振り返り：PMチーム編

さらに振り返りをしたところ判明したのは「プログラマ＋QAのグループとPMのグループにも認識差があった」ことがわかりました。この対応も、まとめてひとつのチームで進めていく手法を取ったと言います。

結果として、改善したいことの中に、抜本的な問題（リファクタリングの類の課題など）があったとしても、短いスプリントの中でテストを実施するかを試すような、柔軟な決断ができるようになったとのことでした。なお、PMのグループ統合については「組織変更したら部長がいなくなった」ことも付け加えていました。

スクラムで振り返り：製品文言修正チーム編

製品文言の修正といった小さいタスクも、修正のタスクを出しているエンジニアチームが修正までしてしまえばいいのでは？と考え、その改善を提案したこともありました。しかし、そのまま改善の提案を提出したところ製品文言のチームに怒られてしまったそうです。これは、エンジニアチームが製品文言チームの仕事を把握できておらず、ただ仕事をおろしただけになってしまったことに気が付けられなかったことが原因だったと振り返りました。

この問題に対応するため、非エンジニアな製品文言チームに対して、開発環境構築自体をシンプルにし、もろもろのドキュメントを準備するようになったそうです。その結果、文言開発チームもGitが怖くないという状況が作り出せているとのこと。さらに、製品文言チームが開発チームに対して、困ったときにいつでも聞いてもらえる関係性が作れたのが最大の収穫になったと話していました。

失敗して学ぶチームを強くする方法

次に、グループウェアGaroonの開発において、前任から引き継いで、自動テストを導入したときの話を取り上げました。

自動テストを導入するにあたって、ベトナムと日本のエンジニアで、コード品質の意識がそもそも違った点が問題になっていたそうです。ベトナムのエンジニアはスピードを重視したいとか、テスト実装コストが無駄だという考えを持っている人が多かったと言います。たとえば、CIが落ちている状態でも、実開発を優先させてしまっていたとのことです。

チームに「ルール」を課して品質をそろえようとしていましたが、うまくいってなかったそうです。杉山さんは、最初にチームの品質への意識をそろえて、「⁠ルール」ではなく「目的意識」を共有する必要があると感じたと言います。その際、杉山さんは「伝統とは火を守ることであり、灰をあがめることではない」という言葉を引用し、目的意識を共有する必要性を強調しました。

具体的には、拠点をまたいでのコードレビュー時に、『⁠リーダブルコード』をベースとして話すようにしたとのことです。『⁠リーダブルコード』の輪講前のコードレビューでは、主観の話に落とし込まれることが多く、その主観で議論が中断されてしまう結果となってしまっていたそうです。しかし輪講後は「書籍のX章にあるように○○と書いたほうがいいよね？」と指摘できるようになり、建設的な会話が続くようになったと話しました。

ほかにも、チームで勉強できる福利厚生として著名な開発者などを呼んでみることを実施しているそうです。

すべて解決？

このようにしてGaroonの改善は進めやすくなりましたが、17年の歴史に及ぶ負債が大変だそうです。さらに、振り返りのProblemの登録数がどんどん増えているのは悪くもあり良くもあると、杉山さんは悩ましそうに話していました。

最後に、今後も失敗しないことよりも失敗から学ぶ方法について考えたいとし、「⁠Garoonのプロジェクトでは、まだまだ失敗できる余地がある。たくさん学んで失敗して、チームを広げていきたい」と述べ、発表を締めくくりました。

前田直哉さん「プログラム未経験からたった3ヶ月で圧倒的な開発力を身につける〜スクラッチ開発の重要性」

SkillCampの前田直哉さんは出身地沖縄で貢献したい思い、地元に会社を設立して12年目です。前田さんはPHPを学ぶ際400時間ほど勉強したそうですが、無駄が多かったと振り返ります。そして、その無駄を省いてノウハウにして会社としてプログラマの育成支援も行っています。今回の発表では、その教育カリキュラムについて話しました。

理想的なエンジニアのためには「思考基礎体力」「⁠プログラミング基礎体力」「⁠PGスキル」「⁠SEスキル」「⁠PMスキル」「⁠タイピング、英語スキル」が必要であり、それを基礎として「進化系フルスタックエンジニア」を目指しているそうです。

プログラミング学習時のポイントとして、学習達成のゴールやそこまでの中間点を決めたり、都度確認をきちんとすることを挙げていました。確認が遅れがちだと正しく答えられても伸びないと言います。また、最初にフレームワークを使ってしまうとそのフレームワークの構造を理解しにくいので、スクラッチから開発してもらい、スクラッチ開発で作ったものをフレームワークに置き換えるのが良いと説明しました。

そして、このカリキュラムを体験した中学校の先生や製造業に勤めている人の感想を取り上げ、2人とも、スクラッチ開発の体験が良かったと述べていたことを紹介しました。

ライトニングトーク

恒例のライトニングトークが行われました。

カンボ@沖縄さん「Laravel + Nuxt.js + FirebaseでDXと開発コストを意識したSPA開発」

技術選定において「今後、市場で注目される技術」「⁠沖縄のあたりでは尖っている技術」「⁠開発コストが高すぎず、程よく挑戦したい」という観点で行ったそうです。

エンジニアが「よりよく気持ちよく開発したい」というDX（Developer Experience）から市場価値が高く、エンジニアが少ないのを技術を選定し、FirebaseとNuxt.jsを採用することで、「⁠日々の開発が楽しめるようになる」「⁠コードの品質がよくなり、保守性も高くなる」ようになりました、とのことです。

白井英さん「PHPでgRPCってどこまでいけるの？」

「PHPでgRPCは、まだ早かった」とのことです。

sogaohさん「PHP-CS-FixerをIDEに取り込ませてPSRを強制する開発スタイル」

PHP-CS-FixerをPhpStormとVisual Studio Codeで使うときのトピックを紹介しました。 PhpStormでブランチ切り替えのとき、LaravelのサービスプロバイダーはFile Watcherの設定にあるTool to Run on Changesを走らせない、とのことです。

阿波連智恵さん「レガシーコードでビジュアルリグレッションテストをやってみた」

静的ファイルや処理を削除したことによる画面崩れを検証にはビジュアルリグレッションテストを使うのが良いそうです。ビジュアルリグレッションテストの良いところは、表示崩れを検出できること、テストの用意が容易であることだと挙げていました。テストのない環境で表示崩れが怖くてリファクタリングができていない方に特にお勧めとのことです。

清家史郎さん「PHP on AWS Lambda！」

PHP on AWS Lambdaは、普通のPHPとして使えて、scaleが必要な処理には爆発的な効果を発揮し、PHPはServerlessにできる、とのことです（発表資料⁠）⁠。

瑞さん「2年目エンジニアがスキルアップのためにPHPtで競プロやってみた」

協議プログラミングコンテストのAtCoderを使ってチャレンジする際、PHPtというテストコードを発見したそうです。

しろぐちゆうまさん「設計文化のないチームに文化を広めたが冴えない一手で混沌を招いた話を聞いてほしい」

メンバーからの問いには、時間をけずって説明する資料を作ることが大事だそうです。設計について討議し、説明はさぼらないことが重要だとしました（発表資料⁠）⁠。

大重智志さん「運用経験ばかりのメンバーと新規開発で初めてしっかりと設計から開発までを経験した話」

APIを作成するとき、クリーンアーキテクチャを採用しました。その際に、全エンドポイントのモックを作成、チームに導入しやすいようにサンプルを用意し、率先してPull Requestに目を通したとのことです。正解が誰もわからない問題に対しては議論することが良いことだったそうです（発表資料⁠）⁠。

うゐろうさん「エンジニアがブログや登壇で、アウトプットするとどうなる？」

ブログを書くと人生が変わります、とのことです。ブログで「フィードバックがもらえる」「⁠自信がつく」とし、そして登壇するようになったそうです。

高野福晃「余裕を生み出すコードレビュー」

レビューコストを下げるには、「⁠変更の意図がわからない」「⁠変更内容がわからない」「⁠確認方法がわからない」の3つのわからないことを減らすだと説明しました（ブログ、発表資料⁠）⁠。

やなせたかしさん「社内最長老のシステムにPHPUnitで立ち向かう方法」

レガシーなシステムで、5,000行あるものを大胆にモック化してテストを行った話です。テストについては取捨選択をしたそうです。「⁠カバレッジ100%は単なる安心感」として今回は問題を切り分けとのことです（発表資料⁠）⁠。

田島裕介さん「開発合宿のススメ！」

Hamee株式会社が考える開発合宿について話しました。「⁠最初にゴールを決める、決まったことは実行者も決める、あとは行動あるのみ、行動しないと何も変わらない」と紹介しました。それから合宿後も、きちんと動けているのかを追ったほうが良いとのことです。