ぼくの Developers Summit 2020 1にちめの感想文

デブサミ2020 1日目の感想文です

Developers Summit 2020が開催されました。
私もかれこれ3回目の参加となります。
本当は2日目も行きたかったのですが、諸事情により1日目のみの参加となりました。

本記事では、私が聞いた講演の感想についてのメモ書き＋講演ごとの全体的な感想を記載させていただきます。
すでに資料公開されているものについてはリンクも記載しておきました。
後ほど公開されたら追記します。

UXデザインが大事なのはわかるけどエンジニアの私ができることってなんでしょう？

登壇者

• 安藤昌也さん
• UXで博士号を初めて取ったつよつよ教授
• UXデザインの教科書著者

話の導入

• e-learningを導入するにあたって最大の障害があったがそれは？
  • 会社内でイヤホンが使えないこと
  • ユーザの体験は環境に作用されるということ
• UXはなんのために必要か
• エンジニアはそれに対して何ができるか

講演の趣旨

• UXとUXDは違う
• UXD＝ユーザーがうれしいと感じる体験となるように製品やサービスを企画の段階から理想のユーザー体験(UX)を目標としてデザインしていく取り組み方と方法論
• 体験を捉えるレンズ＝抽象度
  • いろいろなレベルの抽象度で体験を捉えることができるようになろう
• 理想の体験という仮説とそれへの検証
  • どのレベルの体験度をエンジニアは理解すべきか

体験こそ商品

• 事例１：カメラ -> シャッターを押すことのみに専念させるという体験
• 事例２：iPod -> ポケットに千曲持ち運べるという体験
• 事例３：スタバ -> 照明、商品、接客すべてがスタバでしか体験できないものにするというコンセプト
• 総合的な体験を通して顧客が得る価値こそ商品

消費者は体験を買っている

• 事例：バルミューダのオーブントースター、炊飯器
  • お高めの製品
  • だけどうまそうに見える
  • HPでは技術よりもうまそうさを伝えるように工夫している

UXとは何か

• 利用文脈の中で利用する際に、ユーザーの中に生じるもの
• UXとユーザビリティは違う
  • UXはユーザ側のプロパティ
  • ユーザビリティは製品品質なのでプロダクト側のプロパティ
• ユーザの主観をいかに扱うか、操作するか
• UXの期間モデル
  • 予期的UX -> 広告とか
  • 瞬間的UX -> スマホ使っているとき、インタラクション、エピソードに包括される
  • エピソード的UX -> タスク、目的からその達成まで
  • 累積的UX -> 体験全体の価値
  • お化け屋敷がいい例
  • 入り口と出口が一緒 -> 予期的UX。待っている間に出口から驚いて出てくる人を見てなにがおこるのか想像する
  • 中で驚かされる -> 瞬間的UX。驚く、恐怖するというネガティブな体験
  • 終わったあとに入った人たちと会話 -> エピソード的UX、瞬間的にネガティブであっても、それがエピソードに昇華されることでポジティブに変わる
  • 古いUXはこれらのUXが縦割りになっている
  • 予期的UX -> 累積的UXの順に抽象度があがる
  • UXDは４つのモデルをいったりきたりしながらデザインすること。どれか１つが一番重要といったものではない。

UXDとはなにか

• Webはサービスを提供し続けるからわかりやすい
  • 製品となるとなかなか難しい。
• サービスの事例の紹介
  • 事例：JapanTaxi
    • 最初はユーザビリティを重視していたが、全国で使用できるという体験を重視するように推しポイントを転換させた
    • HPでは、４箇所の浜、海辺の背景＋アプリを使うという広告をしている
      • なぜ浜、海辺の背景なのか？
        • 浜には目印になるものがなにもない
        • けどこのアプリを使えばいつでも呼べる
        • ありがたいと感じられる
        • 東京でも使えるものがこんなところでも使えるなんてありがたいなぁというUX
• 事例：MOV
  • 乗りたいときにタクシーに乗れない。そんなタクシーライフを変えよう。
  • リアルタイムマッチングでタクシーがすぐに来るよっていう売り
• 事例：S.RIDE
  • ワンアクションですぐタクシー呼べるよ。
  • 精算もクレカ登録しておけばめっちゃ楽だよっていう売り
