冒険。ロマン。船はその文明、文化における最新技術の結晶と水中(船舶)考古学は伝えます。今の時代ならば宇宙分野もそうかもしれませんね。昨年2021年の12月、ジェイムズ・ウェッブ宇宙望遠鏡が打ち上げられています。望遠鏡に代表される新しい「観測手段」が新しい発見を導くことは常に期待されていますし、機械部品が少ないだけ故障の心配も少ない面も興味深いところです。

そんな宇宙分野から学ぶことは多く、例えば医学界新聞では宇宙分野に学ぶチーム作りという記事を出しています。

翻ってみると日本のIT業界はどこまで異分野の知見を活かしているでしょうか。IT業界は成熟しつつある一方、話題がIT業界内で完結しがちで異分野の知見を活かす機会が少ないように見えます。キーワードさえ知ることができれば、検索して深堀りがしやすい。そこで、いくつかの専門用語とカケハシでの適用事例を紹介します。

＊この記事は、DevOpsDays Tokyo 2022での以下講演を再構成したものです。

広げていくにあたり何から手をつければ...

Team TopologiesでいうEnabling Teamで多く、Platform Teamでも見られることが、何かを組織全体に広げていくことです。構築した社内プラットフォーム、クラウドベンダーの新機能や新しく導入したSaaSを広めていくことは一つの大仕事です。開発プロセスならレビューガイドラインを広めたい、データに基づく開発を広めたいということがあるでしょう。開発外でも開発者ブログを皆に書いてもらう、採用に協力してもらう、といったこともあります。なにから手をつけていけば良いのでしょうか。

そこで登場するのが、⚡チェンジマネジメント⚡

古典的な「ジョン・コッターの変革の8段階のプロセス」なら以下のとおりです。

危機意識を高める
変革推進チームをつくる
適切なビジョンをつくる
変革のビジョンを周知徹底する
従業員の自発的な行動を促す
短期的な成果を生む
さらに変革を進める
変革を根づかせる

まず覚えておきたいことは、変革には実はコツ、型が存在するということ自体です。実施にあたっては、漫然とステップに従うよりも、プロセスや施策に抜け漏れがないか、計画時点や推進途中で検討するときの材料として便利でしょう。

チェンジマネジメントはGoogleでも取り入れられているほか、ガイド本や資格もあります。

カケハシの開発組織では

例えばE2EテストツールのMablを導入するときに重宝しています。

スキルアップ方式をどのように設計すれば...

オンボーディング、スキルトランスファーと人材育成は開発組織にも不可欠です。開発者体験の改善も、迅速な立ち上がりには効果的でしょう。前項のチェンジマネジメントでも皆に学習をしてもらう必要があります。そのために、スキルアップ方式をどのように設計すればよいのでしょうか？

そこで登場するのが、⚡「成人学習理論」Andragogy⚡

アンドラゴジーと対比されるのがペタゴジーで、皆さんの学生時代の教授法とみなせます。一方、アンドラゴジーのような成人の学習は問題解決中心で、学習者が自分自身のペース、自分自身のモチベーションで学習します。

まずは、成人の学習は子供時代での勉強イメージとは異なることだけを押さえておきましょう。小中高のようなコンテンツ作成法、教授法になっていないでしょうか？

ここでクイズです。

成人の学習の特徴として正しいのはどれか。
1.　学習者のこれまでの経験が資源となる。
2.　外的動機づけによって学習が促進される。
3.　自己評価よりも他者による評価が重要である。
4.　課題中心の学習よりも講義形式による学習の方が効果が高い。

第102回看護師国家試験で出題された問題です。出題の背景として、例えば慢性疾患では病気とその付き合い方を学んでもらうことが挙げられ、看護過程のうち看護計画の一つにも教育計画(E-P)があります。

カケハシの開発組織では

エンジニア向けオンボーディングで活用しています。入社時の詰め込みではなく細かくコンテンツを区切り、必要になったタイミングで読むような構成を心がけています。

発言が特定の人に偏りがち

会議のよくある悩みとして、発言が特定のメンバーに偏ることがあります。慣れている人、外交的な人がどんどん発言し、新メンバー、内向的な人の発言が少ないことはありませんか？人数が多いとなおさらです。

そこで登場するのが、⚡ターンテイキング⚡

