変化を促すということ

posted at  

最近同僚と話す中でどうやって自分が思い描くようなソフトウェアエンジニアリングのプラクティスを導入していってるのかという話をしたのでメモ書きとしても残しておく

TL;DR

まず結論からでいうと、自分は何かしらの変化を促そうとする時には、まずは相手の力学を理解した上で、ゴールを共同化し、相手にその変化が自分の課題解決のために必然であることを理解してもらった上で長い時間をかけて変化を促していき最終的にはそれを文化に昇華させていくという流れを大事にしている気がする。

変化を促す難しさ

ソフトウェアエンジニアリングに限らず何かしらの新しい取り組みや改善を促していくのは一般的に難しいと考えている。
例えば、「自動テストを書くべき」という主張をしたところで「それはそうだが」となりその後のアクションにつながらないとか「なぜそれが必要なのかわからない」とか論理を超越した何かにぶつかる感覚を経験したことがある人は少なくないと思う。
ここで「こんな一般常識を共有できない人や環境では働きたくない」となるのは簡単ではあるし、1つの解ではある (特にジュニアなキャリアのうちは) とは思うがあえて留まり変化を促していく際に思うことを書いていく。

突然ではあるが、SCRUMMASTER THE BOOK (原著は The Great ScrumMaster: #ScrumMasterWay) という本が自分は好きで、その中に 「変化を成功させるための8つのステップ (Eight Steps for Successful Change)」という節がある。
その中で以下の8つのステップを紹介しており、ここからも変化を促すことは時間がかかる取り組みであることがなんとなく察することができる。

  1. 危機意識を持つ
  2. チームをガイドする
  3. 変化のビジョン
  4. 理解と了承
  5. 人々の行動を促す
  6. 短期の成功
  7. 気をゆるめない
  8. 新しい文化を創る

自分はこの中でも特に最初の 「危機意識を持つ」 が非常に重要でより詳細に以下の3段階に分けて、アプローチしていることが多いのかなと感じている

  1. 相手の力学を理解する
  2. 相手のゴールを共同化する
  3. 相手に変化が課題を解くのに必然であると納得してもらう

それぞれ順番に補足していく。

1. 相手の力学を理解する

まず何よりも変化を促そうとしている相手が晒されている環境を理解することが非常に重要だと思っている。
自分はその相手に働いている力という意味で 力学 と呼ぶのが好きだけど、具体的には組織での立ち位置、ステークホルダーからの要求、負っている責任、その人自身の特性などなど多岐に渡るところをまず聞いて、観察する。
この段階では、最も大事にしている かつ 課題に思っていることを発見することが目的となる。
例えば先の「自動テストを書くべき」の例だと 「スケジュール納期が強い案件やそういったコミュニケーションをしている場合が多い」 という力学と 「障害発生時の差し込みによるスケジールの不安定さ」 という課題が発見できれば最高という感じ。

2. 相手のゴールを共同化する

次にその相手の力学を自分も負ってみる。
もちろん全てを同じように力学を負うのは無理な話なので、間接的にKPI指標だったり相手がレポートに利用している定量や定性の目標があればそれを自分のゴールとして設定するなどのイメージ。
このように同じゴールや課題を背負う、自分にも設定するというのを自分は 「共同化」 と呼んだりしている。
(※ 「共同化」についてはもちろん脳裏には SECI モデルがあるが正確にはちょっと違うのでいいネーミングがないものかと頭を悩ませている)
この辺は組織によって色々 How がある箇所だけれど要するに相手に 「この人も自分と同じ課題を解決しようとしているんだ」 と思ってもらうことが目標。
例えば、1の例の延長だと 「スケジュール納期を守れるように差し込みの発生率を下げる」 というゴールを共同化するイメージ。

3. 相手に変化が課題を解くのに必然であると納得してもらう

ここまで来ると、ゴールと共にどこに課題があるかということも共同化できているはずで、あとは自分が提案しようとしていることや促そうとしている変化がいかに相手の課題を解くことができるのかを納得してもらうことが大事となる。
でこここそが専門性を発揮する部分で、スペシャリストとして相手の課題を解決するインパクトが大きく かつ コストが安いもの (いわゆる Low Hanging Fruit) からアプローチを実行していって、小さな成功体験を積み重ね、 「ほら、自動テストがあるとあなたが重要視している力学やそこから出る課題が解決できるでしょ」 を実行を以って伝えていくことになる。
この辺になってくると、先に挙げた8つのステップのうち2番目に進めている感覚になることが個人的には多い気がする。
これまで出してきた自動テストの導入の例だと例えば 「まずは差し込みとなってしまってる障害がどういった傾向があるのかを分析し、そこのデグレを検出することができるテストケースからまず整備していきましょう。最初は手動でもいいですが最終的にはそこも自動化していきましょう」 のようなイメージ (ここまで来るとアプローチ方法は課題に完全に依るので腕の見せ所である)。

まとめ

冒頭でも述べた通り、自分は何かしらの変化を促そうとする時には、まずは相手の力学を理解した上で、ゴールを共同化し、相手にその変化が自分の課題解決のために必然であることを理解してもらった上で長い時間をかけて変化を促していき最終的にはそれを文化に昇華させていくという流れを大事にしている気がするなという思っていることをメモ書きとして残してみた。

余談

上記のような動きは単純化していくといわゆるコンサルが得意領域としているような気がしていて、最近以下のようなコンサル出身者の本を読んだりしている。

この辺もまた読んで感想とか書けたら、 https://scrapbox.io/omuomugin/book に書いていくつもり