※2018/12/19 資料公開に伴い加筆修正

PHPユーザ最大のイベント「PHPカンファレンス」に今年も行ってきました。そのセッションの中でも印象に残った下記3公演を振り返ります。

・マイグレーションアンチパターン
・VOYAGEのエンジニア評価制度ってどんな感じなのか25分でミニ再演
・レビューで初心者インターンを一人前に育てた話

Track6『マイグレーションアンチパターン』

株式会社鎌倉新書という、ライフエンディング系メディアを運営している会社のお話。「いいお墓」「いい葬儀」といった主力のサイトと、地域などに特化した複数のサテライトサイトからなる構成です。

これが半年前までフレームワーク無し、ドキュメント無し、テストコード無し、AWS EC2(IaaS)×1台にアプリケーションもデータベースもすべて詰まった状態で、ソースコードはFTPアップロードでデプロイという、なかなか攻めた構成。むしろ、この構成でわずかにAWSを使っているところに最低限の努力が見えてしまいます...

ここからマイグレーションしてLaravelに移管した、という話でした。発表者(＝マイグレーション担当者)は入社数ヶ月で仕様に詳しくもない、さらに正直Rubyのほうが得意、という中で、社内担当者1人でLaravelへの移管をやり遂げたとの事です。(社外にオフショアの開発チームとブリッジSEがいたそうです)

発表では「アンチパターン」としてプロジェクトにおける要所が紹介されており、例えば...

「繁忙期前に一気に切り替えようという、締切ありきのスケジュール」
→マイクロサービス化して段階的にリリースし、切り替えの影響を少なくした

「切り替え直前1ヶ月でまとめてテストしようというカツカツの検証期間」
→疎結合なモジュールごとにテストし、開発と検証を並行して進められるようにした

「不具合修正の優先順位付けができない」
→最優先の「他のテストに依存している不具合」>次に「リリースまでに直すべき不具合」>最後に「リリース後でも良い不具合」と、3種類に分類した(細かすぎてもアンチパターンだと言われていた)

「不具合の重要度または影響度を、数値で把握していない」
→メインではないサテライトサイトでの不具合は発生しても影響は無いと、上層部より"口頭で"貰っていたためテストを疎かにしていたが、ちゃんと数字で確認するべきだった

...といった内容が赤裸々に語られていました。

質疑応答にて、マイグレーションをやり遂げてみて「現状はソースが汚いまま。これからはリファクタリングのフェーズ。旧システムのコードをそのままコピペした箇所があり、Laravelを使っているもののView内にロジックが残っており、ORMも使ってない」と語っており、システムリプレースは一筋縄ではいかないというのを改めて実感させられる内容でした。

----

この公演以外にも、他のいくつかのセッションでもシステムリプレースやPHPバージョンアップの話はされていました。その中でも多くの事例で「リファクタリングはしない」と語られていたのが印象的でした。

システムリプレースで「せっかく新しくなるから」と、何でもかんでもやろうとするのは危険なのだと思います。セキュリティ向上やスピード改善なのか、機能追加なのか、リプレースで何を実現するのか、実現しない事は何なのかを決めるのが大切だと思いました。

なお、昨年はこういったシステムリプレース開発やレガシーシステム保守運用の話に絞ってセッションを聞いてきたので、去年書いたBlogの方がよりまとまっています。関係ないですが昨年のほうが自分の文章が上手い気がします。

Track4『VOYAGEのエンジニア評価制度ってどんな感じなのか25分でミニ再演』

こちらは評価の話。エンジニアの普段の業務改善のような、地味な取り組みをどうやって評価して給与にフィードバックするか、という話でした。

VOYAGEさんはエンジニア評価において、「技術力評価会」という、被評価者1名に対して評価者2名・発表30分+質疑応答60分の会議をしているようです。その内容を"再演"する形でセッションが行われていました。

「技術力評価会」において、被評価者は評価期間(半年に一度？)のあいだの成果の中から、自身の評価してほしいことをMarkdownファイルにまとめて準備し、発表します。それも課題の背景や前提(人員リソース制限とか)から実際にやったこと・やらなかったことまで、とても詳細に書かれていました。このMarkdownを用意するのに相当な準備時間をかけているんだろうな、という印象でした。実際に、準備段階においては「サポーター」と呼ばれる方が被評価者の発表内容をサポートしてくれるそうです。

作成されたMarkdownファイルのフォーマットは、ざっと見て下記の通り。

# タイトル
## 概要
例では「ポイント失効の自動化」について、数行で説明。

## 背景
なぜそれをやる必要があったのか、という背景。
例として「ポイント失効」という仕組みがあることや、どういうエンジニア対応が発生しているか、リスクになりうる点などが記載。結構長い。

## 事業理解・ユーザ理解
ターゲットユーザ、今回の例では作業をするエンジニア自身が対象のため特殊だが、恐らくエンドユーザやクライアントについての詳細が記載される事が多いと思われる。

