上記の取り組みはあくまでも第一歩として少数の有志メンバーが実施したものです。本当に難しいのは、そして本当に重要なのは、「いかに組織全体に浸透させるか」です。筆者の現場では、組織に文化を定着させるために「メッセージング」「体験イベント」「プロセス装着」そして「成功体験の共有」を行いました。
まずはメッセージングです。目指す方向性を提示することから始めました。あの手この手で「データ分析をやろう」という空気、文化を醸成しました。以下は一例です。
次は、体験イベントです。“モブプログラミング”もとい“モブデータ分析”を実施しました。1つのモニターを囲んで全員で一緒にデータを分析します。Measure(施策の効果測定)に慣れた有志メンバーが、他のメンバーを巻き込む形で実施しました。
1人が手を動かしている間に、周囲のメンバーが調べたりアドバイスしたりしながら進めることで、挫折を防いだり、Tipsやコツを共有し合ったりすることができます。
「皆がやるなら自分もやるか」ということで参加の背中を押す効果もありました。参加者からは「やってみたら、予想していたよりも良かった」という感想が寄せられました。やったことがないから不安なのであって、実際に手を動かして体験することで物事の見え方が変わることもあります。
そしてプロセス装着です。分析要件定義やMeasure(効果測定)を開発工程に明示的に組み込みました。
意識するだけでできるようになるわけではありません。思い付いたときにやるだけでは定着しません。データ分析を業務の一部として仕組み化することが、組織への定着となります。メッセージングや体験イベントは、プロセス装着のための準備だといえるでしょう。
「プロセスを変えられるかどうか」はエンジニアチームの地力が問われます。もともとの開発業務(Build)が安定して、普段から継続的にプロセス改善ができているならば、開発工程を1つ増やしても、チームとして適応できるはずです。反対に、まだチームが十分に進化していないのであれば、データ活用の前にやるべきことがあるのかもしれません。
最後に成功体験の共有です。うまくいったことをたたえて、組織全体に方向性を示します。「うまくいったから次もチャレンジしていこう」という認識を醸成するのです。小さな成功を積み重ねて、少しずつ歩みを進めていくことで、結果的に「文化」と呼ばれるものができるのではないでしょうか。
今回の取り組みの分かりやすい成果としては、アジリティの向上が挙げられます。データ仕様に詳しい(少なくとも調査するスキルは持っている)エンジニアが担当領域を広げることで、前後工程のリードタイムを大幅に短縮できたのです。
製品開発を担当するエンジニアはその場でデータ仕様を調べることができます。「メインモニターではJupyter Notebookを開いてデータを分析し、サイドモニターではプロダクトのソースコードを読み解く」といった具合です。筆者の担当現場では、データサイエンス部門に依頼していた分析をエンジニアが行い、仕様ヒアリングや手待ち時間を削減することで、分析を当日中に完結できるようになりました。
※誤解を招かないように補足すると、より高度で複雑な分析はデータサイエンティストが担い、そうでない簡易な分析は製品開発の現場で各担当者が実施するのが望ましいと筆者は考えています。
Copyright © ITmedia, Inc. All Rights Reserved.