• 以上3つの事例を見ると、体験全体はどれも同じだが、力点が違う
  • JapanTaxiは累積的UXに力点を置いている
    • 普段東京で使えるものが全国どこでも使えるという全体的な体験
  • MOVはエピソード的UX
    • 乗れない->乗れるという目的の達成焦点を当てている
  • S.RIDEは瞬間的UX
    • ワンアクションという、そのアクションの瞬間に重きを置いている

UXDのコンセプト

• 体験の仮説を意識した実装
• 具体的アイデアや体験はすべて仮説にすぎない
• だれでもUXDはするべき、わかっているべき
  • ユーザの体験は仮説、それを技術で実装していくのがエンジニアの仕事
  • 顧客との会話においても、いろいろなレベルで体験を捉えることができればコミュニケーショの不和が減る

私的感想＋まとめ

講演について

まさしく大学教授の講演といった感じでした。しかもいい意味で、です。複数の事例を使ってUXDがどういうもので、どういうことに注目したらよいかということが非常にわかりやすかったです。
アカデミックさもありつつ、講演を聞く人たち（＝エンジニア）向けに内容を洗練させているように感じられました。めちゃ面白かったです。

内容について

「今では会社でイヤホンつけて音楽聴きながら仕事するなんて当たり前のことですよね？」-> ま？カルチャーショック受けちゃいましたよ…

それはさておき、私は業務アプリの開発しかやったことがなかったので、UXっていったらせいぜいユーザビリティぐらいしか考えたことがありませんでした。
そういう意味では初見の知識が多く、新鮮な気持ちで聞くことができました。
「誰しもが何らかのユーザー」なのだから、誰でもユーザー体験を考えるチャンスはあるってことですよね。お化け屋敷の例はちょっと衝撃的でした。そういうふうにものを見るのって面白いな、建物の構造とかにもすべて意味があるんだなって思いました。

？？？「ボーッと生きてんじゃねーよ！！！」

エンジニアとしては、自分の作る製品のUXを4つのレベルの抽象度で捉えることができれば、自分の作る製品の体験(=仮説)に対して適切に検証していくことができるってことだと学びました。
UXとUXDについて、もう少し勉強したいと思います。とりあえずどっかのタイミングでUXデザインの教科書は読みます。

CircleCIの3000 万件のワークフローから得られたDevOpsに関する知見

登壇者

• 車井登さん
• CircleCI Japanのソリューションエンジニア

CirCleCIとは

• クラウドCI/CDサービス

CI/CD戦国時代

• 現状、いろいろなCI/CDツールが生まれては消えている
• 巨人たち(AWS,GCP,Azure)の参戦

CICDツールを使う動機・理由

• 最高のチームづくりをしたい
  • ハイパフォーマンスの開発をするには？
  • 自分たちのチームはそうなっているのか？
    • 上記の内容を知りたいためにデータ分析してみたという流れ

ワークフローの動作時間

• 最も長い時間 -> 3.3日
  • 長すぎじゃね？って思うけど一概に長すぎとまでは言えない
  • けどやっぱ長い
• ワークフロー内で結合テストやってますとかDocker File作ってますとか、プロジェクトによりけりなので、なんともいえない
  • でも開発者への情報のフィードバックは早いほうがいいよねって話になる

デプロイ頻度

• デプロイ頻度が一概に組織のパフォーマンスと繋がるかといえばそうでもないが、デプロイ頻度が多いってことは、コードの細かな修正と頻度の高いテスト実行によって品質を高めていることはわかる
• フィーチャーフラグ -> これ知らなかった。あとで勉強する
• いつでもデプロイ実行可能な状態にしておくことが大切

MTTR

• 問題が起きたらすぐにロールバック可能にしておく
• 高度な自動化の仕組みを作っておく
• ユーザから問題をあげられるようでは遅い
• 基本1時間未満で対応しよう

失敗の頻度

• Gtiのちからってすげー
  • マスターにできるだけ傷がつかないようにできるってところがいいよね
• 検証だったらがんがん失敗していこう

今後の分析方向

• 言語による違いもある（PHPは失敗頻度がほか言語より少ない傾向にあったとか）
• ブランチ数の違いも影響あるのでは？

私的感想＋まとめ

講演について

自社が保有するデータを使っての分析ということで、数値に基づいた考察をした講演でした。
自社を事例としてリーン開発の4つの指標に照らし合わせ、そこからわかることの発表という、堅実でわかりやすい話の流れでした。

内容について

