ツナワタリマイライフ

日常ネタから技術ネタ、音楽ネタまで何でも書きます。

チームに変化を導入するときに心がけていること

はじめに

今日もポエムです。

本当は会社のアドレスで登録しているqiitaにこれを投稿しようと思ったのですが、プログラミングじゃない、ポエムは嫌われそうなので、こちらに書くことにしました。

きっかけは後輩くんとキャリア面談(笑)をしているときに、「なんで(たけさんは)いろんなあたらしいことを見つけて、チームに導入できるんですか」と言われて、自分なりにそのとき考えた答えをまとめておきたかったから。

そしてそれを後輩くんに伝えるためにqiitaに書きたかったんだけど残念。(笑)

何を変えてきたの

日常的に改善を行ってきたし、課題意識を持って変えてきました。

  • 部/チームにmattermost(slackクローンOSS)導入 -> 今は部の1/3ぐらいがactive user、プロジェクトや開発環境管理にも活用
  • プロジェクトにmattermost分報導入
  • 障害チケットをmattermostに通知する仕組み導入
  • 修正パッチ作成ツールをCI連携し全自動化
  • 仕様書等のドキュメントレビューをgitlabのMRで行うように変更
  • 週の進捗報告で前週との差分が見えるようgitで管理/報告
  • OSS導入、活用推進
    • mattermost
    • knowledge
    • gitlab
    • ...ほか多数

残念ながら商用環境に対して何かを変えて顧客価値、ビジネス価値をもたらした、みたいなことはできていません。

自チーム、部に閉じた範囲では何も言われないので(笑)改善提案して、それを流行らせるってことは結構得意なほうだと思っています。

心がけていること

なんとなく書き出してみて、新しい仕組みの導入には以下の3フェーズがあるような感じがしてきました。

  1. 自分一人で試す
  2. チームに提案する
  3. 少しずつ広める

それぞれのフェーズでコツがありますが、以下フェーズに絡めたり絡めなかったりしつつ心がけていることを紹介します。

変化は小さく、少しずつ

フェーズ問わず、今回変更しようとしている内容全体についてです。

開発運用ガチガチの組織にいきなりDevOpsじゃ、ansibleじゃ、と言っても無理ですよね。

wordとexcelでドキュメントを書いている組織にいきなり今時reSTで書いてCIでpdfにbuildするんじゃ!って言っても無理なわけです。

理想は小さく、少しずつ、段階を踏んで変えていきましょう。一番無理のないところから変えましょう。

まず、自分がやってみせる

1つめのフェーズです。

自分がやらないのに相手にやって、と言ってもなかなかやってもらえません。やり方を書いたとしても、です。

まず、自分が普段から使ってみる。それをチラチラと見せる。(笑) なんかあいつやってんなーという雰囲気を作るところからはじめます。

自分が十分に使って、うわーすごいいいー!という空気を見せてから、具体的導入のための説明をします。

現在の課題を共有する

ここからは2番目の提案について。

改善したいということは、現状何かしらの課題を抱えているはずです。

今はどういう状況で、理想はどういう状況、だからこうしませんか?ということを明らかにして提案しましょう。

メンバーにとって何が変わるのかを示す

今まではこうだったのが、こうなる。変更点だけをシンプルに示すこと。

誰しもが「自分がやってる普段の作業はどうなるの?」が気になるはずです。その不安を埋めましょう。

それをするとどううれしいの?を示す

エンジニアっぽいですよね(笑)

その改善/変更をすることでどううれしいの?ということを示すのが大事です。僕の自己満じゃなく、みんなにとってもうれしいことなんだよ、ということを説明することが重要です。

新人を使う

自分も使ってみせたし、チームに提案もした。それでも全員がやってくれるまでは時間がかかります。3番目のフェーズですね。そこで使えるのが新人さんです。(笑)

いやらしいんですが、新人さんというのは今までやってきたやり方というのを持っていないので、新しくこれでやってみない?と言っても受け入れられやすいです。そしてその感想を聞くこともできます。その新人さんに(悪いけど)実験台になってもらって、その後チームに展開するということができます。

今ちょうど新人さんを見てるのもありますが、インターン生がきたときに新しい仕組みを試して、(mattermost)これはいける、と確信してチームの本格活用に展開した、ということもありました。

完璧を求めない

いざチームで導入が決まっても、それができていないメンバーがいたとしても責めてはいけません。つまり、ルールにしてはいけません。みんなが(強制されてないけど)なんとなくやっていることを変えるんです。この積み重ねが文化を作ります。

頑なにやり方を変えないメンバーがいてもいいです。少しずつ、少しずつ仲間を増やしていきましょう。

おわりに

改善のための変化には三段階あり、まず自分がしれっと使い始めて、メンバーに使って見せて、なんとなく認識させるという、1番目のフェーズが個人的にはとても重要だと思います。この期間をじっくり取らずにはじめると詰まってしまうことが多い。

そのあと、実際にこのメンバーならいける、という確信が得られたら、メンバーが集まる会で提案します。提案するときは「現在の課題」「導入して何が変わるか」「導入して何がうれしいか」を説明しましょう。そこでいいですか?と聞いてダメですという組織だと諦めてください。うちの上司は絶対にダメと言いません。

導入後も継続的にできているかどうかはじっくりフォローしてください。また、完璧を求めないでください。

今後も、プロジェクト/チーム内の課題を、技術を使って解決していきたい。