ありがとう、カルテット

3年と7ヶ月勤めた株式会社カルテットコミュニケーションズを、10月31日をもって退職します。本日が最終出社日でした。

カルテットコミュニケーションズでは、システム開発部のエンジニア兼マネージャーとして、コードを書くことはもちろん、プロダクトのソリューション設計、利用部門との調整、および開発したプロダクトの運用など、プロダクトにおける上から下まで幅広く携わりました。加えて、チーム/組織としての動きの改善や、メンバーの教育、採用向けの試験問題の作成から評価といったことにも携わりました。システム開発部は10人に満たない小さなチームですが、本当に良いメンバーに恵まれ、さまざまな困難にぶつかっても乗り越えてきた、個々のメンバーのいろいろな個性が活きていながら団結力もある凄いチームだと、自信を持って言えます。私がこのチーム、この会社で仕事をした経験は、確実に私の自信を強く支えるものになっています。カルテットコミュニケーションズで一緒に仕事をしてくれたみなさん、本当にありがとうございました。

私がカルテットコミュニケーションズで働く以前、自分が設立した、社員が自分しかいない小さな会社で受託開発をメインにやっていました。そこでは、自分の技術力を上げて、効率よく品質の高いシステムを作り上げて納品するということが興味の中心であり、我ながらかなり上手くやれていたと思います。しかし、うまく仕事をこなしながらも、「なぜこんなシステムが必要なんだろう?」と疑問に感じる開発、「これをやる前に、別の所の仕組みを作ればもっとよくなるはず」という思いを押さえ込みながらの開発がポツポツと出てもいました。その度に、本当に解くべき問題が、自分の立ち位置からは手の届かない距離の場所にあるということに、ある種の絶望のような感覚すら抱くようになっていました。根本にアプローチできる立ち位置にいなければ、自分が納得できる仕事ができない。いつしかそのようなもやもやとした感覚がなんらかの閾値を超えて溢れ、ついには転職を決意しました。次に働く会社では、自分たちでビジネスをしていて、自分たちのビジネスのためのシステムを作っている、そんな会社で仕事をしたい。そこでなら絶望せず、有意義に仕事ができるはずだ。そう考え、カルテットコミュニケーションズに入社しました。そして最初に書いたように、素晴らしく有意義な仕事をさせていただきました。

このような恵まれた状況下で働けていたにも関わらず、なぜ転職するのか。それは、私自身が「タイミングをつかんだ」からという、理由にならないような理由です。私は今43歳です。本当の意味で大きなチャレンジを今しなければ、自分の人生はその類のチャレンジをしないまま終わるのではないか。そんな危機感が年々強くなっていました。私にとっての本当の意味での大きなチャレンジとは、より大きな組織での役割、グローバルな環境、大きなうねりの中での自分の価値の発揮、そして組織と自分のより大きな成功、これらのチャレンジに値すると自分が納得できるだけの報酬。これらすべてです。そのチャレンジにあてはまる「タイミング」を感じ取ったら、動くしかありません!

 

転職先は、株式会社メルカリです。

メルカリのバックエンドチームのマネージャー(エンジニアリングマネージャー)という立場で仕事をします。

この立場での私の個人的な夢は、チームメンバーの技術、チームメンバーの幸福、チームメンバーのアウトプットを、いずれも世界に誇れるレベルだと言えるようにすること。そしてそのようになった時に、自分もそのチームの一人のエンジニアとして技術に携わっていること。これを実現したいと思っています。

東京で開催されるいろいろな勉強会などにも、積極的に顔を出したいと思っていますし、いろいろな方とお会いしてお話したりもしたいと思っています。お気軽にお誘いなどお声がけください!

 

昔作成したPHPUnit/TDDの記事内容を更新してGitHubに置きました

昔CodeIQにPHPUnitでTDDを行う記事を寄稿したのですが、CodeIQが閉鎖になって以降、「あの記事また読みたい」とリクエストがあったため、内容をわずかに更新してGitHubに置きました。

github.com

以前作成したコードの日付をみたら5年前だったんですね。書き方がいろいろ古い箇所があったため、比較的最近っぽい(PHP 7の)書き方に修正してあります。