最初に「「DevOpsに関する知見」とタイトルにつけたことを後悔しています」って予防線張っていたけど、確かにそうだったかもしれないと感じてしまいました。
というのも、データに対する考察が「一概にこれ！とは言えないが、少なくともこういことはわかるよね」って感じにまとめあげていることが多く、なんだかはっきりしないなぁって気持ちになりました。
でも、こうだ！と言い切るにはデータの量と分析がまだ足りないってことなのでしょうね。
今後もおそらく講演でそういう話をしてくださると思うので、注目しておきたいです。

デプロイ頻度の考察のところで、低パフォーマンスのチームは1ヶ月から6ヶ月に1回のデプロイと言われていました。うちのチーム低パフォーマンスのチームでワロタ。
継続的に製品をよりよいものへと高めていこうっていう発想で仕事をしていないんですよね。政治と金の都合によってプロダクトを作っている感じが否めません。業務アプリ開発だから仕方ないって諦めるのは、思考停止、あるいは自分自身の努力不足なのでしょうか？

常識を破壊するティール組織とエンジニアリング組織論

登壇者

• 片岡俊行さん
• ゆめみの社長、めちゃんこ頭良さそう
• ゆめみといったらやめ太郎さんだよねって思っていたら、冒頭その話してワロタ

ティール組織について

• 組織には発達段階がある
• ティール＝青緑色
• 群れ
  • 力や恐怖によってトップダウンの行動が可能
  • 組織が長期的に生きていかない
• 軍隊
  • 長期的な計画を立てていくことができる
  • 外部環境の変化に弱い
• 機械、合理性と能力主義
  • 競争原理が働き、成長bが促進される
  • 勝者、敗者に別れるし、勝者になっても幸せになるとは限らない
• 家族
  • 弱者救済が行き過ぎる
• 生命体（ティール組織）
  • 主体性が発揮される
  • 変化に対する不安
• どれかを選ぶのではなく入れ子の構造になっている
  • 組織が発達するにつれてデメリットが解消され、新たなメリットが生まれていく。一方で違うデメリットも生まれる

ティール組織事例

• ビュートゾルフ

ティール組織のモデル

• 役職主導 -> 役職に対して役割が紐づく
  • 役割が明確
  • 役職者に仕事が集中する
  • でも実際にそうなっているかと言われるとそうでもない。役割があいまいになる場合もある
• 役割主導 -> 役割に対して人を結びつける
  • 役割を明確に定義する必要がある。
  • その上で役割を分散する
  • できる範囲の役割の分だけやる
  • 役割検討会議に全員が参加して、組織を細かく設計修正していく
  • 自分の得意分野ができる人にその役割を割り当てる
  • マトリクス型組織

ティール組織のエンジニアリング

• マネージャー業務とは、制度ルールに則って（コードを書き）、マネジメントを行う（コードの実行）
• 経営とは命令によって制度・ルールを設定
• 報酬制度ではなく給与制度に問題があるのでは？
  • 金による動機づけは問題があるから
• 社員全員が会社というソフトウェアに対してコミットできることが重要
• 制度に対して誰もがコミット可能な仕組みにする
• これをゲームと捉えるとわかりやすい
  • プレイヤーは自身がゲームマスターになることができ、ルールに則って自分自身がゲームを変更することができるような組織
  • 経営者はルールブックを策定、改定し続ける。それが守られていること、あるいは変更をする。経営者は自身がプレイヤーになることもできる
• この組織形態がいずれパラダイム・シフトとして発生するであろう
• 制度改革を行える仕組みをつくることが大切
  • ただしおれがかえてやるんだっていう発想はトップダウンと一緒になるだけ、機械組織と変わらない
• 自分は変えられないって思わないこと
  • まずは自分からルールを適用して、チームで適用して、それが組織へと反映されていく

私的感想＋まとめ

講演について

頭のいい人にありがちな（とかいうバイアス）早口での講演でした。でも早口だからといってわかりにくいわけはなかったです。明瞭に話されていて聞き取りやすかったし、内容も説得力がありわかりやすくまとまっていました。
だから、あながち頭のいい人は早口というのは間違いではないのかもしれません。いや、ただ頭のいい人が早口で喋っていただけか？
どちらにしてもイケイケ感(カリスマ性)を感じさせる講演でした。

内容について