言語学、言語哲学、社会学といった分野の会話分析で使われます。

発見された会話のルールとして以下があります。

話者は一度に一人のみ
順番を交代していく

一見当たり前ですが、重要な結論が導けます。30分の会議に10人が出席すると、一人あたり3分しか話せません。なお学術的には、話者が交代する条件といったことが研究の対象です。

カケハシの開発組織では

会議人数の削減を前提として、非同期コミュニケーションを活用しています。

一つ有効なのがホワイトボードツールです。付箋の書き下しと閲覧の時間を設けることで、短い時間で効率的に全員の意見を集めることができます。Google Workplaceを契約していれば、Google Jamboardが無料です。

チャットも効果的です。浮かんだ疑問がすぐ解決したり、ラジオDJ形式でコメントを取り上げたりしています。

危機的な状況のなか、どう支援するか

障害対応中には、苦しんでいる人、燃え尽きる人がどうしても出てしまいます。その中には自分自身も含まれます。危機的な状況のなか、どう支援していけばよいのでしょうか。

そこで登場するのが、⚡WHO版心理的応急処置ガイド⚡

このガイドは専門家でなくても誰でも使える、心理的支援の手引きです。障害は災害に近い面があることから、このガイドの内容をおさえておくと良いでしょう。自分自身に対するケアも記載されています。

障害対応時のような、緊急かつ強度のストレスに対する反応は様々です。ご存じの方も多いのがFight or Flightで、攻撃的になる人もいれば、文字通り動けなくなる人もいます。障害対応中に完全に緊張して震え、体が固くなる人も見かけたことがあります。他によくあるのは呼吸が浅くなる、首の緊張状態が進むなどでしょう。

基本的なこと、呼吸をする、食事を摂る、休憩するといったことを忘れないようにしましょう。それが結果的にパフォーマンス改善になりますし、なによりケアになります。

カケハシの開発組織では

以下記事のように、インシデントふりかえりガイドで活用しています。

社内で情報を共有するには...

障害対応中によくある悩みとして、どのように情報を共有するかが挙げられます。不確かな状況のなか、速度を求めつつ、正確さも必要です。

エンジニアチーム内なら、どのサービスがおかしく、どのような連鎖があるのか。報告の負荷も減らしたいところです。チーム間なら、自チームが関係あるのか、支援できることはあるか。サポートなら、影響範囲はどこで、一時的な回避策はあるのか。どこまで開示できるのか。経営陣なら、結局なんなのか。支援には何が必要なのか。これらは悩ましい問題です。

そこで登場するのが、⚡状況認識の統一「Common Operational Picture」⚡

文字通り「地図」として、ひと目で理解できること、適切に更新されることを目指します。Incident Command System(ICS)というあらゆる規模や種類分野の災害に対応した共通フレームワークにおける、初動の重要項目の一つです。日本の行政でも災害対応時に作成されるようになってきており、本格的にここに人手を割く価値があります。

＊ICSの解説自体は別稿に譲ります

カケハシの開発組織では

ホワイトボードツールを利用して地図化できないか検証中です。他と比べたホワイトボードツールのメリットとして、注目すべき部分を容易に強調できることです。

開発に便利な仕組みを使いたい...

開発でよくあるトレードオフとして、実装するか、購入するか(build or buy)があります。自社で作成する、OSS、ライセンス購入、SaaSと手段は豊富です。どのような基準で判断すればよいのでしょうか？

そこで登場するのが、⚡機会費用⚡

いくつか同じ工数のプロジェクトがあり、工数が限られているのでどれを実行するか選ぶとしましょう。効果が工数の2倍がプロジェクトがあったとして、それを実行すべきでしょうか。2倍はなかなか良さそうですね。

答えは「わからない」です。なぜならもっと効果があるプロジェクトがあるかもしれないからです。ベストな選択肢からある選択肢の差分が機会費用とみなせます。字面で書くと単純ですが、実際に実行することは案外難しいものです。例えばすでに世の中に存在するものの開発にエンジニアを割り当ててしまえば、コアの事業、差別化要素といったもっとやるべきことに時間を割けないことになります。エンジニア市場が過熱し採用が逼迫しているなか、今の割当は本当に最適でしょうか。

＊資本コストの議論はまた別