PHPカンファレンス福岡2023に参加しました & 登壇しました #phpconfuk / @自分の登壇まわり

やったこと・書いたもの イベント

6月24日に開催された、PHPカンファレンス福岡2023に参加しました

phpcon.fukuoka.jp

ここ最近は、カンファレンスに参加する度(たび)に段々と楽しんだ度(ど)が増してるな〜〜という気持ちがあるのですが、 今回もまた、それはもう楽しかったです。

参加した感想やセッションを聴いての感想などは、別途で記事を書きたいと思いますので、ここでは自分の発表内容についての諸々を残しておきたいと思います。

発表したもの

fortee.jp

所感など

「結局、何の話だったのですか？」というと、 「ソフトウェア/ソフトウェアアーキテクチャを設計していく際の勘所」でもなく「オブジェクト指向の原則」でもなく「プロジェクト管理のコツ」みたいな話でもなかったし、総じて「上手くやるには？」というよりも「(タイトルの通り)何かしら関係や、影響があるのではないかなーって思うんだけど」というものでした。 と、個人的には考えています。

おおよそ、リーンやXPの話をちゃんと読めば、全部書いてあるな・・・・という気はしつつ、より深ぼってみるとしたら、「オブジェクト指向」の話でも「アジャイルソフトウェア開発」の話でもなく、関数型だろうと”ウォーターフォール”だろうと活きる話なのではと思う所。*1

言いたかった(かも？)こと: コレは「依存性の逆転」なのではないか

今まで自分が思い浮かべてきた感覚について、資料を作りながら言語化が進んだものがあり、 それは ソフトウェア設計とプロジェクト管理の依存性逆転 というキーワードで言い表せるのでは？というものです。 (残念ながら、表現が「デカすぎる」感があり、今の言語化レベルで外に出すのを躊躇った*2次第です)

「プロジェクト」と「ソフトウェア」だと、前者のほうが抽象ですよね。
ただ、実際に開発プロジェクトを考えると・・・・例えば「タスクAをやってからでないと、Bが進まない」みたいな硬直が発生して、つまりソレってソフトウェア的な都合なのですけど、そうやって「下流・詳細」の影響が「上流」に流れ込んできていますよね。
リアルワールドへのアウトプットを考えると、詳細な部分までしっかり組み込んで初めて「実体化」できるので、これは自然なことではあります。しかし、リアルワールド =「物体」の世界に近づけると、「ハード」になっていくことが事実です。
ソフトウェア本来の、概念的な世界に事物の制御権を取り戻す = 「支配をソフトにする」ためには、依存性を逆転していくことになります*3。
つまり、「プロジェクトの都合だけを考えて、タスクの組み立て方 = ソフトウェア開発の実行順を支配したい」という願望を実現するための、依存性の逆転です。
「先に作らないと動かないから先にやる」ではなく、「仮説の検証を進めたりフィードバックを早め・深めに欲しいから作り込む」という判断で動きたいな、が出来ることが理想だよなという話です。

クリーン(な)アーキテクチャの世界では、インターフェイスを用いて逆転を手に入れますが、プロジェクト⇔ソフトウェアの世界においても「抽象化」を用いることになるのかと思います。
そうやって「ソフトにしていく」ことが可能なのでは？というのが、今回の発表の主題であります(と考えています)

皆さんのリアクションを見たり現地で話をしたりして、改めて思うのは、今回の発表は「それが出来たら苦労がしないよ」「現実問題、どうやるの？」という問題をクリアするような内容にはなってないよな(目指していない)、ということでした。
「抽象化を上手くやれば勝ち目が上がる」と言われても、「独立して進められる作業が用意できれば勝ち目が上がる」と言われても、実現するのは難しいのですよね。
そういう意味では、絵空事ばかりではあるのですが、提供したかった価値としては「ソフトウェア設計とプロジェクトの管理の関連性を意識することで、設計についての見え方が変わる・認識している重要性が昨日より高くなる」といったところでしょうか。

「設計があれば便利でしょ？」「どういう設計があれば、どう便利なの？」を話すセッションであり、「設計ってどうやるの」は本筋ではなさそうだな、と考えています。