大半の企業は機械組織なのだということがわかりました。うちもそうです。
機械組織が家族組織へ、そしてティール組織へと変化するパラダイム・シフトは訪れるとのことでしたが、それはいつになることやら…
機械組織のままでも別にいいと思うんですよね。ただし、その組織に所属している人が幸福を感じられるっていう条件を満たせていればの話ですが。そしてのその条件は往々にして達成されないですよね。敗者になるのは嫌だし、勝者になっても幸せを感じられるかどうかわからないって、人生にとってだいぶリスキーですね。

興味深かったのは、全社員が制度・組織改革を行える仕組みを作るっていう点。
俺が自分の実力で金を作るっていう実績を出して、権力を持って会社のルールブックを作る側に回って、全社員が制度・組織改革を行える仕組み作ったるわ！では、それはもうトップダウンで実力主義の機械組織と変わらんってこと。ここが面白かったです。自分にはなかった視点でした。
組織って人の集合体であって、自分とそれ以外の他人です。組織を変えるってことは自分とそれ以外の他人を変えるってことになるのですが、他人を変えることはできません。だから自分を変えるっていう結論になるわけですね。各所で言われている、当たり前の着地点に着地しましたとさ。
だからまずは自分。自分がこれが幸せを感じられるって思うことを率先して行っていき、身近な周りの人に紹介する。それが認められればチーム、組織、会社へ波及していく。その最終形が組織のパラダイム・シフトって感じなんでしょうか。それがいかに時間がかかるかで人は環境を変える＝転職するのかなっていう気もしました。
草の根運動が大事ってことですね。

質とスピード

登壇者

• 和田卓人さん
• それサバンナでも同じこと言えるの？
• テスト駆動開発著者、プログラマが知るべき97のことにも寄稿している、つよつよエンジニア

講演資料

品質について

• 予算、時間、スコープを満たすために品質を犠牲にしがち
  • 犠牲にしようとしているのはだいたい内部品質
• 短期的にスピードは得られるが、中長期で逆効果を発揮し、死ぬ
  • 短期的と中期的ってどれぐらい？
• 品質＝○○性、ilities
• 狩野モデル

内部品質とは

• 内部品質次第で外部品質も変わってくる＝外部品質は結果
• 犠牲にしてきた内部品質は保守性（他2つはユーザビリティと切り離し可能レベル）
  • 保守性をさらに3つに分割
  • テスト容易性
  • 理解容易性
  • 変更容易性
• で、保守性を犠牲にささげてスピードは得られるの？
  • あとでクリーンにするから（クリーンにするとはいっていない）
  • 顧客はまってくれないから
  • 次の機能、次の機能と仕事が与えられてしまう
  • コードが荒む
  • 保守性を犠牲にしたことによって、呪いの言葉が生まれる（動くコードにふれるな！）
  • コピペ、コピペを繰り返し、そのコピペに重大な間違いが発生、あるいは仕様変更が発生したときに大変なことになる
    • Grepで引っかからないものも発生する危険がある
  • 結果、爆弾処理のようなリリースを常に行うことになる

技術的負債がもたらすもの

• 一つ一つの変更に倍、三倍と時間が累積的にかかるようになる＝スピードが落ちる
• 変更がなければいいよねっていう話になるけど、今の御時世プロダクト作ってはいおしまいなんてことはまずないだろ

スピードを落とせば質はあがる？

• 時間を与えたとて、質の高いコードをかける人はある程度の品質を書くし、クソコードを書く人はクソしか書かない。
  • なぜなら技術レベルが一定以上の質の水準にならないから
• クイック＆ダーティの神話
  • IT業界三大神話の1つ
• 質とスピード、保守性とスピードはトレードオフではない
  • トレードオフ構造を見つけて要はバランスって思考停止するのは、掘り下げきれていない証拠
  • 質とコストはトレードオフか？ -> 議論の余地がある：Quality is Free（品質実質無料）
    • 品質を向上させることで手戻りが減る＝コストが減る
    • 手戻りを直すのにかかるコストと品質をあげるコストが相殺する
• 事実としては、短期的にも長期的にもうんコード書くほうが常に遅い（過激派）
• 品質を高く保っていた「からこそ」早く開発できたといえるのでは？

スピードから質への作用

• スピードを取ると、手戻りが発生し、手戻りが発生すると学びが生まれない。
  • 仮説、検証のサイクルに影響が発生する
• コードの生産性４つ -> circleCIでもでてきたやつ、リーン開発の4つの指標
• 質が上がる -> スピードが上がる -> 学びが生まれる -> 仮説、検証ができる -> 外部品質が生まれる -> いい製品が生まれる -> 売上が生まれる -> 製品にさらなる機能を追加、変更ができる -> 内部品質が～になる

