YAPC::Japan::Online 2022 で登壇してきました
YAPCにスピーカーとして参加させていただきました。関係者の皆さまに改めてお礼申し上げます。
カンファレンスで初めて20分トークするのは大変緊張しましたが、ためになる感想を多数いただけましたので参加してよかったです。
印象深かったトーク・LT
5年にわたる"Perl の" REST API を "Perl で" GraphQL API 化し作り直す
私もRESTfulAPIを扱うチームにいるので興味深かったです。似たリソースが増えていき、冗長性を排除できず増えていくことのつらみに共感しました。いっぽうで、GraphQLを使うとリソース同士の結合度が上がりやすくなり、疎結合な実装にできないかもしれないなー。。なんて思いました。とはいえトレードオフだと思いますので、柔軟に書けることに魅力を感じました。PerlでGraphQLを実装した話は新鮮で楽しかったです。
CTOになりたいと思っていたけど今はそのときではないと気づいた件
まずスライドが見やすい。さすがariakiさんです。ariakiさんのコミュニティが主催する勉強会でLTの勉強をさせてもらったこともあり、「さすがだなぁ」と思いながら聞いてました。得意なことを全部やるのではなく自分が500%のパフォーマンスを出せるような状況を作り出すというのが刺さりました。得意分野を伸ばすには自分で頑張る以外にも、環境を整えたり味方を作ったり、いろんな方法を探す必要がありそうだと気づきました。強みというのは相対的なもので、周りの状況によって変わるんですね。1人で頑張るだけじゃなくて視野を広げる大切さを教えていただいた気がします。
YAPCらしさを感じる
アンカンファレンスから参加したのですが、顔見知りと会えたのも嬉しいですし、何よりトークが自由で面白かったです。テックカンファレンスは他にも参加しましたが、YAPCは器の広さ、つまりオープンな雰囲気が他のカンファレンスよりも大きいと思いました。内輪で盛り上がるだけのカンファレンスもたまにありますが、YAPCはそういうのがない。だから楽しいと思います。
私とYAPC
2014年が最初のYAPCです。
起業してから3年経ち、インフラエンジニアからWebアプリケーションエンジニアにジョブチェンジしたいと思っていた時期でした。『Webアプリエンジニア養成読本』を読んで興味を持ったのがYAPCとの出会いでした。
LTがとにかく楽しくて、ロックバンドのライブを観たような高揚感がありました。「LTってカッコいいな」と思うようになりました。
その後いくつかYAPCに参加しつつ、私生活では会社を畳んだり登壇しまくったりPerl入学式を手伝ったりキャリアカウンセリングやりまくったりしてまして、念願叶って今回YAPCで登壇できました。8年越しでオーディエンスからスピーカーになれました。やったね。
インフラエンジニアからWebアプリケーションエンジニアになれたのも、きっかけはPerlでありYAPCなんです。だからPerlには単なるプログラミング言語以上の思い入れがあります。
次のYAPCも参加したいですし、できる範囲で恩返しをしていきたいです。
トークで話せなかったこと
なぜフロー効率の高い企業がハイパフォーマーと言われるか
今回はフロー効率のお話をしましたが、そもそもなぜフロー効率が高い企業がハイパフォーマーと言われるのか疑問でした。調べたところ、パフォーマンスが良好な組織はそうでない組織と比較して以下のような違いがあるそうです。
・コードのデプロイ頻度は46倍
・コミットからデプロイまでのリードタイムは1/440
・平均復旧時間（稼働停止からの復旧に要する時間）は1/170
・変更失敗率は1/5
ではなぜデリバリーの速度が大事なのでしょう？さらに調べます。
同書から引用します。
日常業務をきちんとこなすだけではビジネスにおける競争力を維持できない時代になった。（中略）各組織はマーケットにおける競争力と優位性を維持するために、次のような面でさらなる加速化が求められる。
・顧客に満足感を与える製品やサービスの提供
・マーケットとのエンゲージメント（絆、つながり）の強化、顧客要求に対する感度向上、顧客理解の促進
・自社（自組織）に影響を与える可能性のある法的、倫理的規制強化に対する予測と対処
・セキュリティ上の脅威や経済情勢の変化など、潜在的リスクへの対応
上記のうち、大事だと思ったのはエンゲージメント強化、顧客要求への感度向上です。ソフトウェアが提供する価値観が多様化するにつれ、何が正解か分からなくなった。そのため「すばやく頻繁に価値を届ける」ことが重視されるようになったのではないかと考察しました。
言い換えると、ソフトウェア開発は「ユーザがどう使うか」を事前に予測することが困難であるがゆえに、ニーズに素早く応えられることそのものがソフトウェアの「価値」となるのだと思います。何を届けるかに腐心するよりも、すばやく届けること自体に価値があるということですね。ドミノピザは30分以内で届けることをサービスの売りにしましたが、それと同じようなものだと思います。
ユーザーのニーズにすばやく応えることがソフトウェアの価値、だからフロー効率が大事なんだと、調査結果から考察しました。
メインチームを支援するチームコミュニケーション設計
スライドでは、他のチームの助けを最小限におさえて設計からデプロイまで完遂できるチーム（メインチーム）を作りたいと書きました。メインチームという名前は『チームトポロジー』を参考にしたものです。同書ではストリームアラインドチームと呼ばれています。
私の構想には続きがあり、メインチームのフロー効率をさらに高めるために他のチームを作り、コミュニケーションスタイルを決めることを考えてました。
具体的には、まずメインチームをファシリテートするチームを作り、メインチームから出た課題を整理します。このチームはスキルレベルのかなり高いメンバーで構成し、メインチームのフロー効率を下げる技術的な要因を大きく2カテゴリに分けて分析してもらいます。
次に、分けたカテゴリごとに対応する別のチームを↓のようにつくります。
ビジネスドメインとは別の、専門的な技術に対応するチーム
検証環境、テスト環境など、開発に必要なプラットフォームを提供することに特化したチーム
チームを分けたら、チーム同士がどうやりとりするかを定義します。上記の2チームは、どちらも最終的にはメインチームに「サービス」を提供するものとして扱います。たとえば、電子署名技術をAPIとしてメインチームが使えるようにしたり、テスト環境の構築をPaaSとしてメインチームで作れるようにします。
コミュニケーションのスタイルは、『チームトポロジー』の下図を参考にし、コラボレーションから始めて徐々に疎なものに変えたいと思っています。
このようにして、メインチームは価値を届けることに集中させ、他のチームが適切に障害を取り除くことでフロー効率を向上させる狙いです。ここまで出来ればかなり嬉しいと思います。
我々のチームはWebAPIの開発・運用が主な役割なのですが、モノリスなのでAPIの変更しかしなくてもCIでテストを実行すると関係のない箇所まで自動テストが走ります。ファシリテートチームの協力で、このようなモノリスを適切に分割してCIコストの削減ができたら嬉しいですね。
フロー効率向上のためのロードマップ
継続的デリバリーの整備
チーム内のコラボレーションを促進
設計からデプロイまで完遂できるチームをつくる
チーム間のコミュニケーションを設計し、さらにボトルネックを取り除く
現段階では上記の順番で改善を進めると、スムーズにフロー効率を高めてゆけるのではないかと思っています。もっと良い方法もあると思います。
モブワークのつらみ
スライドではモブワークのメリットを語りましたが、うまくいかなかったことも沢山あったので共有します。
非同期コミュニケーションよりも気を遣うのがつらい
メンバーのタイムゾーンが違うとモブワークしづらい
朝型と夜型のメンバーが同じチームにいたので時間調整に苦労した
アメリカと日本のチームがモブワークするのは困難
意図的に休憩しないとダメ
モブワークだと休憩を入れるタイミングが見つけづらかった。ぶっ通しで6時間モブワークしてしまうこともあった。休憩を入れるタイミングもタイムボックスに含めないとダラダラ仕事してしまう
共通言語がないとつらい
スキルレベルが違いすぎると話が通じないので生産性が上がらない
人間関係が構築できてないとつらい
信頼関係のない状態でいきなりモブワークしてもうまくいかなかった
ウチのチームは結成して半年くらい経っていて信頼関係があったから成功した
初対面の人たちがいきなりモブワークするのはつらいので、以下の対策が必要
最初にやり方をきっちり決めておく
ファシリテーターを参加させる
教育目的でモブワークするとつらい
フロー効率を上げるためにモブワークするのがベター。モブワークのためのモブワークはあまり効果がなかった。チームビルディングの一環としてやるなら良いかもしれない
教育目的だと、目に見える成果がつねに出るとは限らないのでメンターが達成感を得にくい。コードをマージするなど、メンターとメンティーの双方が目に見えて達成感を得られる仕組みがなければ長続きしない
つねにモブワークするとつらい
1人で作業したいときもある。人間だもの
モブ：1人 = 4：6くらいがいい
仕事の裁量がなくなるとモチベーションが下がってしまうため、「困ったときに相談しやすいツール」としてモブワークを活用するぐらいの温度感でいい
おまけ
頭に猫を乗せて歩きながら登壇してたのでオーディエンスを混乱させてしまいました。すみません。。
猫はSnapCameraで乗せました
歩きながらだったのは、ステッパーに乗ってスタンディングデスクにPCを置いていたからです。
スタンディングデスクはガス圧式がおすすめです。
最初のうちは疲れますが、肩こりと腰痛がサッパリなくなりました。↓な感じですね。
この記事が気に入ったらサポートをしてみませんか？