例年行っているのと、今年は知り合いのスタッフ参加が多かったので遊びに行くことに。 あとコミュニティ運営、大人数の参加者をさばくイベントスタッフの動きとかもちょっと観察できればいいかなーとか。（2019年はイベントスタッフとしても暗躍したいなと少し思ってるので）
以下、感想です。
午前
あまり興味があるセッションがなかったため、企業ブースを中心に回って見る作戦で行った。
以下、印象に残ったスポンサーのところとか。
- VOYAGE GROUPさん：ajito fm の話とか、エンジニアの評価制度の話で盛り上がった。ちなみに13時からVOYAGE GROUPさんのセッションがあったが、最初から見に行くつもりだったのでじっくりブースにある資料を読ませていただいた。
- 弁護士ドットコムさん： 法律×ITでクラウド契約書やってるとか、法律的にどうだろうってときに調べるとめっちゃ見つかったりするので、普段から見てますめっちゃありがたいですって話をしてきた。弁護士の労働環境を変えるために様々なことしてるんだなあみたいな印象を受ける。
- SCOUTERさん：リクルート用のチラシが印象的だった。また、 VALUEを音楽的な価値観で示している（採用サイトに書いてあった）のもカッコよさがある。
- GMOインターネットさん：会場でISUCONじゃないですけど、チューニングバトルをやってた。最後まで結果見れてないんだけど、どうなったんだろう？
- LIVESENSEさん：転職ドラフトの最近の話とか、登録大変でした！つらい！とか言ったらですよねーみたいな話をしてきた。気が向いたら登録し直してみよう。
- LIFULLさん：（割と本業と近いところの仕事をしている会社さんなのだが）結構最近勉強会開いているみたいな話をしたり、MAP検索めっちゃ便利ですよね革命！って話をした
- 楽天さん：この前のTech Confの話をちょっとしてきた。サービスが無数に有って無数の言語とフレームワークが動いてるの、大変そうではあるけど、様々なフレームワークに関する共有知識がすごく多くなりそうで刺激的なんだろうなあ。
- JetBrainsさん：謎のパズルについて聞いてた（実物がないと分かりづらいけど）。なんかゴール的なものは自分で設定して適当に疲れたときに遊ぶといいよってアドバイスを貰った。あと自分が買うならAll Packageしかないな～みたいなのをぼんやり思う。
という感じで終わり。書籍はサインもらえるけど、なんかいいかなーで（積んでる本が多いので）スルーしてしまった。もっと本を読まねば。
午後
セッション4つ見てLT見た。PHPはあまり詳しくないので、Webとエンジニアリングにフォーカスして聞いている。
VOYAGEのエンジニア評価制度ってどんな感じなのか25分で再演 ー 地味な仕事でも、技術力は評価される ー
スライド： https://speakerdeck.com/yukimine/show-voyage-group-tech-assessment
事業貢献はしているが、裏側だったり目立ったなかったりしたときにどうアピールするか、評価するかについて話を聞いていた。
どちらかといえばPHPというより、VOYAGE GROUPさんの技術評価制度の話メイン。
- VOYAGE GROUPさんの技術力評価会という制度自体がすでに良さそう、昇格者は社内告知されるとかも良いなあ
- 評価書のプロセス（概略）
- これをもとに評価、フィードバック
- 結果は達成できてるけどテストもうすこし厚くしたほうが良かったねとか、そういうフィードバックもされる
詳しく聞きたい場合は次の勉強会に来てくださいとの感じでした。
個人的にはやらないことをまとめるの大事だなあと感じていて、例えば機能実装のときについでにリファクタしたいなっていうのもあるんだけど、それもどこまでやるっていうのは割と明確にしとかないとハマるなーっていうの身に覚えがあり、改善しなければと思いました。
あとは評価を書くときのポイントとかにするとか。自分が書いてるときは割とやったことベースでしかかけていないが、もう少し将来図を見るとか、コストとの関係を考えることがあるなあと感じました。
ユニットテストが入れられないレガシーなソースでCIが回せるようになった
スライド: https://speakerdeck.com/miurakatsu/yunitutotesutogaru-rerarenairegasinasosudecigahui-seruyouninatuta
リプレース案件でいろいろ問題をついでに解決する。svnとか、その他の開発環境がはびこっている中、gitに寄せ、デプロイ環境もリプレイする感じの話。
そして結局設定とかサーバーとか考えていくうちにDockerにいきつき、Dockerで設定をしてやってやれるようにしていたとか。
大事だなと思ったのは開発手順を変化させ、それを開発チームに理解させ、開発文化として続けるようにすることかなと思った。 せっかく良い仕組みを作っても使って改善して行けなければ意味がないので、文化的に作っていく必要があるんだなと感じた。
またやっぱり開発環境を考え出すと、Dockerはすぐ選択肢に上がり、Docker-Hubで探すみたいなのが良さげなフローっぽい。マスターしなければ。
あと Codeception は聞いたことがなかった。PHP用のテストフレームワークらしい。
苦手！！フレームワークを克服するには
これちょっと会場に入れなくてサテライトで流し聞きだったので、メモだけ貼る。
フレームワークに沿って勉強するのが良い。しかし開発環境が難しい。 環境構築でつまづきがちになる。そのときに役に立つのは書籍、動画だったりする。なので、出し惜しみをせず書籍を買うのが大事だったりする。 そしてガチで勉強したいならスクールとかに行くべき。仲間とかと一緒にやるとうまくいきがちである。 Docker、Vegrandを使ったりする、Could 9を使ったりする、MAMP環境。 容易なのはLAMP環境だったり、Could 9だったりする。 仮想サーバーが立ち上がるので勉強できる。 Laravelを構築しながらやると決まったLinuxコマンドが覚えられるので良いですね。 MVCとMVP、MVVMの違い。MVCが非常にわかりやすい。 https://qiita.com/shinkuFencer/items/f2651073fb71416b6cd7 Larabelフレームワークのいいところ、セキュリティ、たくさんのメソッド、etc... アプリリリースが目的ならいいと思います！ あとMVCっぽく使ってみよう！
全体的な感想で言えば、PHPは自分自身も何となく分かるので、Laravelを始める際にどう勉強するかが大事なのかなと思った。スクールに通うは自分の価値観と時間コスト考えたときに選択肢にできないけど（選択肢にする人がいても当然いいと思いますが）、Webの情報を見ながらよりも書籍を読んでガッツリ写経しつつ作るみたいなのは最近やれてないので、やらなきゃなあと思いました。
技術者が企画力を上げたら鬼に金棒。プログラマー向け企画書の書き方
ちょっと自分の肌には合わなかったかなという感じ。（どちらかといえばプロダクトマネージャに移ろうとしてるエンジニア向け？ ）
結局、企画を通すというのもロジックで理由付けを以下にするかが大事という話だった。 エンジニアが強いのはデータとロジックなので、主張、データ、理由付けのロジックをうまく組み合わせて企画を上げて提案していこうって感じだった。
とはいえ、この話エンジニア向けにいるのか？みたいなところは若干疑問視…。PHPの話も出てきてないしなあ。（ちょっと他の人からこの公演についての感想を聞いてみたい感じ）
Webサービスを育てるための組織作りと文化作り
スライド: https://speakerdeck.com/soudai/proper-problem
組織はマネージャー、文化はプレイヤーが変えていき、良い開発環境に全員でしていく話。とにかく 変化に強い組織づくりが大事である 。
Webサービスを育てるにあたって、意図した成長と意図しない成長があるが、意図しない成長はしてほしくない。（変な使われた方をされていくので） それ以前に、Webサービスは開発チームの文化がそのまま反映されたものなので、良い文化を作っていくことが大事になる、というのは共感できた。（コンウェイの法則に近い考え方らしい。この辺 を参照）
一方、組織は意図的かつ目的を持って構成されているものに対して、プロジェクトやチームは偶発的でそのときいるメンバーに依存してしまう場合も多い。 それを上手くコントロールためには、適切な大きさの問題を解決し続けることが大事だという話。OSS等もそれと同じ仕組みで回っている。
- 問題を適切なサイズに細分化する
- 問題のサイズに適切な人をアサインする
- 問題解決できるように人を育てる
しかし、誰にも適切でないサイズの問題や、誰もいない問題がある？ その時は人を連れてくるし、人を育てるしが大事。
またチームメンバーが成長するタイミングは
- 行動をしたとき、またその最中
- 結果を振り返ったとき、失敗成功問わない
- 自分の限界を超えたとき
で、限界よりも少し大きな問題にチャレンジできる文化を作っていくのが大事で、ここは制度等で組織が心理的安全性を用意していくことが大事。
それな！！！しか思うことがなかったので、スライドをもう一度読み返して置こうと思う。
あとこの記事を後で読む。
DBの寿命はアプリより長い！ 長生きするDBに必要な設計とリファクタリングを実践から学ぶ #エンジニアHub - エンジニアHub｜若手Webエンジニアのキャリアを考える！ https://employment.en-japan.com/engineerhub/entry/2018/12/11/110000
あとこの辺の質疑応答も良かった
- 向上心の無い人に対する問題の与え方？
- A.クオリティとかを目指させる。小さな成功体験を与える。
- コミュニケーション頻度？
- 週1の1時間のミーティングよりも、10分で毎日で、小さいコミュニケーションとる。マネージャーと現場の認識がずれないように日々改善していく。
LT
印象に残ったものだけ。雑多なメモしか残っていないので。
20代が考えるエンジニアキャリア論
メモだけ貼る。柔軟性が大事。
エンジニアのキャリアにとって大事なことは「柔軟性」 キャリアップのために、勉強する？仕事頑張る？転職活動？政治力？環境？ 今日は環境をテーマについて考える 会社、エンジニア、技術、組織、家庭 変化に対して柔軟な姿勢を保つこと→依存しない、選択肢を広く持つ、精神論、楽しむ、筋肉を鍛える
発表駆動開発を一年間実践してきて今
めっちゃこれわかるー スライドも見ましょう。
「やりたい」を実行するための良い手段、周辺知識が身につく、知らないことに気がつく、 懇親会で話しかけてもらえる（最重要！最重要！これ僕もめっちゃきつくて懇親会はご飯食べて帰りがちになってしまう） これめっちゃわかるなああああああああああしか言うことがなかったです。
というわけで、2019年はもっと多くの発表ができるよう、仕事もプライベートも頑張ろうって思いました。
個人サービスを最速でPHPからGoに置き換えたときにやったこと・やらなかったこと
個人開発の敵は飽きてしまうこともめっちゃわかるなあ・・・。で、やりたいことをフォーカスいて、いい感じにリプレイスしていく、っていうの学び多くて良さそう！ってめっちゃ思いました。
趣味でサービスを持つと技術の取捨選択や開発環境の構築、言語やFWの特徴も抑えられて業務でもめっちゃ役立ちそうですね！
ハニーポットから見たWebサーバへの攻撃
実際にハニーポットを立ててる人の話を初めて聞いたけど、めっちゃ面白かった。特にどのような攻撃が想定されるか、直アクセスが有るかとか、めっちゃ勉強になったので興味が出てきた。
トウダン・ジャーニー 〜 PHP カンファレンス関西 2018 登壇までの道 〜
組織レベルで登壇を応援するのはいい感じだなあと思った。
まとめ
PHPやるならLaravelなのかなあと、Dockerで開発環境を整えることができるようにならないトナーっていうのを強く感じた。