個人の質をあげるのか

• 正解はない
• システムを設計するための判断力が重要、自分で設計したシステムを自分で長い間メンテすること
  • 自分自身の内省によるフィードバックと外部からのフィードバックを自分で受けることができるから

内部品質に対する投資の損益分岐点はいつ訪れるのか

• テスト保守性は自動テストで補える
• およそ４回実行したタイミングで損益が逆転する
• 全体的な視点でみたらどうか
  • 思ったより早くやってくるよ（ふんわり）
  • 定量的なデータから見ると、1ヶ月以内に現れる
• 短期的とはごく局所的であるという事実
• 中期的に見れば1ヶ月以内

結局何を削ればよかったの

• スコープ削れ
  • 予算は動かせない
  • 品質は動かしても意味ないうえに逆効果
  • そうなると時間かスコープかって話になる
  • 時間を延ばすと単位時間の生産性がわからなくなるのでやめたほうがいい
• スピードと質のトレードオフになっているものは教育、次世代への投資、多様性、メンバーの成長
  • これらが犠牲になっているかもしれない

私的感想＋まとめ

講演について

まず気になったのは、講演聞きに来た人の多さです。デブサミの中でも大きめの会場だったのに、それを上回る超満員でした。
まあ私もテスト駆動開発読んでいたし、サバンナのライオンのAAで有名な人の講演だからぜひ聞きたいって思って聞きましたが、みなさん同じ考えだったようですね。
ユーモアあふれる解説と、説得力のある内容でめちゃ楽しめました。
講演自体は以前やったものをブラッシュアップしたものとなっていました。以前やったスライド資料はネットにあがっておりそれを読んでいたので、内容自体の目新しさは感じられませんでしたが、ただ資料見るだけと実際に人の言葉として聞くとでは自分の中での納得感が全然違いました。そういう意味でも、聞いて満足できる講演でした。

内容について

クソコードを書く人に時間を与えても、クソコードしか書いてこないにグサッ、短期的にも中期的にもクソコードを書くやつは遅いにグサッ、質とスピードはトレードオフだよなっつって思考停止すんなにグサッって感じでした…見に覚えがありすぎる。
でも正論なんですよね。講演で解説されていた通り、一定水準のレベルのプログラマはリミットが短くてもある程度良いコードを書く、レベルの低い人は時間を与えても与えなくてもその水準を超えることはないからうんコードをもりもり量産するっていう理論は正しい(与えた時間で猛勉強して急成長するなら話は別ですが)。
しかも、定量的データで質のいいコードにかけるコストの損益分岐点が1ヶ月以内に訪れるっていうんですから、もうぐうの音も出ないですよ。実際、経験の浅い私でも質のいいコード書いてりゃ、今ここでこんなに苦労しなかったろうに…と後悔したことが何度あったことか。
まさにクイック＆ダーティは神話だったということです。ちなみにIT業界には人月の神話っていうのもありますよね。3大神話として数えようとしたら、あと1つはなんでしょうかね？No Silver Balletとかですかね。

質とスピードは相互依存関係、じゃあなにとトレードオフになるかというと、教育とか多様性とか成長とかになるのではないかと推測していますっていう締めで講演は終わりました。
これ、SIerの業界構造上の問題も絡むことかもって思いました。
うちは企業のエンジニアと人材派遣のエンジニアの協力体制で開発やっています。私はユーザ企業側のエンジニアとして、協力してもらう人材派遣のエンジニアさん(以下パートナーさん)と一緒にお仕事をしています。ユーザ企業のビジネス領域についての質問だったら苦痛を感じることなく答えます。でも、パートナーさんから技術的な質問をされたり技術的な教育をしたりするのは本当に面倒くさく感じるんですよね。
その技術力はパートナーさん側の会社が教育を施すことでしょ？あなたはうちの会社から私の給料の3倍ぐらいの単価でお仕事しに来ているのになんで求めている水準以下なの？なんで私は自分の3倍の単価の人間にこんなことを教えなきゃならんの？ってネガティブ思考に陥っちゃうんですよね（愚痴です、すみません）。
これが自分の会社の人だったら話は変わるんですけどね。明確な違いはパートナーさんはいなくなるリスクが自分の会社の人間より高いってところでしょうか？自分の会社の人間だったら、すべて自分の責任、自分たちの責任の範囲に収まりますが、パートナーさんは協力会社の都合でやめるっていう場合もありますよね。だからパートナーさんに教育、投資してもそれに見合ったリターンが返るかどうかわからないって強く思ってしまう。それが後々のビジネス感覚に影響して、教育とか成長への投資を鈍らせるようになってしまうのかもしれません。
って考えるとまずい傾向ですね。とりあえず情けは人の為ならずを心がけます。

