過去２回のDevOpsDays Tokyoは、2017年1月末のシアトル訪問から始まりました。
Microsoftを訪問し、いくつかの多様性のある開発現場を見せていただき、英語での闊達な議論もしてきました。

今年のキーノートの Chap Alex さんもそこで出会った一人です。
彼はもともとテストの自動化の役職にいたわけではありません。
スカンクワークスで数年、チームになって３年くらい、今は30人のチームになったといっていました。

別のチームの人は、TFSというプロダクトを作っていましたが、
「ほら社内でこんなに使われるようになったんだよ」
と言っていました。計画経済のようにトップを説得して全体に使わせるなんてことはやっていませんでした。

さらに、そのチームは部屋を工夫し、チーム全員が一部屋に集まり、それでいてほかのチームとは共有しない部屋を作っていました。徐々にほかのプロダクトに広がっていると言っていました。

日本人エンジニアの河野通宗さんが言っていました。
「上司もエンジニアなので意思決定が速いです」
意思決定が速いと何がうれしいのですか？
「クラウドは常にどこかが壊れている。なのですぐに検知して直さなきゃいけない」

世の中がガラリと変わってしまう音が聞こえました。

もう開発者もデザイナーもマネジメントも経営陣も関係なく、リアルタイムに動き続ける世界を相手にして動かないといけない。途中の誰かがわからないから通訳してくれといえば、そこでリアルタイムから弾き出される。

テスト自動化だけ、チームビルディングだけ、上手なデリバリーだけ、得意ななにかをひたすら追いかけて、エンジニアのキャリアパスだけ考えて、残りはほかの人のせいにしておけばよい時代は終わってしまった。全体としていい仕組みを作った企業が生き残る。誰も安住できないグローバル競争をしたたかに生き残って時価総額を伸ばし続けるエンタープライズがシアトルに一つありました。競争している企業もいくつもあります。

私たちの DevOpsDays Tokyo そこから始まりました。

それから一年ちょっとがたちました。

世の中の何が変わったのか、そして、心境はどう変わったのか、ここからどうなっていくのか。

話し合ってみたいと思います。

「人は、学び続ける動物である。なぜそういえるかというと、人が問題を解いていたり、新しい問題の解を見極めたりする時どういうことが起きているかを詳細に観察してみると、人は、何かが少し分かってくると、その先にさらに知りたいこと、調べたいことが出てくることが多いからだ。人はなにも知らないから学ぶのではなく、何かが分かり始めてきたからこそ学ぶ、ともいえる。」(三宅芳雄・三宅なほみ 教育心理学概論 第一章 P.13-14)

多くの人がスクラムを利用して開発するものは、たぶんなんらかのソフトウェアサービスで、その先には利用者がいると思います。アジャイル開発やDevOpsでどれだけ技術的に研ぎ澄まし、円滑にリリースができるようになったとして、ターゲットとしている利用者像が間違っていれば、成果に繋がらず、投資や予算が尽きた時点で終わりです。

過去のソフトウェア開発は、作ってすぐには顧客に届けることなんてできない前提で作られてきました。そのために、じっくりとテストを重ね、ビジネスインパクトを計算し、エンドユーザーに届くときには「絶対に使い物になる」ものを作ろうとしました。しかし現代、作ってすぐユーザーに届けることは当然の事になりました。そのために、テストの自動化、クラウド、DevOps、A/Bテスト、カナリアリリース、マイクロサービスなどのプラクティスが普及してきたのです。

プロダクトオーナーシップは汎用化が非常に難しい分野です。うまくいく方法は一つではないし、売れるということはすなわちユニークな優位性があるということであり、すなわちコピーできない。できたら簡単に優位性は失われるからです。しかし、その考え方まで理解を深めれば、取り入れられる部分が出てきます。

本セッションでは、大手企業の中で、新規の事業開発を手がけられてきたパネリストの皆さんが、どのように予算をとり、新しいエンドユーザーの仮説を検証し、マーケットにアプローチして、小さな成功を掴み取ってきたか、話し合ってみたいと思います。

パネリスト
　山崎 篤 氏 (コクヨ株式会社)
　黒田 樹 氏 (リクルートテクノロジーズ)
　太田 敦士 氏 (NTT西日本)

本セッションプロポーザルに対してコメントにて質問をいただければ検討いたします。

DevOps(継続的デリバリー)によって、プロダクト開発は、より短いピッチで仮説検証することが可能になりました。仮説を効率的に実装につなげ、素早くデリバリーして、部分リリースでメトリクスをとって検証する。リーンスタートアップが、大企業でも積極的に採用されるようになった、ともいえます。こうした時代に、プロダクトマネージャーに求められるスピード感や役割そのものが変化しています。おそらく正解もないので、パネルディスカッションを用意することにしました。ぜひ皆さんで議論しましょう。

本セッションでは、「めんどうくさいので、やめてみた」についてみなさんの経験を共有していただき、参加者のみなさんが、もっと「めんどうくさい」を発見できる方法について考えます。そして、時間があれば、なにかを始めたり作ったりする際に、めんどうくさくてもやらなければならないことのリストを作ってみましょう。めんどうくさいけど、練習は大事です。

実は、本セッション自体がめんどうくさいのですが、なんとなく必要そうだなと思いまして、まあ、やってみないと価値があるかどうかもわからないので、プロポーザルとして置いておきます。あわせて、代わりにやっていただける方も募集いたします。