解説の仕方や図など、今見るとうーんとなってしまう点もありますが、この内容でもリソースとして役立ちそうなので、そのあたりはいずれブラッシュアップするということで、一旦公開します。

 

メモ:ドメイン駆動設計におけるモデルの効用と、モデルが満たすべき3つの基本的用法(私訳)

日本語版『エリック・エヴァンスのドメイン駆動設計』p.3の、「ドメイン駆動設計におけるモデルの有用性」の部分、大事なことを言っているような箇所なのに、文章のつながりや意味がイマイチとれなかった。そこで原著Kindle版を購入し、原文から自分なりに訳してみた。(私の訳文は若干補足的な文章になっている)

なお、この箇所は見出し(効用/有用性)と、中の箇条書きの構造とがマッチしていないので読みづらいのだと思う。各箇条書きの最初の文が「基本的使用方法」、つまり、モデルに求める条件となっていて、それを満たすとどのようなありがたいことがあるのか(=効用/有用性)の説明が続く、という構造なのだと思う。

 

The Utility of a Model in Domain-Driven Design

ドメイン駆動設計におけるモデルの効用

 

In domain-driven design, three basic uses determine the choice of a model.

ドメイン駆動設計では、モデルが満たすべき3つの基本的用法をチェックして、モデルの候補の中から使うモデルを決定する。

  1. The model and the heart of the design shape each other.
    そのモデルは、設計の核心と相互に方向付けあっていること。
    It is the intimate link between the model and the implementation that makes the model relevant and ensures that the analysis that went into it applies to the final product, a running program.
    モデルと実装とのリンクが徹底されていることこそが、モデルを実用的な地に足のついたものにする。また、モデルに行われた分析を最終的なプロダクト、つまり動くプログラムに適用することを保証する。
    This binding of model and implementation also helps during maintenance and continuing development, because the code can be interpreted based on understanding the model.
    このようにモデルと実装が結びついていると、メンテナンスや継続的な開発においても役立つ。モデルの理解に基づいてコードを読むことができるからだ。

  2. The model is the backbone of a language used by all team members.
    そのモデルは、チームメンバー全員が使う言語の骨格となること。
    Because of the binding of model and implementation, developers can talk about the program in this language.
    モデルと実装とが結び付けられているおかげで、開発者がプログラムのことを話す際に、この言語を使える。
    They can communicate with domain experts without translation.
    開発者がドメインエキスパートとやり取りする際に、言葉を翻訳して伝える必要がない。
    And because the language is based on the model, our natural linguistic abilities can be turned to refining the model itself.
    言語がモデルに基づいているため、私たちが持つ自然言語能力を、モデルそのものの改善に役立てられる。

  3. The model is distilled knowledge.
    そのモデルは、知識を蒸留していること。
    The model is the team's agreed-upon way of structuring domain knowledge and distinguishing the elements of most interest.
    モデルは、ドメイン知識をどのように構造化するか、および、ドメイン知識の中で最も興味のある要素をどのように識別するかについての、チームの合意を表す。
    A model captures how we choose to think about the domain as we select terms, break down concepts, and relate them.
    私たちがドメイン知識のなかから用語を選び、概念を分解し、それらを結びつけていくにつれ、モデルは、ドメインについてどのような見方を選択したのかを捉えるようになる。
    The shared language allows developers and domain experts to collaborate effectively as they wrestle information into this form.
    開発者とドメインエキスパートが、ドメイン知識に取り組みモデルを形作っていくにつれ、共有された言語が生まれ、開発者とドメインエキスパートが効果的にコラボレーションできるようになる。
    The binding of model and implementation makes experience with early versions of the software applicable as feedback into the modeling process.
    モデルと実装とが結びついていると、ソフトウェアの初期バージョンの利用経験を、モデリングプロセスへのフィードバックとして使えるようになる。

 

PHPカンファレンス関西2018で「続・SOLIDの原則ってどんなふうに使うの? オープン・クローズドの原則 センパイのコーディングノート編」を話しました

7月14日に開催されたPHPカンファレンス関西2018で、『SOLIDの原則ってどんなふうに使うの? オープン・クローズドの原則 センパイのコーディングノート編』というトークをしました。

2018.kphpug.jp

今回のスライドは以下です。60分という長めのセッションでしたが、聞きにいらしてくれた皆様、ありがとうございました!

 