ともにつくる「DX」〜事業会社、スタートアップ、グローバル、そして・・・「あなた」〜

自己紹介

• 福井勝史さん
• Insight EdgeのCTO

InsightEdgeについて

• 住友商事グループ内にある、DXを推進する組織
• 住友商事のビジネスドメインに対して、最新Tecで解決していく

DXのについて

• DXの主体はビジネス＝ビジネスありきでそれに対して技術で何ができるかということ

DX推進プロセスについて

• 企画と計画の部分が重要、エンジニアも携わる
  • 新規・既存のビジネスモデルをエンジニアが理解するこが必要
  • エンジニアの視点からも口出しすることができる点もメリット
• 企画・計画段階で目的とゴールを明確に文字としておこすことが重要
• 従来は企画設計はコンサルが、開発はエンジニアが行うという構造だった
  • デメリット多し
  • ノウハウが分散する
  • 内部の人間が技術に対する理解度が低くなる
  • 費用とスピードにも影響
• ユーザ企業とITベンダの割合は3:7
• プロダクトオーナーと開発側が協力することが重要

私的感想＋まとめ

講演について

お世辞にもいい講演とは言えませんでした。あの場にいた人だったらわかるはずですが、講演終了後の拍手の音がそれを物語っていましたね…
というのも、タイトルがよくなかった。カッコでDXをくくっているからには、DXとは？から入り、DXを各人、組織、会社間でどうやって実現していくか？的な知見の解説になるのかなって期待していたんですが、実際はただ自社のやっていることの紹介＋採用広告でした。
勝手に期待値あげていた私も悪いのですが、それを差っ引いてもつまらない講演でした。事業内容をあげる＋事業の進め方の説明という構成でしたが、事業の進め方もこれといってDX事業だからという特別なことは何1つ語られておらず、あまり得るものがありませんでした。
ここからは完全な邪推になるのですが、会社側から「デブサミ講演の枠とったから、自社アピールして少しでもも人材集められる機会を作ってね。じゃ、あとよろしく～」って感じでぶん投げられたから、ああいう内容になったのかと。
でもあの内容だったら採用広告っていう面でもむしろマイナス感（つまらない講演をする企業）があったので、やらないほうがマシだったかもしれませんね。

ただで聞けるものに文句言うな！

内容について

せめて自分なりになにかを得たいと思って、講演聞き流しながらその内容についていろいろ考えてみました

まず、企画・計画の部分にエンジニアが携わるってところですが、これDDDやるなら必須ですよね？DX関係ない気がしました。
DDDをやるやらないにしても、エンジニアは開発の背景、物語、あるいは全体像を知っていると知っていないとでは、パフォーマンスに影響が出ると思います。自分が何やってるかわかっているのとわかっていないのではモチベが全然違いますよね。

ユーザ企業が自社内にエンジニアを囲いこみに行く潮流はもう必至の流れだと思います。なんちゃらpayっていう苦い大失敗もありましたよね。
そういった例もあれば、他に失敗している例もあとを絶たないですし、そもそも今のIT業界の構造は多くの人に幸せを感じさせることがないっていうことをやっと学んで、なにか対応策を講じなければと企業も考えだしたってところでしょうかね。
だから中長期的に人に投資することが重要になってくるってことですね。質とスピードの感想で書いたことにも繋がりますね。

礼節から育てるチームの健康と信頼性

登壇者

• 塩谷啓さん
• クラスメソッドの自社サービスの開発にて、チームリーダー的なことをしている人？(Team Reliability Engineer)

講演資料

チームとは

• 相互に依存した人々の集まり
• チームで働くこととは
  • 一人でできることは限られているから
• プロセス知識スペクトル
• ルーチン業務について
  • 継続的改善が求められる
  • 不安なことは何一つない状態
• 複雑な業務について
  • 専門性を結集し、すばやく問題を解決する
• イノベーションの業務について
  • 仮説、検証をサイクルさせる
  • 不安だらけだから
• 上記３つを達成するためには、一人の学びをチームの学びにする必要がある

