自分が働いているGaiaxのように, 社内に複数の事業があり, それぞれにエンジニアが所属して働いている場合, ｢ねえ, ○○のチームの××って仕組み, どうやってるの? うちのチームでもやってみたい!｣といったコミュニケーションから, 他のチームに対して｢技術的支援｣をする機会が生まれる事が多々あります.

最近の例だと, 社内の新規事業の立ち上げや, オンプレからクラウドへの移管のタイミングで, Infrastructure as Codeやデプロイ施策, ChatOpsなど整えたいので, 相談に乗って欲しい! という声を何度か頂いた事がありますし, よくよく考えると今やっているPhotosynthへの留学も, 見方を変えれば｢Photosynthへの技術支援｣と言えるかもしれません.

そういった｢技術的支援｣をする時に気をつけている事についてFacebookにつぶやいた所, 思ったより反響があった(ような気がした!?)ので, 備忘録として, そして自戒としてブログにも綴っておこうと思います.

｢自分のこだわりや考えを, 一方的に押し付けない｣

何かしらの｢技術的支援｣をするということは, そこに｢支援する人｣と｢支援される人(チーム)｣という関係が生まれます(なお, 以後"支援する人"を"支援者", "支援される人(チーム)"を"支援先"と呼ぶことにします). そして, 支援をする｢何らかの技術領域｣において, 支援者は支援先よりも深く取り組んでいて, 一日の長があるはずです(だからこそ, その知見を活かすべく支援先は支援者に技術的支援をお願いするからです).

そういう時に, 気をつけないとやってしまいがちなのは, 支援者が過去の経験から導いた解決策(支援先に存在する課題を解決するための手段)を, 一方的に支援先に押し付ける, というやり方です.

このような技術的支援がうまく成果に繋がるパターンも多々あると思います. しかし, 場合によっては支援先の課題を解決するはずの技術的支援が, 支援先に新しい課題を生み出しているパターンがあると思います.

1つは, 支援者が提案した解決策が, 支援先が使っている言語, フレームワーク, ミドルウェア, インフラ, ツールなどの文化や慣習に則っていないパターンです. この場合, 支援先が支援者の解決策をそのまま鵜呑みにして実施していったところ, 支援先で既に利用している何かしらの技術的要素の文化や習慣に則っていないが故に, 新しい別の問題が生じてしまう, という結論に行き着きがちです.

もう1つは, 理想と現実の壁が出来上がるパターンです. 支援者が一方的に解決策を押し付ける場合, その解決策は支援先の現在の状況(支援先が利用している技術的要素に加え, 開発しているプロダクトの特徴であったり, そのチームの文化, 状況, 習慣であったり...)が考慮されていないパターンが多いはずです. そうなってしまうと場合, 支援先は支援者が提示する解決策(理想)と, 今の支援先の現状(現実)のギャップが大きすぎて, 解決策を実現する為に大きなコストを捻出しなければならなくなるはずです.

...また, 日本人は｢変化を嫌う｣とよく言われます. ｢変化を嫌う｣事に対する是非はともかくとして, このような大きなギャップを乗り越えに行こうとすると, チームの中でも賛否が別れる可能性は容易に想像出来るのではないでしょうか.

ここで支援者が解決策の実現を強行すると(例えば, 支援者が実際に手を動かして実装を始める, など), 言うまでもなく支援先の理解や納得のないまま作業が進んでいきます. 大抵, このパターンは中途半端な結末に終わる事が多いです.

例えば, 解決策の実現が中途半端に終わってしまうパターンもあるでしょうし, 無事完成まで至ったとしても, それが支援先に引き継がれない(使われない, 有効に利用されない)という事もあるでしょう.

｢支援者｣が気をつけるべきこと

ここまで, 技術的支援をするときに, 支援者が｢自分のこだわりや考えを, 一方的に押し付け｣た時に, 支援先に与えてしまう可能性のある悪影響について述べてきました.

ここでは, 逆にこれを防ぐ為に支援者はどのような取り組みができるのか? というところについて, 現時点の気付きを述べたいと思います.

...といっても, それは難しい事ではなく, ｢自分のこだわりや考えを, 一方的に押し付ける｣の反対のことをすればいいだけだと思っています. すなわち, ｢自分のこだわりや考えを活かしつつ, 支援先と解決策を一緒に考える｣ではないでしょうか.

支援者が成し遂げるべきは, ｢支援者の理想を支援先に実現させる｣ではなく, ｢支援者の支援によって, 支援先の業務が最大効率で回るようにすること｣です(但し, この2つがイコールになる場合もあると思います).

そのためには, 解決策を示す前に, 支援先の現状と課題をしっかり調査し, 理解に努めなければなりません. そして, そこから単純に解決策を提示するだけでなく, 一旦提示した解決策に対する反応を受けて, 更に解決策をブラッシュアップしていく必要もあるでしょう.

更に, 解決策はなるべく複数のフェイズに分離して, 少しずつ進められるように構築する方が良いでしょう. 言い換えれば, 支援先の課題を細かく分離して, 1つずつ解決していくように道筋を作るべきです. こうすることで, 支援先はその解決策によってどのような問題が解決され, どのようなメリットを得られるかが理解しやすくなります. 加えて, 一度に大きな変化を実現する場合と比べると, 細かい変化を繰り返す方が, その変化にかかるコストの見積もりもやりやすくなるでしょう.

まとめ

ここまでの話をざっくりまとめると, 技術的支援をするにあたって大切なのは, 支援する技術に対する知見だけではない, ということです. 何かしらの技術的支援をするエンジニアには, 支援先に対してより良い解決策を示せるようにするための工夫が求められます. その1つが｢支援者と支援先の相互理解｣であり, そのためにしっかりコミュニケーションを取り, 信頼関係を育んでいく事が大切, ...だと, 個人的には思っています.

いずれどこかのタイミングで詳しくお話しようと思いますが, GaiaxのRNDに新しく｢Delivery Support Team(仮)｣というチームが出来ることになりました. このチームは, ｢エンジニアが開発したサービスと, そこからの生まれる価値を顧客に"届ける"｣, という行為を｢Delivery｣と称して, そのために必要な全ての技術的要素(例えばCI環境の整備, デプロイフローの構築, ChatOps, Infrastructure as Code, IaaS/PaaS移行支援, ミドルウェアの導入/移行支援, チューニング, などなど...)を支援するチームです.

4月からは, この｢Delivery Support Team｣としての活動, すなわち他のチームへの技術的支援が業務の主になってくるので, ｢自分のこだわりや考えを活かしつつ, 支援先と解決策を一緒に考える｣を胸に刻んで取り組んでいきたいと思っています.