SOLIDの原則シリーズのトークはこれで完結

PHPerKaigiから3回にわたって、「SOLIDの原則ってどんなふうに使うの?」シリーズのトークをしてきました。私の中では、それぞれのトークのポイントは次のようになっています。

どの回も私にとってはチャレンジングな内容でした。PHPerKaigi版では、いかにオープン・クローズドの原則のポイントのようなところを、腑に落ちるように伝えられるかというところが難しく、最終的な形式になるまでにかなり苦労しました。なお、オープン・クローズドの原則を直球で説明している部分も、「アジャイルソフトウェア開発の奥義」に書かれていることをベースに、よりクリアにした私オリジナルの内容になっています。

PHPカンファレンス福岡版では、PHPerKaigi版の内容をブラッシュアップしつつ、伝えたい内容を追加してすこしフォーカスをずらしたので、話のまとめ方、そして時間配分に苦労しました。

最後のPHPカンファレンス関西版では、福岡とはまた違った内容をプラスしていて、この部分の話をちょうど良い感じにまとめるだけでもかなり苦労しました・・・。追加したい内容の部分がかなりのボリュームになってしまったので、削りつつ、ストーリーを変更するということの繰り返しですね。

そして今回の関西のトークで、オープン・クローズドの原則を軸にした一連のトークは、完結となりました。聞いていただいた方には、やや消化不良な箇所があったかと思いますが、それは今の所の私の力量不足です。スミマセン! この一連の話は私の持ちネタとして、少しずつ改良を重ねていく予定です。

裏話:掛け合い方式がなぜ生まれたか?

センパイとコウハイの掛け合い方式は、最初からそのように考えて作ったものではなく、偶然の産物としてできたものでした。私はソフトウェア開発者としてある程度の経験を持っており、そのような立場として設計などについて説明すると、どうしても説明を端折ったり、そんなこと知っていて当たり前、というような空気で前提を作ってしまうところがあります。そういう、言い方は良くないですが「上から目線的」な話がウケる場合もあることは確かですが、今回の一連のトークでは、それとは違うアプローチにしようと思っていました。それは、より多くの人にきちんと伝わるトークにする、というものです。そのために、話の細部に渡って、聞いている人が「なぜそうなるの?」とか「あれ? わからない」となって話についていけなくなる、という箇所がなくなるよういろいろ工夫しました。その工夫の中で、話す内容についていちいち自分で「なぜそう言えるのか?」「新人が聞いても分かるか?」「新人ならどう考えるか?」などと自問しながらストーリーを磨いていました。そんなことをしていると、ふと、「この質問自体を共有した方が伝わるんじゃないか?」と気づいたんです。

これを入れたのは、今の私のトークスキルとしては、成功だと思っています。

もっとうまいやり方はあると思いますし、話者が質問を最初からいれなくても、会場からのリアルタイムな質問を引き出せれば、もっと面白いですよね。そして、熟練した話者なら、そんなリアルタイムの質問にうまく答えつつ、それさえも自分の話の流れに組み込んでしまうものですよね。そんなふうになれるよう修行せねばと思います。 

今回のトークの反省

  • スクリーンの左側に立つパターンに慣れていなかった。マイクを左手で持って、右手でスライド操作&水を飲むという感じで、スクリーンの方を指す場合は右手を使うのだけど、方向が逆なのでちょっとやりづらかった。右手マイクでやれる方がよいのかもしれない(対策未定)。
  •  思っていたより、スライドの下の方まで見えるようにスクリーンが調整されていたので、スライドでは下いっぱいまで使った方がよかったかも。
  • スクリーン表示が予想よりちょっと小さく、クラス図やコードの文字は読みづらそうだった。このあたりは、コード量が多いプレゼンテーションの場合の正解が分からない。(話している部分を拡大というのを手軽に作れればよいのだけど。。。)

イベントについて

PHPカンファレンス福岡でも感じましたが、このPHPカンファレンス関西でもスポンサーさんがたくさん集まっているというのが本当にすごいなと思いました。また、参加者もたくさんいらっしゃって、カンファレンスがすごく盛況だなと感じました。

スポンサーブースを回ってカードを集めるという面白い企画も用意してあって、このカード集めの際に、自然とブースの方と話せるようになっていて、上手い企画だなとも思いました。