健康と信頼性について

• 一人の学びをチームの学びに変えていくためには、建設的な衝突が不可欠
• 信頼性について
  • チームに求められる３つの業務を継続的に成果として出していくことができる
• 健康について
  • 人間関係のリスクがない＝心理的安全性が不可欠
• 心理的安全性＝カジュアルにヤバイことを言える雰囲気
  • カジュアル＝対人関係リスクなし
  • やばいこと＝不安だらけなこと
  • やばいことをいうのはなんのためか
    • チームが目的に近づくため
    • なんでもかんでもいいたい放題いっていいってわけではないよね
• なかよしとは違う
  • 休日にBBQやったり飲みニケーションしたりしても、それが仕事上の心理的安全性につながるかっていうとそうではない
• 基本的には心理的安全性がやっぱり重要だよねっていう話

礼節

• TeamGeekの紹介、HRT
• think civility
  • 礼節の重要さを解く本
• 無礼とは？
  • マウント
  • 立場を背景にして接する（○○ハラ）
  • 無関心
• 礼節とは？
  • 無礼の逆
• 無礼な態度はチームにとってコストを発生させる
  • 実証実験によるデータが存在する
• 礼節持った態度を振る舞うことはチームのメンバーとしての責任
• 礼節はプロトコル、もはや通信規約、コミュニケーションのお約束
• 礼節はコミュニケーションの土台となるものなので、人格とか素質とかそういった次元の問題ではない
• 正しいことは強いことなので、せめて態度だけでもやわらかく、優しくいおう
  • これまじで難しい
• 礼節から順に成果を出すチームへと依存していく＝つまり個々人が変われ。

礼節の前に大切なこと

• 心身が健康であることが一番重要、命より重要
• やんでいるときに礼節をもった対応なんかできないよね
• 自分の機嫌をコントロールすることが礼節へと繋がる
• つまり体調管理こそまず第一に行うこと

私的感想＋まとめ

講演について

ユーモアに溢れた喋りと、チームとは何かからスタートして階層構造的にどんどん掘り下げていく話の進め方が非常にわかりやすく、この講演も満足度の高い講演でした。
Google re:WorkもTeamGeekも読んでいたので、1/3ぐらいは既知の内容でしたが、Think CIVILITYは読んだことがなかったので得られる新たな知識も多かったですし、心持ちも改めなければと思うところもありました。
今度Think CIVILITYも読みたいと思います。

また冒頭で技術書展で本を出しますと話していたのも気になりました。技術書展の存在は知っていたので、この機会に行ってみようかなとも思いました。

内容について

チームについては当たり前の内容を話していたので、その通りだよなと頷くだけでした。

健康と信頼性のところで、心理的安全性をカジュアルにヤバイことを言える雰囲気って言い換えて説明していたのには笑いました。いい口語訳だなって思いました。
大事なのは目的を見失わないこと。チームの目的に対しての手段として、やばいことを言うことが重要。そこに結びつかないヤバいことを言っていたら、ただのヤバいやつですからね。

礼節については、思うところがいろいろありました。礼節は人格がどうこうではなく、仕事としてやることの1つっていう考えは今までの私にはなかったので、これからはちゃんと実践します。
正しいことは優しく言うっていうのは、自覚している私の問題点の1つですね。
優しく言うって難しくないですか？優しく言うってどういうこと？笑顔で言うってこと？オブラートに包むってこと？オブラートに包むと真意が伝わらないっていう不安に駆られるんですが。口調とか態度ってことなのかなぁ…

そして礼節よりも心身の健康が大事。これはガチ。
自分を大切にしよう。そのために必要なのは食事、睡眠、運動。
プロジェクトマネージャーが知るべき97のことのどこかでも書かれていた気がするんですが、私たちはただ幼稚園児、保育園児がやっていることをやりゃいいだけじゃんって感じがしませんか？ご飯食べて、体動かして遊んで、よく寝て、挨拶をして、チームの人たちと友達になって、新しいことにワクワクして、素直になる。私たちはなぜこれが難しいと感じるようになってしまったのでしょうか。

結局この講演でも言われていたことって、個々人の態度がチームの雰囲気を作り、チームをハイパフォーマンスにするっていうこと＝他人は変えられないから自分が変われってことですよね。最終的な着地点は自分ということでした。

他

ノベルティ＋オライリー本購入特典のTシャツです。
タックスくんかわいいですね。