余談: 制作の裏

  • miro便利
    • アウトラインを作ったり組み直したり、スクラップ帳を作るの最高に良いです。その他のツールなども併用しているので、必ずしもmiro単独で完結させようという意志は自分的には持っていませんでしたが、思考をフローにしたままdumpできるのはツールの力。
  • 録画素振り便利
    • これは前回か前々回くらいの登壇準備から取り入れているのですが、発表資料&話す内容がβ版くらいまで進捗したら「Zoomで画面共有してプレゼンしながら録画する、見直す」というのが便利だな〜と思っています*4
      • ZoomじゃなくてQuickTimeとかでも良いでしょうね！
    • 口頭で喋る(/端折る)内容とスライドに記載した内容をバランス取ったりするのに使うのはもちろん
    • 改めて見てみて、言葉がうまく出てきていなかったり説明が”スピン”しているところを確認して、トークスクリプトを厚めにする〜というのももちろん
    • 作業中や移動中にBGM代わりに垂れ流して、睡眠学習的に「発表内容を身に染み込ませる、馴染ませる」とか「繰り返し同じ内容を聞くと、肝となる部分が浮き上がって見えてくる」といった使い方もしてました
  • 壁打ちありがたい
    • 発表練習しようぜ！！みたいなのも非常に効果あるんですが、そこまでの完成度を待たずに、誰かを巻き込んで「どこまでいきました？」「アウトラインまではできたつもりです！」「へぇ〜、どんな内容なんですか？？」ってやりとりしたりとか、「コアになるメッセージコレかなって考えてます〜」って説明したりとか、やっぱり思考が洗練されたり焦点が合いやすいなと、改めて感じました
    • 特に今回は「どこまでの深さ、広さで話そう」というのが定まるまでに苦労していたので、人に聞いてもらってシンプルに出来たなーという感謝があります

リアクションを

Twitterで感想や考えの共有をいただけましたので、「ここは自分も補足をしたいな」と思ったツイートを拾ってIMOないし発表内容のフォローをしていきたいと思います。

懇親会でも直接話しましたが、アジャイルソフトウェア開発宣言は非常に洗練された内容だなぁ・・と、やはり思う所。
今回の話はテクニカルな面で言えば「アジャイルソフトウェア開発の奥義」で全部説明しています、というところでもあるので、アジリティは念頭に置いています。PMBOKの言葉を使うと、「適応力・回復力」の獲得であり、それを設計の力でサポートしたいね〜みたいな内容だ、と要約できる気がします。

「いい感じに分割すると、例えばGitでコンフリクトとか起きにくくなるはず」という話をしました。
やや極端な例だなぁとは思いますが、実際に「PR作ったけどコンフリクトしたので、解消しています・・・」という困った顔をした人々をたくさん見かけて・・・・・

例えば「寿命が長いブランチ」「変更範囲が大きいブランチ」などが、コンフリクトしがちですよね。
これは根本的には(ブランチ戦略云々というのはさておき)、「変更理由(≒バックログ)がデカすぎるから」という所が大きそうなので、そちらを解決したい気はします。
その上で、「タスクをスライスしてもコンフリクトする」だと、変更すべき事情が集中しているのかなーと感じます。

やや蛇足ですが、アーキテクチャ系のメトリクスとしてGItでのアクティビティから面白い情報が取れるよなーとも最近思うことが多く、churn-phpなどは遊んでみたいツールです。

github.com

この観点から、「コミットが頻繁に行われているファイル、コミットしている人数(もっというと、チーム数とか)が多いファイル」などは何らかのシグナルを発しているのかもな？とも思います。
「1週間に4人が変更しているファイル」、とかメッチャ不吉な臭いしませんか！

「分割・局所化によって、並行作業が可能になる」みたいな話ですね。
人月の神話では「コミュニケーションが必要なので、人員追加に比例してパフォーマンスが上がらない、まして相互的なコミュニケーションが求められる場合においては逆に悪化さえする」という話が触れられています。新規メンバーの教育・キャッチアップコスト、なども含まれます。
それに対して、「疎結合になっており、相互に影響しない独立したモジュール同士」であれば、全く別々の人を同時に別のタスクにアサインする！が可能になりそうだよね、という話をしました。

加えて、リソース活用の柔軟性という意味では、「タスクの着手順番やタイミングをいじりやすくなっている」ということも重要だと考えています。