いろいろな工夫をしてカンファレンスを準備してくださったスタッフの方々、ありがとうございました!

次回は?

未定です!

東京で開催されるPHPカンファレンス(12月15日) か、何か他の小さなイベントなどでも、気分やネタの準備状況によっては参加するかもしれません。

参加するならやはり発表者として参加し続けたいので、次なる渾身のトークアイデアを練ろうかと思います。

phpcon.php.gr.jp

 

PHPカンファレンス福岡2018で「SOLIDの原則ってどんなふうに使うの? オープン・クローズドの原則編(拡大版)」を話しました

6月16日に開催されたPHPカンファレンス福岡2018で、『SOLIDの原則ってどんなふうに使うの? オープン・クローズドの原則編(拡大版)』というトークをしました。

phpcon.fukuoka.jp

 

スライドは以下です。スライドだけでも十分内容が伝わるように作っていますが、しゃべりでしか言っていないこともたくさんありますので、動画がアップロードされたらそちらを観ていただきたいです。

 

このトークにかける思い

私はプログラマになりたての頃から、ソフトウェアの設計が好きでした。これまで独学だったり師匠や先輩方からのご指導だったりで揉まれながら、さまざまなことを学んできました。そんな学びの結果、私に身についたといいますか、師匠や先輩方から授かったという方がよいのかもしれませんが、ソフトウェアやコードの設計に対する「目」というものがあります。この「目」は、ソフトウェアのソースコードを見た時に、その設計の具合を嗅ぎ取る目です。

自分のことを振り返ってみても、決して最初から意識してこのような目を手に入れることを目指した、ということはありません。さまざまなことをしてきた結果、そのようなものが身についているらしいということにやっと気づいたというのが正直なところなのです。

ですので、「この目を手に入れる方法」を自分ではっきり見いだせているわけじゃないんです。そのかわりに、「この目では、物事がどのように見えているのか」を伝えてみよう。それが、今年の一連の「SOLIDの原則ってどんなふうに使うの?」シリーズのトークにかける私の思いです。

この「私の目に見えている物事」は、言い換えると「コードの設計的側面の機微」というものかと思います。それはとても些細な違いだったり、僅かな兆候だったりするものなので、表現して人に伝えるには、緻密で正確な描写が必要になるものだと思っています。

しかし、このような描写は言うほどたやすいことではありません。また、そもそもこのような描写を行うためには、対象となる物事自体を相当緻密に観察し、かつ、理解し、自分のものとなっていなくてはいけません。このような点でいえば、今の私の観察、理解、表現はまだまだ発展途上です。今年の一連のトークを通して、より緻密に自分の「見え」を伝えられるよう、磨きをかけていきたいと思っています。

このようなトークで私に見えているものをお伝えすることで、「設計の面白さ」を一人でも多くの方に味わっていただけたらと思っています。

 

今回聞きにいらしてくれた皆様、どうもありがとうございました!

イベントについて

オープニングのスポンサー紹介を聞きながら、あらためてスポンサーがたくさん集まっているということに驚きました。スポンサーブースの数も多く、スポンサーブースの部屋に活気がありました。この部屋にAsk The Speakerのコーナーもあり、私もそこで質問に答えていましたが、部屋自体に活気があるからなのか、質問者の方と楽しい雰囲気で会話することができたように思います。このような場の空気が作れているのは、素晴らしいことだと思いました。

 

トークの反省

  • しゃべりはじめの頃、マイクの音量がつかめなかった。ボリュームが大きくてハウっていたようで、スタッフさんが途中で調整してくれたとのこと。最初の段階で自分から調整した方がよかったかも。
  • 前回のPHPerKaigiでは、水をこぼしてしまうという事件が発生したので、今回はコップに水を注いで飲むようにした。これは安心感があってよかった。 

次は

7月15日のPHPカンファレンス関西2018で、懲りずに同じテーマの『続・SOLIDの原則ってどんなふうに使うの? オープン・クローズドの原則〜センパイのコーディングノート編〜』というトークをします!

2018.kphpug.jp

今回とはまた少し違った設計の観点を攻めるトークです。

ぜひ聞きにいらしてください!

そして、よろしければご感想、ツッコミ、提案、批判、その他いろいろな声をお聞かせください!