🌲 Developers Summit 2022 Winter

2/17-18 は デブサミ2022でした。全90セッション!残念ながら参加できていないのですが、いくつもの資料が公開されていますので、ピックアップしてご紹介したいと思います。

資料はここでまとまっていました。

エンジニア組織

10年後もエンジニアが成長し続けるためにできることを、20年続く組織の中から考える

たどってきている道が似ていて、だからこそ勇気も持てるよい話でした。いきいきできる組織を。

魅力品質は当たり前品質になっていく

同じ前提の中で改善を重ねるだけでは適応できない環境の変化がある

勝ちパターンのアンラーニングが必要

中長期は構造的な / 現場は偶発的なものへの対応に長けている

変化を支える仕組みは現場からボトムアップ

ボトムアップは組織をまだらに変えていく

現状維持バイアスとたたかう、変化のためにOKRを

無理やり動かすんじゃない。自ら動いてもらうんだ

Ready Player One? ― 『ユニコーン企業のひみつ』に学べること

去年話題になった書籍「ユニコーン企業のひみつ」より、「Ready Player One」= 「自分たちから始めるしかない」と説いています 。「Lean と DevOps の科学」でも組織文化が組織のパフォーマンスを左右することを説明していました。さらに「(文化形成などは)ボトムアップでの取り組みが成功の要因」「チームから始める、チームから広げる」「すごいプロダクトはボトムアップでしかつくれない」「何をしたらいいのか? = まずは継続的デリバリー」「開発者がプロセスをコントロールする」と、エンジニアとエンジニアリングの影響力ってすごい、だからこそ自分たちから動き出す、という話をしてます。特に、「すごい仕事をしていない「言い訳」は何?」という問いかけが。なんだろう。

生き生きとした組織への道

kyon-mmさんのパタンランゲージと組織論。難しい。私にはもうちょっと先か。あと、いきいきって、アジャイル界隈のキラーフレーズなんだろうか。

プロダクト開発速度とデータの組織的価値をセットで飛躍的に高める開発戦略

EdTech の atamaplus 。データを用いて次の戦略を決めていこうとしたら、収集したデータそのものが価値のベースになった、という話。任意時点でのユーザ状態の再現技術の誕生(データをすべてのこしているため、ソフトウェアの操作過程のどこにでも戻れる技術)、すごい。

2022年からCTO交代!新旧CTOが語るこれまでの10年とこれからのエンジニア組織と文化

Voyage あらためCARTA グループ ( EC ナビの会社です)のCTO 交代。小賀さんは10年か。今のCTO は 32歳。ちなみに CARTAグループは企業規模なんかが当社と似ているんですよね...

エンジニアの生き方

GitLab社で学んだ最高の働き方

「世界最大のAll-remote企業」のプラクティスはどれもこれも参考になります。目的がある同期コミュニケーション(会議)に関しては徹底的に無駄を省くルールが定められていて、一見の価値あり。同期コミュニケーションを円滑に進めるための 「Cofee chat」(雑談)が制度として確立しています。Hybrid 通話 ( = 複数のメンバーがWebミーティング設備(画面、ヘッドセット、カメラ)を会議室などで共有している状態での通話 )は最悪、というのは同意する人も多いのでは。

開発プロセス

今、テストに興味があるのかもしれない。

開発者・経営者へ特に伝えたいAgile Testingのエッセンス

よい話だった。特に「実例マッピング」は実際にやってみたいし、Agile testing condensed もよんでみたい。

オーバーエンジニアリングって何!?ぶくぶく膨れ上がる仕様、使われない機能、過剰品質、、、突き詰めたら、その先に真のチームの姿があった。


やりたいことがあるし、エンジニアも足りないなか、どうしたら素早く価値を届けるか、っていったら、「余計なことやってる時間なんて俺らにはない」わけです。この記事、どこかでばずってましたよね。アンチパターンとしての「ベローンの美学」。本当に自戒です。

アジャイル開発と品質エンジニアリング - QA時代の終わりとQE時代のはじまり

mabl という自動テストツール会社のセッション。現代のソフトウェア開発では最後だけ実施する「QA」ではなく、開発の全てのプロセスに「品質向上」をエンジニアリングで埋め込むことが必要と説明している。「 根強いQAがボトルネック問題」「開発サイクル全体で品質を維持」という話から、「しっかりしたテストのプラクティスがあれば変化はおそるるに足らない」「テストでスピードを上げる」と言い切っているところが心地よい。

デジタルトランスフォーメーション・ジャーニー ~組織のデジタル化から、分断を乗り越えて組織変革にたどりつくまで~

papanda さんのDX セッション。DX 4つの段階設計( 1. 業務のデジタル化、2. スキルのトランスフォーメーション、3. ビジネスのトランフォーメーション、4. 組織のトランスフォーメーション)でいったら、私たちは 2と3の間かな、と感じました。

SBOMでソフトウェアを守れ!10年後も自信を持ってリリースするために今始めるDevSecOps

JFrog によるDevSecOps (ツールの紹介込み)の話。若干ポジショントークはありますが、Software Bill of Materials と SCA は検討の余地あります。あとここ。

まずは丸投げしない。理解する。/ すこしずつお互い手を広げる

「アジャイルマニフェスト ディケイド」Resurrections

角谷さんがアジャイルマニフェストの10年を振り返って話をしました。アジャイル仮面ライダーディケイドとかに例えてて、個人的に懐かしかったです。 心に残ったフレーズ。