## 制約
スケジュール、人員構成などの前提条件。

## スコープ
工夫したこと、いつまでに何をしたか、そして何をしなかったか。例ではプロジェクト管理ツールのissueと思われるリンクが記載されていた。ここも長い。

## プロジェクトの進め方
時系列に沿った経緯。いつ、なにをしたか。

## システム構築
コードベースで、例ではGitHubと思われるリンクが掲載されていた。

## 開発・運用環境
テストツール、デプロイツールなどを記載。

## 評価してほしいポイント
例としては「プロジェクトの進め方」「リカバリーしやすい作り」が記載。

かなり直感ですが、恐らく数千～1万文字程度のボリュームだったのではないかと思われます。

解説にて「評価する側は、やった事、できている事は評価しやすい。しかし、やっていない事、切り捨てた事は見えないことが多いので、しっかりアピールしてほしい。やってない事は評価しにくいが、A・B・Cというパターンを洗い出した上で他の選択肢をやらないと決めましたという判断は大切」と語られていたのが印象的でした。今回の例で被評価者の改善したポイントシステムについて、システムそのものの仕様の見直しも検討されましたが、対応にかかる工数やステークホルダーの大きさから、適切な対応内容に改めたという話がありました。

なお、この発表は公演自体が「実際に社内で使われた(と思われる)評価資料とフィードバック内容」を元に構成されており、セッション内でも「このMarkdownはだれでも見える所に置かれます」と何度か言っていました。セッションではあまり明言されていませんでしたが、この会社は評価プロセスが凄まじく透明化されているという印象を受けました。おそらく簡単な事ではないと思いますので、この評価プロセスの透明化に相当な力を入れているのではないかと思いました。

20190114追記:

Blogが公開され、私の質問も回答いただいていました。

【回答】
せっかくなのでアンケートを取ってみたところ、
「評価会資料の作成にかけるのは2日未満」という人が8割でした。

初回は時間をかけた人も、何回かやっていくうちに
かける時間が短縮されているようです（僕もそうでした）。

Track5『レビューで初心者インターンを一人前に育てた話』

こちらはユアマイスターという会社の事例。前提としてこの会社、社員十数人に対してインターン生40人ぐらいという、凄まじい構成比率になっています。

まず最初に挙げられたのが、40人近い学生に対して「何を求めてインターンをしているか？」というアンケートを取った結果。

・自身の成長のため: 100%
・業界研究のため: 0%
・就職活動の自己PR等に使いたい: 0%
・志望企業(インターン先)をより深く知るため: 0%

という嘘のような結果が紹介されていました。インターンの内容や会社によっても状況は異なると思いますが、とにかく「インターンはなによりも成長を求めている」と言えると思います。受け入れる側の社員は、いかにインターンで成長の機会を作れるか？というのが重要です。

とはいえ、受け入れ側の社員もエンジニアであって、プログラミング講師のような教えるプロではありません。この会社はベテランと言えるエンジニアの数も少ないようで、その中でいかに成長できる環境を作ってきたか、というのが話の鍵でした。「教える」のではなく「成長を促す」と語られていました。

公演では成長のチャンスを生む「苦い薬」として下記3つが挙げられていました。

・レビュー前の「関係性の構築」
まず心理的安全性を確立します。たとえば分報、times channel、Working Out Loud等と呼ばれるような方法を使ったり、1on1の実施、日報を書いてもらってリプライする等、とにかくコミュニケーションを増やして信頼関係を構築します。

・レビュー中の「明確な伝達」
コードレビューには事前にセルフレビューチェックリストを作ったり、コーディング規約の徹底はLintに任せたりします。特に「成長の機会を奪わないように」と語られていたのが胸に突き刺さりました。私もよく「ここは自分がやる！」とメンバーのチャンスを奪いまくっているので、反省です。

自戒としてよく取り上げる記事:

「代わりに問題を解く」のではなく「問題の構造を示す」ように、と語られていました。たとえば「ここはこう直す」ではなく「ここは直さないとどうなる？」のような感じのフィードバックでしょうか。大切ですが、なかなか難しいです。

・レビュー後に「結果を共に確認」
フィードバックには結果の確認をセットで行い、うまくいったら自分のことのように喜ぶことで、共感します。ペアプロが最も手っ取り早いフィードバックの手段として語られていました。

この会社は決して規模が大きいわけではないようですが、こういったインターンの成長を促す環境・仕組みに注力しているお陰で、多くの人数のインターンを受け入れることができているようです。

その他

今回は会場でランチの販売は無かった反面、ランチセッションでお弁当の提供があったようです。しかしすぐに満席になってしまっており、私は入ることはできませんでした。

当日の会場インターネットもずいぶん快適でした。今回はネットワークスポンサーにGMO ConoHaさんが付いていました。ちょうど行きの新幹線でVPSを1台立ててきたので、この日はConoHaさんにお世話になる一日でした。