参考書籍として挙げている「クリティカルチェーン」や、同じくゴールドラット博士の「ザ・ゴール」において「ボトルネックは移動する」という考え方が強調されています。
このボトルネック、例えば「いい感じにDBスキーマを考えられる技量を持つ佐藤さん」がいたとして、複数PJから引っ張りだこである場合、「佐藤さんが他のところで忙しいから、タスクXYZが進められない」といった人的・ナレッジ面でのボトルネックも対処しないと行けないわけです。
そうした時に、「DB周りの詳細は後でやれば大丈夫だよ」とできれば、佐藤さんが合流できる予定日までにまだ1週間あったとしても、タスクXYZにロックされずに他の開発者のリソースが生きるようになります。

発表中で「上からやるか下からやるか」という話をしました。
コレは完全にお2人に同意で、抽象化や要求に対しては「上手く揺さぶりをかけていく、そのために必要なモーションを掛ける」ことが重要だなと思います。
やりたいことは「手戻りを含めムダを減らしたい」であり、そのために必要なのは「意思決定を間違えない」ことです(決定を遅らせる、というのはそのための方法)。なので、「確証を持てるならすぐに踏み込んで問題ない」が最初にあり、それが無いなら「早く確証を得たいところへ早く揺さぶりを掛ける」のが次善です。

「プロセスやツールよりも個人と対話を」と同様に、「どっちからやるか？というこだわりを捨てる、ソフトウェアの状況と対話をする」で進めていきたいなーと思います。
(もっと平たく言えば、「気になりが強いところから手探る」という感じ)

ライティングソフトウェアの「マネージャー」レイヤーの話が、個人的には好きです。
あとは、自分の場合は、「抽象的に、命令だけする」役割と「ロジックやアルゴリズムを定義する」役割をしっかり分離したい、というのが1つの目安になるかな〜という説明を用いることが最近は多いかな、と思いました。

・・・今回の発表は「サービスクラス」「ユースケース層」みたいなのを挟んでいないので、最近の開発をしている業務環境では、もっと複雑な悩みになりそうですが・・・という風には思っていますw

「変動性を見抜きましょう、それができれば良いのです！」という発表をした身ではありますが、「変動性や抽象の設計を見抜くのが難しいよね」というのは正に問題であり、コレは檻の中に入った鍵みたいな話だなぁ・・と思います。
頑張って色々な設計を触ってみて、自分なりに感覚を研ぎ澄ませていくのが王道(険しいけど)！！って所なんですかねぇ頑張るしか無い。頑張る人しか頑張らない権利は手に入らないので・・・

ソフトウェアデザインを切り刻むためのスイスアーミーナイフが欲しい。

難しいことをおすすめする話で、難しいことをどうやるか・どうしたら出来るか？という話ではないなーと、こういうリアクションを眺めながらフフフってなってましたw

「実物として、自分の目で確認できるもの・物理法則に支配されるもの」と「頭の中に生まれて、縛るものがないもの」との違いですね。
確固たるWhyがあると良い！！！というのは間違いないですが、その一方で、Why=解決したい問題=Visionが確率されればされるほど、「より良い姿を求める」という力も働くため、要求v1→v2→v3と進化を催す性質は色濃くなるのかな、とも思いました。
「曖昧ではないが不確実」な要求、みたいな世界観があるのもしれません。

まとめと諸々

改めて、聴きに来てくださった方や、資料を読んでくれた皆さんに、感謝申し上げます。

資料を作ったり、そのために本を読んだり読み直している中で、自分自身とても勉強になった発表でした。
発表時に端折った部分も少なくないですし、もし資料作成中に収束を意識しないで「完成版」を作ったらボリュームどんだけになるんだ・・・と独りで笑ったりしていましたw

まだまだ思考や知識のアップデートや言語化を進めていく必要があるだろうな〜と思うトピックですので、また色々な反応を聞けると嬉しいです！

*1:実際、発表中で引用した重要参考資料である書籍「ライティングソフトウェア」は「分析」「設計」フェーズをしっかりと事前に取っていますし、アーキテクトやデザイナのロールが存在することを前提としている内容になっています

*2:不安なものや機微なニュアンスの蒸留が足りない感覚・概念を持ち出すと、補足的な説明が多くなり、すると長くなった説明により発表時間が足りなくなり・・・という恐れ

*3:字面的には制御の逆転の方がハマりそうだけど・・どっちが適切ですかね

*4:コレが出来ているのは、事前録画式のカンファレンスや、会場登壇の発表でもオンライン配信されたり・・・で、自分の声を聞く苦しみが薄れてきたのが大きい