コードはドキュメント。 あなたは毎日小さな奇跡を起こしながら仕事をすすめていくというわけです。

「界隈がざわつくほど超進化したPMBOK第7版」に私たちはどう取り組むか

プロジェクトマネジメントを体系的にまとめたPMBOK。第7版ではいままでと大きく異なり、計画通り管理するプロジェクトから環境の変化に適応しながら価値を提供する「適応型PM」の体系へ。方法でなく「プリンシパル」をベースにまとめられているため、自分で手順を発明しなくてはいけないのは、個々人の基礎のビジネス能力が試されるものに。がんばろう。

プロダクト開発

開発者視点のBtoBプロダクトマネジメント実践論 ~エンジニアが高い顧客解像度を持つ事で高まる機能開発のROI~

flyle はプロダクトマネジメントSaaS 。以前、UZABASE と及川さんのパネルディスカッションに参加したことがあり、とても示唆に富んだ内容でした。今回も失敗談交えて「顧客の声をどうプロダクトにとりくむのか」話していてとてもよい内容でした。

開発チームみんなで取り組むアクセシビリティ

freee さんによるアクセシビリティの話。仕組み化と教育とビジョン、全てを整備し形骸化を防ぐところは、当社のチームにセキュリティなどを実装するときにとりいれたい。あと、デザインシステムがこれくらいワークするようになるとうれしいなあ....

Mackerelのプロダクト開発 ~ エンジニア中心の開発プロセスで大切にしていること ~

サーバ監視ツールのMackerel の話。基本的にお客様がエンジニア、エンジニアのためにエンジニアが作る製品なので要件定義もドッグフーディングで楽なのかと思いきや、やはり同じところでつまづいてしまうよね、という話。製品なにつくるか、つくらないかは、難しい。

データテクノロジー

今まで生き残ってきたRDBMSとこの先10年戦えるデータストア戦略

soudaiさん。この1-2年、当社のインフラ改善でDBもリプレースしたのですが、そこで得た知見、取り組んできたことに近いです。印象的だったのは以下のフレーズ。未来を想像しよう。

データベースの寿命はアプリケーションよりも長い

今と過去の差分を見ると未来が想像できる

マイクロサービスとデータとData Mesh - アプリは分けた。データはどうだ。

マイクロソフトさんの発表。次の10年は ストックなデータから Kafka のようなフローなデータへのパラダイムシフトになる、というか時代はそうなっているはずと思っています。ただ、当社はまだそこまで追いきれていない(製品に反映できていない)ので、CDC とかデータ指向とかチャレンジしないとなあ、とおもった話です。といいつつ、まだよめていないです。資料が綺麗なので保存。

インフラ

CloudNativeな時代に求められるWebサービス基盤モデルの再考 - Daprについての考察と実装

まずは、SRE の話など。当社のインフラをSREにもっていくかは悩ましい、というか、インフラを持っている

SLO はサービスごとに設定する

コンテナの歴史とメリットについてよい読み物... に見えるのは私に知識があるからか?感想求む。SLI にレイテンシを加えてもよいかも。配信遅延を監視しているのと同じように。対して、Dapr はノータッチだった。勉強したい。

Developers Boost

若手デベロッパーのカンファレンス「Developers Boost」のベストスピーカーの話

成長の秘訣はスクラム?楽しく学ぶOJTの作り方 - デブサミ2022 - / Is Scrum the secret to growth? How to make OJT to learn enjoy. - Developers Summit 2022

OJT フレームの作り方。山本五十六メソッド最強。だけど、教育のプロセスやスタンスを丁寧に分解して解説していて、繰り返し読みたい内容。「何回でも聞いていいよ」は魔法の言葉ですね。

事業をスケールさせるエンジニアたち〜技術のコモディティ化にエンジニアは敗北する〜 / Connecting Business and Engineering

元DMM 現LayerX 松本さんの血を受け継ぐ、DMMのプロダクトマネージャーによるつよいエンジニアの成長理論。開発ではなく、事業のグロースに貢献できるエンジニアが生き残ると説いた上で、そのエンジニアの特徴は「構造を捉える」「KPIで事業を語る」「仮説と実験で、転がしていく」「BMLループで学習サイクルを構築する」「チームの戦闘力もデータ化する」という点であるといっています。それだけできたら....技術のコモディティ化には巻き込まれないだろうけど...的な。

制約が多い大きなプロダクトに新卒で飛び込み、バリバリ案件開発に貢献するようになるまでの道のり。 / DevBoost2021_YusukeKawauchi

できあがったプロダクトの開発に携わることになり、わからないことだらけのエンジニアがどういうふうにひとつひとつ疑問を解決していったか、という話。きっちり課題を構造化した上で、自分の能力開発のステップを立て実行していってすごすぎる。世の中賢い人がいるんだなあと感じましたが、これを新人に任せてはいけませんね。

外の知見を取り入れる

改めて、自分たちが抱えている課題は決して人類未到の特殊なものではなく、ほかの企業さんも知恵を絞って日々立ち向かっているんだ、と感じました。ただ、共通するのは、いろいろ小さく試して学んでいくしかないということ。小さく試すのもスキルがいるのでこのあたりはもっと磨いていかないと。とはいうものの、ここ数年取り組んできたこと、そこから得たものは、正しかったんじゃないかなあ、とも感じました。  こういう知見を共有してもらえるのはすばらしいですね。ありがとうございました。