今年設立40周年を迎える株式会社ポリゴン・ピクチュアズの代表取締役塩田周三が考える、“オモロい”ものを創造するための仕組み、場、組織づくりについてお話しします。

Shuzo Shiota, CEO of Polygon Pictures, Inc., which celebrates its 40th anniversary this year, will talk about how to create a system, a place, and an organization to create "omoroi" (fun) things.

The DevOps ハンドブックで示される3つの道、フローの原則、フィードバックの原則、そして継続的な学習と実験の原則。

ソフトウェア開発につきもののシステム障害。私達はそこから多くの事を学び、改善し、システムはより堅牢なものになっていきます。SREでもFour Keysでも、障害は発生しうるものとして扱われ、それをどのようにコントロールしていくかに主眼が置かれています。

その昔、私の現場では障害は「起こってはならないもの」として扱われていました。障害を発生させないことが目標として設定され、障害のような事象が起きているときにそれを障害として扱うべきか、という議論に時間が割かれることもありました。また、障害報告を上げると自分の責任になるのではないかという不安感から疑わしい事象を報告することについて心理的ハードルが存在していました。

2016年頃でしょうか。弊社がコミュニケーションツールとしてSlackを採用した頃から、その空気感は変わっていきました。#info_troubleという障害について報告されるチャンネルが開設され、「あってはならないもの」から「起こりうるもの」へと意識が変化していきました。

さらに時は流れ、「#info_troubleは障害について連絡する場だから、疑わしいレベルのものは投稿しづらい」という声があがるようになりました。そこで生まれたのが#info_trouble_lite。ちょっと挙動が変だよね、というレベルのものも共有されるようになり、「起こりうるもの」の規模が大きくなる前に対処できるようになってきました。

2021年。スクラムフェス大阪2021のセッション俺たちのDiRT - 継続的な訓練と振り返りで障害対応力をUPしように参加したメンバーがDiRTの実践を始めました。その取組は彼のチームの外側にも広がり、バックエンド開発チームを中心に実施されていきました。DiRTの結果をもとに障害発生時のオペレーションを改善したチームもあり、「起こりうるもの」は「起こる前に火を消すもの、起きたとしても素早く解決するもの」へと変わっていきました。

変更障害率0%よりも「継続的な学習と実験」を。10年前とはまるで違う価値観を有した組織へと転換していったのは、Slackのようなオープンコミュニケーションのツール、そのツールを中心に変化していった私達のマインドセット、外部からの学び、そして継続的な学習と実験が有用なものであるという実体験からくる気づきがあったからです。

このセッションでは、ある組織の価値観がDevOpsマインドに転換していった軌跡を時系列でたどっていきます。

東京都庁でのアジャイル推進の事例を紹介いたします。

現在、東京都はDXに全力で取り組んでいます。

業務改善・業務改革、より良い行政サービスを実現するためにアジャイル開発は不可欠なものと考え実践を重ねているところです。

本セッションでは東京都デジタルサービス局が中心となりアジャイル開発の事例やパターンをまとめた「都庁アジャイルプレイブック」を紹介します。

• 従来と異なる手法であるアジャイル開発の始めかた

• 事業部門と開発チームとのコラボレーションの工夫

• 進める中での課題・改善の事例

などなど、公共分野ではない方々にも参考にしていただける内容です。

本セッションでは、分散システムのような複雑な仕様や動作を持つプログラムに対して、その仕様を数学的記法により厳密に記述し解析する技術について紹介します。

システムやプログラムの仕様を表現するにあたって、「安全性 (safety)」と「活性 (liveness)」の二種類の仕様があることは古くから経験的に知られていました。非形式的な表現で述べるなら、安全性とは「何か悪いことが決して起こらない性質」であり、活性とは「何か良いことがいつかは起こる性質」であるといえます。

安全性と活性はそれぞれテストを行うために必要な操作が異なるため、与えられた仕様がこの両者のどちらなのか、あるいは混合しているなら分離して個別にテストすることが可能なのか、という問題が自然に生じます。この問題に対して、1985 年、Alpern と Schneider が位相空間論の言葉を用いた最初の定式化を与えて以来、さまざまな分析手法が用途に合わせて考案されています。

本セッションでは上記のような関連研究を通して、システムの仕様はどうしたら厳密に表現できるのか、また仕様を検証するにあたってどのように数学的な理論を適用するべきなのか、という問題意識について解説し、実際にそれらの理論が効果を上げているツールや事例について述べたいと思います。

みなさんはDevOpsDays Tokyoに来たぐらいですから、DevOpsに興味がある方たちだと思います。

CI/CDなど技術的プラクティスからDevOpsに興味を持たれた方、State of DevOps Reportや4 keysなどから興味を持たれた方、これから学びたい方、すでにある程度実践していて悩みを相談したい方、などなど、色んな興味があると思います。

そんなみなさんの興味を満たすために、DevOpsDays Tokyoで提供されるセッションを観ることももちろん有意義だと思います。

ただ、さらに学びを深めるためには、やはり、参加者同士の交流が必要ではないでしょうか？

せっかくDevOpsDays Tokyoに参加するぐらい熱量の高い方が集まっているのであれば、参加者同士懇親を深めてセッションについての感想戦をやったり、初学者に対するお勧めを聞いたり、自分の悩みを相談したりすることが出来たら楽しいのではないでしょうか。

とはいえ、少なくとも私は、知らない方に急に話しかけたり、話している輪の中に入ったりすることは、とても苦手です。

ネットワーキングパーティのような機会があったとしても、その時間を上手に使えずに話しかけられないことが多いです。

そこで、私のような人でも、知り合いを増やすことが出来るワークショップを行いたいと思います。

このワークショップは、Regional Scrum Gathering Tokyoで複数回開催して、毎回好評を頂いているものです。

このワークショップを通じて、知り合いが増え、より楽しむことが出来た、という感想を頂いています。

具体的な内容はOutlineに記載しますが、５～７人のグループに分かれて、『記者会見ワークショップ』を実施します。

このワークショップを通じて知り合いを増やすことで、より楽しいコミュニティ活動に繋がることを期待していています。

本セッションでは、DevOpsのプラクティスに焦点を当てることで、DevOpsを現場で実践する障壁を下げるとともに、それぞれの現場のコンテキストで得たいアウトカムに応じたDevOpsのプラクティスを実践できるようになることを目指します。

具体的には、以下のような観点でDevOpsのプラクティスを深堀りしていく予定です。

• DevOpsのプラクティスにはどのようなものがあるのか？
• DevOpsのプラクティスで実践難度が低いプラクティスはどのようなものか？
• DevOpsのプラクティスで実践難度が高いプラクティスはどのようなものか？
• DevOpsのプラクティスを実践するとどのような恩恵が得られるのか？
• DevOpsのプラクティスを実践するとどのような副作用が発生し得るのか？

なお、セッションで紹介するプラクティスには、自分自身が現場で実戦経験のあるプラクティスも多くありますが、今回のセッションでは自身の経験に基づいた回答ではなく、320本程度の論文/書籍の内容に基づいた知見を紹介しようと考えています。