PHPカンファレンス北海道2019に参加していました
ブログを書くまでがカンファレンスということで、もう二週間以上も前のことですがPHPカンファレンス北海道2019に参加していました。今回は初めてスタッフとしての参加でした。
スタッフをやることを決めたのは去年の6月末、PHPカンファレンス福岡2018の興奮冷めやらぬ頃でした。PHPerKaigi2018でカンファレンスにハマり、一般参加、登壇者と経験して、次はスタッフをやってみたいと思っていた矢先のことです。
PHPカンファレンス北海道2019の開催をここに宣言します。
— マキ (@makies) 2018年6月28日
と言ってもいま現時点で誰にも言ってないし相談してないし私が勝手にやるよって言い出しただけなので何も決まっていません。時期・会場ともに完全に未定です。北海道在住の方もそうでない方も、スタッフやるよ！とか当日お手伝いするよ！っていう方がいたら、ぜひぜひ @makies 宛にご連絡下さい。
— マキ (@makies) 2018年6月28日
キックオフで石鍋亭に行った時の写真が今年の2月の撮影だったので、半年強の準備期間があったことになります。最初はじわじわと、徐々に加速しながら計画が形作られていく様を見ることが出来ていい勉強になりました。運営経験豊富な歴戦のスタッフも多く、「何を考えるべきか」がわかっているというのがとても安心感があったのを覚えています。
自分はCfPの作成や登壇者の対応など、これまでの経験から想像しやすい仕事を受け持ちました。PHPの現場でカンファレンス運営の話を度々聴いていたとはいえ、それ以外のところは本当にわからないことだらけの状態で、周りに頼りきりでした。普段の本業は積み上げてきた経験の上でやっているので、こういう機会にレベル1の状態で仕事をすると、初心に返る感じがしていいですね。次の機会があれば、もう少し動けるようになると思いたい。
当日は一階の受付とアンカンファレンスの担当で、入場のラッシュの後は結構暇がありました。今思えばこの隙に3階のメイン会場の様子を見に行かせてもらえばよかったです。結局一度も目にしないまま終わってしまって、もったいないことをしました。セッションは全部面白かったと思います。聴けなかったですけど。
すごい、映画館みたい。#phpcondo pic.twitter.com/QQ7FXKiaaz
— しめじ | Kaga (@TAKA_0411) 2019年9月21日
今回の会場は1階と3階に分かれていて、人の移動が起きづらいのではないかという懸念がありました。実際午前中は1階に人が少なかったのですか、スポンサーセッションが始まる頃から徐々に流れができ始め、アンカンファレンスのほうも観覧席の急遽補充が必要になるほどの盛り上がりを見せてくれました。それにしてもこのアンカンファレンス、密度が非常に濃いですね。登壇してくれた方はありがとうございました！
正直、登壇者参加のときより緊張していたのですか、蓋を開けてみれば大きなトラブルもなく、参加者数も目標を達成し、みんなが楽しめたようで大成功だったと言っていいんじゃないでしょうか。当日までどんな雰囲気のカンファレンスになるのか本当に想像がつかなくて、スタッフに出来るのは場を用意することまでなのだということを実感しました。「カンファレンスは一般参加者、登壇者、スポンサー、スタッフ全員で作っている」という当たり前の原点を言葉ではなく心で理解できたと思います。PHPカンファレンス北海道2019に関わっていただいた全ての方々に、お疲れ様でした！
アルプ株式会社に入社しました
2月1日からアルプ株式会社で働いています。社会人になってから4社目、2年3ヶ月ぶり3度目の転職です。
どんな会社か？
ググってもまだWantedlyとコーポレートサイトくらいしか出てこないと思うのですが、サブスクリプションビジネス向けの決済基盤・契約管理のSaaSを作っています。元pixiv代表の伊藤さんの会社と言ったほうがピンとくる人が多いかもしれません。開発言語は主にScalaとTypeScriptです。実はScalaMatsuri 2019のスポンサー欄にも名前があります。
なぜ転職したのか？
前職のインフィニットループは文句なしに働きやすい会社でした。入社直後から色々やりたがる新人を煙たがりもせず、いくつかのプロジェクトのアーキテクチャや開発プロセスに大いに口を出させてもらえました。カンファレンスへの参加や登壇のサポートもしていただいて、コミュニティで活動する楽しさを知るきっかけにもなりました。お陰様で今では立派なカンファレンスジャンキーです。
転職の動機は端的に言えば、「自分が次にジョインすべきプロジェクトはこれだ」という強烈な確信を抱くに至ったからです。意識的に転職先を探したのではなく、次にいっしょに働きたいチームがたまたま社外にあったという感覚でした。気持ちが固まったのは去年の11月末頃、折しもインフィニットループで携わっていたプロジェクトのリリースが迫っていた頃合いで、次に社内でどう動くか考えていた時分でもありました。
決済基盤との因縁
思えば前々職のpixivにいた頃は決済にまつわるコードばかり書いていた気がします。新しいサービスを作る度、新しい決済方法を追加する度に外部の決済システムのドキュメントを読み込み、サービスに組み込む作業を何度となく繰り返しました。サービス数×決済方法の数だけ実装が増えていくのが辛くなった頃、自社サービス向けの決済基盤をマイクロサービスとして切り出すプロジェクトを立ち上げました。この時、ビジネスサイドの采配を取ってくれたのが伊藤さんでした。伊藤さんとはそれ以前にもBOOTHの立ち上げなどで一緒に仕事をしていて、自分にとってはマネージャーの理想像とも言える人物の一人です。アルプの話を聞いた時、勝手ながらこれは自分たちのプロジェクトの続きだと感じました。しかも今度相手にするのは世の全てのサービスで、扱う問題領域も遥かに複雑になるとなれば、心に火がつくのも無理からぬ話だと思います。
これからどうしたいか
まずはサービスのリリースが最大の課題ですが、同じくらい重要なのは組織の文化を作っていくことだと思います。成熟した会社の性質を変えるのは容易ではないですが、最初期のチーム作りに参加できるのであれば、ここで蒔いた種は会社の成長とともに広がっていくはずです。自分は引き続き札幌からの参加になります。リモートワークという条件は枷にもなりますが、オフィスという場所と固定化された時間に縛られないチームを作ることができれば、それは良い文化の土壌になるのではないかと考えています。
本当の意味での創業期に立ち会うのはこれが初めてです。やるからには今までに経験したことのない、新しい形の組織に育てていきたいと思っています。そして、それが可能だと思える最高のメンバーが集っているのも楽しみなところです。
＊追記：欲しいものが思いつかなかったのでウィッシュリストを載せていなかったのですが、妻との協議の末、こちらのリストが完成しました。
集約とトランザクション境界に関するメモ
この記事はドメイン駆動設計 #1 Advent Calendar 2018の22日目です。
昨日は@crossroad0201さんによる「DDDの構成要素とマイクロサービスの単位をどう合わせるべきか」でした。
今日はエリック・エヴァンスのDDD本に書かれたパターンの一つである集約について、自分なりのまとめを書いてみたいと思います。実は以前まで集約については「言いたいことはわかるが実践で使う意義がいまいち見いだせない」というスタンスだったのですが、最近になってようやく腑に落ちました。
バートランド・メイヤーの契約による設計
DDD本のパターンの多くは、オブジェクト指向プログラミングで築かれてきた理論や原則に基づいたものです。OOPの理論で特に有益なものの一つに、契約による設計というものがります。これは鈍器としても名高い『オブジェクト指向入門』*1の著者であるバートランド・メイヤー博士が提唱したもので、簡単に言えば以下のような設計スタイルのことです。
- クラスは、そのインスタンスがライフサイクルの間、常に守らなければならないルール（クラス不変表明）を持つ
- クラスの利用者は、あるオブジェクトのメソッドを呼び出す時、そのメソッドが正しく働くための前提条件（事前条件）を守る義務がある
- メソッドは事前条件を守って呼び出された限りにおいて、予め定められた契約（事後条件）を守る義務がある
- オブジェクト生成命令（コンストラクタやファクトリメソッド）及び、コマンド（副作用のあるメソッド）は、クラス不変表明を守る義務がある
このスタイルを守ることで、プログラムが想定通りに動かなかった時にどのコードが契約違反を犯したのかが明白になります。また、プログラム言語によってはアサーションという仕組みを使うことで、契約違反の発生を即座に検出することが可能です。これを使うと問題のあるコードが実行されたまさにその場所でアサーションエラーが発生するので、バグの原因調査が著しく楽になります。
この辺りの要点は、@t_wadaさんがスライドにまとめられています。
【改訂版】PHP7で堅牢なコードを書く - 例外処理、表明プログラミング、契約による設計 / PHP Conference 2016 Revised - Speaker Deck
続きを読む