スタースキーマの勉強会で話してきた
データエンジニアが集まっているdatatech-jpとは
データエンジニアが集まってる datatech-jpという公開のslackがあるのですが、そこでは輪読会や勉強会が行われています。
僕自身、面白そうな勉強会は何度も参加させてもらっていますし、何より自分よりも経験の豊富なエンジニアの方々の議論を聞いてるだけでも勉強になります。
内容によっては議論に全然着いて行けなかったり、多少議論に参加できることもあるので、自分のレベル感を推し量る物差しにも利用しています。
上記の一環で #star-schema-the-complete-reference というチャンネルでスタースキーマの勉強会がありました。
内容としては、下記の輪読会ですね。
僕自身、データのモデリングに関しては当初全く知識が無く、何となくDWH、データマートを設計していました。
実際それで、運用コストの高いシステムを作ってしまった反省も経験してきました。
(僕が主に設計したとあるレポート作成回りのシステムは、2022年6月頭にリプレイスすることになって、一旦運用を停止しました。
この話は個人的には反省しかないので、機会があれば書きたい..)
スタースキーマの勉強会は最初、単純に聞き手として参加していました。
ただ、気になる章は誰も手を上げていなかったので立候補させてもらい、発表した、という経緯です。
実際に作成した資料
外部での輪読会の発表は、新卒の時に先輩に誘われてやった時以来でした！
僕が担当したのは18章の一番最後ですね
最後なので今までの章に関して理解してないと読み解けないのですが、実際のフローとしてどうやってモデリングしていくのか？を書いてる重要な章かなと思ってます
抽象的な概念が多く、結構読み解くのに苦労しましたし、いまだに腹落ちしてない部分もあります..
内容に関しては、上記を見てもらえたらと思いますので詳細は割愛します。
ディメンジョンとファクト部分のマッピングを行う部分とか、アンチパターンに関して色々記載があったのはとても勉強になりました。
そもそも論、スタースキーマは古の手法と言われるようになっています。
直近だと datatech-jpでも data-valutの勉強会も行っていますし、社内でもdbtを導入してdbtvalutを利用する等の検討を行ってる最中です。
ただ基礎的な概念として今回インプットすることができたのは非常にいい経験になりました。
あとNotionを初めて使ったのですが、めちゃくちゃ便利ツールだったので皆さんにお勧めしたい笑
Tableauの運用改善ダッシュボード作成
社内でTableauの利活用を推進していますが、なかなか活用が広まらない、という話はいろんな企業さんでも起きているんじゃないかと思います。
今回、運用改善の一環としてTableauのメタデータを利用したダッシュボードを作成してみました。
なぜこれらの課題に取り組んだのか、実際に作ったダッシュボードの紹介(個人情報が入るので隠しつつになりますが..)をして行ければと思います。
まずは社内でのTableau利用状況の紹介から
- Tableau Online
- Crater + Explorer 数十名ほど
- Viewer 100名以上
- Tableauを利用し始めて2年ほど
導入初期は小さく始めていたので、まずは社内の営業部門にのみ展開。
その後、営業部門でもダッシュボードの作成等ができるようスキルトランスファーを行ってから徐々に全社展開していました。
ですが、なかなかTableauの活用が進まない、というのが現状課題としてあります。
分析前の仮説・ヒアリング
営業側では部門間で多少違いはあるものの、Tableauの活用が進んでいました。
またその際に利用されているなと感じていたのが、業務オペレーションに組み込まれたTableauです。
Tableauの強みはアドホックに数値のドリルダウンができることにあります。
ただ、それは様々なデータが揃った状態が前提であることが多いです。
理想としては、データ活用が進んで売上などの定性的な結果に繋がっていることが望ましいですが、最初の効果として分かりやすいのは業務改善であることが多いと思います。
上記から、組織・部門間で定常的に使われているダッシュボードがある
→ 相対的にユーザーのアクション状況も高いのでは、と考えました。
ダッシュボードを使っていること自体もアクションなので、相関関係が近い値であることは注意が必要です。
Tableauのメタデータに関する前提知識
ある程度可視化・集計するものが決まったので、Tableauのメタデータを調べていきます。
データの中身が分かっていないと、思わぬデータ構造にはまって間違った結果を導いてしまいますので。
Admin Insightsのデータは90日間しか保持されない
Tableauのメタデータは、デフォルトだと直近90日しか保持されません。
一応回避方法はありますが、Tableau Prep Builder を導入してないなら実質APIを叩くしかないのが実情です。
ここら辺は課題感として感じてるので、先人の知恵を借りながら実装したい部分。
kb.tableau.com
メタデータに関する説明が無い
Google検索を掛けた限りだと、これらのメタデータに関する詳細な定義書のようなものは無いように見受けられます。(情報あれば頂けると嬉しいです。)
一応下記の説明はありますが..
TS Events (Tableau Server イベント) — ユーザーのサインイン、ビューへのアクセス、コンテンツのパブリッシュなどのイベントを示すマスター監査データソースです。
TS Users (Tableau Server ユーザー) — ユーザーアクティビティの集計情報。
カラム名やカーソルを合わせて表示される説明を読みながら、使いたいデータであるかを判断していました。
Tableau Onlineの場合、サイトのステータスでもデフォルトで作成済みの数値が確認できます。
ダッシュボード単位の閲覧状況や、ユーザーのアクション等ざっくりしたものは見ることが可能です。
今回、組織や部門単位でのTableauの利活用を確認したいを考えました。
Tableauにもユーザーの情報は含まれていますが、あくまでTableau上で設定したものに限定されます。
権限管理で、グループを組織単位で作成していれば一応やりたいことは可能です。
今回は社内の情シス部門の方と連携して、システムからユーザーの一覧及び部門のデータをスプレットシートでいただきました。
Tablaeuのメタデータをローカルに落とす
仮に部門ごとのTablaeu利用状況を出すには、LOD関数とデータブレンドを使うことが必要です。
TS events：Tablaeuの利用状況
スプレットシート：ユーザーの組織、部門情報
ただ、以下にある通り上記を組み合わせた処理は行うことができないです。
TS event等のデータをダウンロードするとhyper型になってるため、データソース上でのJOINの処理ができません。
よって、メタデータをローカルに落とします。
社内ではBigQueryを主に利用しているため、Tablaeuのメタデータと部門等を紐づけてテーブル化し、それをTableau上で参照することにしました。
部門別のアクセス状況の可視化
社員情報等が含まれているため、Tableau Pabulicには上げずスクショで紹介できればと思います。
・セットの利用
全社に展開済みと最初に記載しましたが、、まだまだ利用人数が少ない部門もあります。そこで、5名以上利用されている部門のセットを作りました。
・LOD関数を利用した平均アクションの集計
AVG({ FIXED [組織_部門_グループ], DATETRUNC('week', [Event_Date__local_]) : COUNTD([Event Id])} )
/ AVG({ FIXED [組織_部門_グループ],DATETRUNC('week', [Event_Date__local_]) : COUNTD([User Email])} )
部門によってTableau利用ユーザー数が違うので、週次のアクション数の合計を人数で割っています。(AVGの部分の集約関数は特段意味がなく、計算用に入れています。)
AVG({ EXCLUDE [組織_部門_グループ] : COUNTD([Event Id])} ) / AVG({ EXCLUDE [組織_部門_グループ] : COUNTD([User Email])} )
次にEXCLUDEを利用して、部門関係ない全体の平均アクション数を集計します。
これが折れ線グラフで出ている部分ですね。
一応、視覚的に分かりやすくするためにそれぞれの数値の大小を比較してます。
青：平均以下
オレンジ：平均以上
欲を言うと営業部門に数値が引きずられているので、部門ごとに平均値を変えられるようにアップデートしたい..
部門別ダッシュボード利用状況
業務オペレーションに組み込まれている、というのがどういう状態か？をまずは考えていました。
理想：平日は毎日利用されている
というのが理想だと思うのですが、毎日使わないオペレーションも多いと思います。
また、実際には部門別に人数も異なります。
そのため、ある日Aさんが使ったけど、Bさんが翌日利用した
→結果的に毎日使ってるように見える、ということもありえます。
そこで、以下の条件で集計を行ってみることにしました。
・週次でN週以上利用されている
・チームの所属人数以上利用されている
部署の情報等を見せることができないですが、以下のようなシートを作ってみました。
所属人数は別軸に出したかったのですが、総計と同時に利用することができませんでした。
そこで、参考地として赤枠部分に所属メンバーの人数を出しています。
部門別・週次アクション回数
{ FIXED [組織_部門_グループ], [Workbook Name]: COUNTD(DATETRUNC('week', [Event_Date__local_]))}
DataSaberを目指すものとしては、もうちょっといい感じにしたかったですが..
上記の集計方法だと、誰が使っているとかの中身等は考慮できていないので
あくまで業務オペレーションに組み込まれている可能性があるものを出すことができたと思うので、アンケート等を取って確認するなどに繋げていければと思ってます。
不要なデータソースの探索
社内ではTableau Onlineを利用しているので、データソースをパブリッシュすることが多いです。
抽出設定をしたデータソースは、100GBまでしかパブリッシュできないという上限があります。
そこで、データソースの容量やアクセス状況が分かるダッシュボードを作ることにしました。
一応デフォルトでも以下のダッシュボードはあるのですが、リンクで飛ぶことができれば良いと思ったのがきっかけです。
Hyper linkというデータに、該当データソースへのリンクが含まれてるのですが、これをアクションに埋め込もうとしたら、無効になってしまいました。
ただ、Item IDを確認したところHyper linkの末尾に埋め込まれているIDと一致していました。
そこで以下を設定することで、問題なくリンクを設定できました。
https://prod-apnortheast-a.online.tableau.com/#/site/会社のサイトID/explore/datasource/<Item ID>
終わりに
メタデータ活用はどんどん進めていきたい領域の一つですし、今回改めて触れることができたのは勉強としても良い機会になりました。
デフォルトで見れるものも良いとは思うのですが、個人的には細かい部分に手が届いてないと感じたところもありました。
会社の個人情報が含まれる都合上、なかなかTableau Publicにあげることが難しいデータになると思います。
(Googleで検索しても、探し方が悪いのかあまり他社事例が出てこなかった..)
他の方が挙げてる記事があれば教えていただけるだけでも助かります。
Tableauでのカレンダーの作成方法を理解する
Vizを作るためにTwitterで面白そうで勉強になりそうなダッシュボードを作ってる方はいないかと探していたところ、以下のtweetが難易度的にも良さそう、と考えました。
Tableau User Group - View Recordings from Past Events by Ethan Lang
課題感
- Tableauにおけるカレンダーの作成方法がいまいち分かっていない
- 前回に引き続き、表計算を理解したい
まずはカレンダーの作成方法を理解するために、先人の方が作ってくれたダッシュボードを眺めて、疑問点を調査していきます。
先人の方が作ってくれたもの(Janというシート)を残して、検証用にいろいろ作業を行っています。
- "”の意味が分からない
行と列に""というデータが存在している こういう場合は、手っ取り早く外してしまうと挙動を理解しやすいので、外してみます。
行と列の""を削除することで、日付の区切り線が失われる - 日付は不連続値を利用するよう注意する
元々はフィルターを利用して年月が一意になっていましたが、複数選択した際の挙動を検証しました。
最初、""になっていたものをINDEX()で検証しているのは、不連続値を利用したときに、INDEX()が増えるのかを検証したかったためです。
この際、日付を連続値として利用すると、INDEXが増えてしまいます。
ただ、この際の挙動がINDEXに慣れておらず理解できませんでした。
INDEXの割り振られ方検証
列の曜日に対して、2021年1,2月はINDEXが途中から振られています
2021年の1月の火曜日からINDEXが増えているのは、5～9日が、2020年1月の2週目に存在しているため。
同様に行に着目すると、2020年1月1～4日が存在しているため、2021年1月1～2日は、日付が被っています。
そのため、INDEXが増えた、という感じです。
そもそも論の話だと、曜日や週が不連続のデータを利用していることと、表計算を使いたいので日付データも不連続にする、というのが自然ですね。
実際にカレンダーを作成していく
ある程度、カレンダーの作成ロジックを理解したところで、サンプルスーパーストアのデータを利用して自分でも作ってみます。
今回は、前日分との利益比較カレンダーを作成してみました。
単純にカレンダーを作るだけだと面白くないので、日別で利益を表示する。
かつ、それが前日と比較して上がったのか下がったのか？をコンディションとして眺められるものを作ってみました。
(Tableauで重要視されている、Preattentive Attributes、という点を考慮すると、カレンダーでやらない方が良いのですが、今回は勉強用なのでご承知おきください)
前回の記事に引き続きですが、売上データでカレンダーを作ろうとすると売上自体が存在しない日付があります。
それをZNを利用して0埋めすることはできません。
そこで最後の方に宿題にしていた、データブレンドによる0埋めを検証してみました。
ちょっと色合いが微妙かもですが、日々の利益をカレンダーの内部に埋め込み、利益が無かった日付は0埋めできました。
カレンダーによくある機能だと、天気予報が挙げられると思います。
あまり使い慣れてないのもあったので、Tableauの形状を利用して前日との利益比較を行ってみました。
前日分との利益差分の集計
ZN(SUM([利益])) - LOOKUP(ZN(SUM([利益])), -1)
計算式書くより、差の集計を利用した方が楽かもしれません。
前日分利益差分±判定
IF [前日利益差分] >= 0 THEN 1
ELSEIF [前日利益差分] < 0 THEN -1
ELSE 0 END
後者の計算フィールドは、どの形状が、どのデータに当て嵌めるのか？に利用するので、1とかでなくても大丈夫です。
初日のみ、前日分との利益比較ができませんが、こんな感じのアウトプットができました。
最後に
データブレンド利用すれば、0埋めが一応できる、ということが分かってよかったです。
Tableauのビジュアルを綺麗にするために、""であったり、INDEXなどを利用しているものをちょくちょく見かけますが、どういう挙動なのか？を理解するきっかけになったと思います。
オシャレなVizを作られてる方々に一歩でも近づくために、どなたかの参考になれば幸いです。
参考記事
Tableauにおけるデータが存在しないこととNULLは異なる
Tablaeu DataSaberチャレンジ中
年始に建てた月1でブログを書く、ということが順調に達成できず既に4月も中旬です。笑
2022年2月から、Tablaeu Data Saberという資格を取るべく挑戦を進めています。
DataSaberとは何ぞや、という紹介をすると長くなってしまうので、詳しくは下記リンク等を参照ください。
資格と言っていますが、Tableau社が認めた公式の資格ではないです。
ですが、日本ではすでに700名以上のDataSaberがおり(2022年4月現在)、日々データドリブンな世界に向けて活動を進めています。
DataSaberに挑戦する過程で、課題を通してダッシュボードを作成したり、久しぶりにBIツールに向き合う日々が続いています。
その過程で、自分の理解が甘いけれどももうちょっと詳しく知りたい、という内容をブログにまとめることにしました。
課題感
表計算の挙動が良く分かっていない。
私自身はデータエンジニアとして活動をさせてもらっているため、SQLを書いたり、そもそも分析しにくいデータがあったら作ってしまえ、と思ってしまう派です。
また表計算に対するイメージとして、自分が必要としてるデータ構造になっていないから、それを補完するときに機能する、と考えていました。
アナリストが求めているデータを作る時間や工数が足りないときに、それが表計算で解消できるのであれば知っておいて損は無いです。
あり得るのか分かりませんが、表計算でカバーできる範囲を知っていることで細かくデータを作りすぎないことに役立つかも、という期待もあります。
では実際に、こういうことできないんだっけ？と感じたダッシュボードを出してみます。
https://public.tableau.com/app/profile/suga.toshifumi/viz/0_16496890547280/sheet8
Tableauのサンプルスーパーストアから期間を絞ったデータを利用しています。
折れ線グラフに対して、平均線が引かれています。
パッと見るとだまされてしまうのですが、4月14日週の売上は存在しないデータになっています。
やりたいこと
4月7日週・14日週・21日週の平均売上を集計したい。
4月7日週：27,206円
4月14日週：売上が発生していないため、データが欠損扱いになる
4月21日週：86,603円
という売上データが入ってるため、単純に平均すると(27206 + 86603)/2 = 56905円になってしまいます。
欠損値のデータを0埋めして、(27206 + 0 + 86603)/3 = 37936円をアウトプットにしたい、というのがゴールです。
結論
残念ながら、今回の事例は表計算で解消できないパターンでした。
調査・検証内容
そもそも論、表計算、という名前の通りクロス集計表に落とし込める必要があります。
最初に折れ線グラフで可視化しているのは、集計の集計を行うにあたってTableauの平均線、という機能が便利だったためです。
Tableauは問い合わせ内容が充実しているので、調べると結構出てきます。
今回であれば、以下のケースが近しいそうと思い試していきました。
まず、1と2番の例を一緒に試してみました。
ZNのみを利用すると、値が入りません。
PREVIOUS_VALUEとIFNULLを利用すると、2012年の最初のデータはZNの方も0が入るようになりました。
ただ、2013年4月14日週のデータは、IFNULLは前の週の値が入り、ZNの方は0が入っています。
PREVIOUS_VALUEに関しては単語の通りなので、分かりやすかもしれません。
前の行のこの計算の値を返します。
現在の行がパーティション内の最初の行の場合は指定された式を返します。
今回は以下のような計算式を利用しているので、2012年の売上は先頭だったので0が入った。
2013年4月14日週は、直前の週の売上が入った、という感じです。
ZNに関して
式が NULL でない場合は式を返し、それ以外は 0 を返します。
NULL 値の代わりにゼロ値を使用するには、この関数を使用してください。
なんかこの単語だけ見ると、エンジニアとかSQLに慣れてる人の方が引っかかりそうな気がしますね。笑
要は4月14日週の売上はNULLじゃないのか？という話です。
Tableauにおいて、データが存在しないこととNULLは異なります。
なのでZN関数のみを利用しても有効に働きませんでした。
PREVIOUS_VALUEを利用することで、データ枠が生まれました。
それによって、平均売上がNULLとして表現されたわけです。
結果、ZNを利用することで0埋めされた、という感じですね。
NULLが無いなら、作ってあげれば良いじゃない
という発想を抱いて、データブレンドを無理やりすれば行けるんじゃね？と思ったのが、きっかけです。
完全にアンチパターンですが、同じデータソースを読み込ませ日付週はプライマリーから、売上データはセカンダリーデータソースから計算してみました。
結果は、下記のように惨敗です。
一応TableauにもSQLと同じで処理順序があります。
ブレンドで行けるのでは？と思ったのも、結合が先に起きてAVGの集計が行われるためです。
同じデータソースを複製し、データブレンドしてもデータ枠が存在しないところはNULL値ではなく、データ枠が欠落されたままになります。
ちょっとここは自分の中でも腹落ちができていないのですが..
実はこの部分、Tableauのテクニカルサポートの方に質問しつつ、理解を深めていました。
サポートいただいた方には、この場も借りてお礼をさせていただきます。
恐らくFROM句側にデータが無いので、JOINさせてもデータが無いよ、ということだとは思います。
家電カテゴリの中では、2013年4月14日週の売上は発生していないので、日付データも存在してない、という理解です。
(であれば、カレンダーとなるテーブルが別にあれば、ブレンドで行けるのでは？と思ったりしてますが、検証できていないです)
最終的には、私がやりたかったケースは元データ自体を編集しないと解消できない、という返答をいただいてしまいました。
ただ、データが存在しない= NULLという発想になりがちな中で、両者の違いを感じられたことは良い経験になりました。
THECLUTURE CODE 最強のチームを作る方法を読んで、エンジニア以前に人間であることを再認識した
今年は1か月に1回ブログを書くと宣言して、既に2月が終わりそうで焦ってます。笑
少し前に続きチームビルディングが自分の中でも課題だったので、タイトルに挙げたこちらの本を読んでみました。
個人的に抱いている課題感を解消するために、何をしていけば良いのか、という視点で参考になる話が多かったのでまとめてみたいと思います。
個人的に抱いていた課題感
目指しの共有ができておらず、議論が活性化しにくい
今期、社内では新しい全社データ基盤を構築するために、大掛かりな引っ越し作業を予定しています。
その上で、まずは引っ越し作業を完遂するために何をするのか？
どういうスケジュールで何をやっていけば良いのか？
等を僕の方で洗い出してみました。
今振り返ってみると、タスクの洗い出しは、チームで議論しながらできれば良かったと思ってます。
しかしながら、チームとして目指しやゴールの共有がふんわりしていました。
(そもそも論、僕自身がそういった内容を共有する、という意識が甘かった)
そのため、一旦タスクとか洗い出して目指しを共有すれば良いかなー、と軽く考えていました。
先週の金曜日に目指しを共有したのですが、順番が逆だったかも、と反省してます。
漠然とした理想像
お互いが目標に向かって、課題を出しあって議論したり、メンバー間で方向を決められる状態を作ること、が漠然とした理想像です。
今の僕はポジションとしてそういう立場にいる訳ではないですが、リーダーという立場を意識せずに仕事をしたいなと思っています。
そのためには、チームメンバーが互いに自走して、考えて、議論して、、という状態を作ることが必要です。
(こうやって書くと受動的な働き方をする人ばかりなのか？という話も出てくると思いますが、現在のチームはむしろ積極的に動いてくれる人の方が多く、頼りになる方が多いです。)
誤解を恐れずに書くと、Howの話は活発に議論するが、As is to beの話はメンバー間ではあまりしない、という感じです。
そもそも論、僕自身メンバーだった際はそうだったなと思い返していて、リーダー的な立場になった途端、こういうことが気になりだしています。。
本の中で良かったところを2点まとめてみます
圧倒的な具体例の多さ
良いチーム、ダメなチーム、ダメだったチームが改善されていくプロセス、世の中の実験を通して読者の予想を裏切ると同時に、なぜこれが上手くいったのか？を言語化してくれる質が圧倒的に高い本だと思います。
印象的なものが多すぎたのですが、そのうち一部を抜粋してみます。
イントロ部分で紹介されていた、スパゲッティとマシュマロを繋げて高い塔を作る実験です。(結構有名な話らしいので、知っている方も多いかもしれない)
ビジネススクール、弁護士、CEOチーム、幼稚園児のグループといった、様々なチームの人が集まった。
この中で優勝したのはどこか？というイントロから始まります。
こういった書き方をすると、結果が予想できてしまうかもしれませんが、優勝したのは幼稚園児チームでした！
なぜ幼稚園児チームが優勝したのか？
他のチームだと、リーダーは誰だ？とかアイディアを批判しても大丈夫か？という「ステータス・マネジメント」の状態になり、余計なことを考えていて非効率です。
幼稚園児チームは、「チーム内の立ち位置」などを気にせず、対等に目の前の課題解決に没頭している。
そのため、リスクを取って挑戦し、失敗から学び、効率的な解決策を見つけられた、という話です。
もちろん、実際の業務は幼稚園児に解決できるような問題ではないだろう、と思われる方もいらっしゃると思います。
ただ、上手くいっているチームは根本的には上記と同じスキルを使っていることが本書では解説されています。
特別なスキルは基本的には必要ない
この本で何度も言及されているのが、強いチームを作るために何か特別な能力は必要ない、という話です。
若干補足すると僕自身はエンジニアなので、課題を解決する際に技術力が足りない、という問題は起こりえると思っています。
その上でエンジニアとしての技術力と、チームとしての力は別物、という前提で話をしていきます。
(むしろチーム開発を行っていく過程で、チームビルディングが重要だと思っているから、この本を読んでいます。)
スキルは大きく3つに分けられる
安全な環境づくり
他のチームビルディング本でも出てきましたが、心理的安全の話がここでも出てきていました。
弱さを見せる
これも心理的安全を生み出し、信頼関係を気付くのに大切な要素として挙げられています。
共通の目標を持つ
物語が共通の価値観や目標を生む仕組み
意思決定のヒューリスティクス
共通の目標を持つ、という部分で具体例として挙げられている粘菌の話をしたいと思います。(僕がもともと理系で生物学が大好きだったのもあります。笑)
粘菌は単細胞生物の集合体ですが、子孫を増やす際は面白い活動を行います。
1. アメーバたちが1つの有機体として活動を始め、中央に集まってくる
2. 一部のアメーバが、上に向かって移動し植物の茎のようなものを形成する
3. 他のアメーバが茎を上り、頂上に着くと胞子に変わる
4. 風に乗って飛んでいき、子孫を増やす
この背景に指示を出す役割の細胞がいると考えられていましたが、実際はそのような細胞は存在しません。
ここで出てくるのがヒューリスティクスです。(かならずしも合理的な根拠がある訳ではないが、多くの人が経験的に有効だと信じている知識)
ヒトは複雑な有機体なので意思決定のプロセスも複雑だと考えがちですが、実際にはシンプルな経験則から判断しています。
そこでチームとしての目標を共有し、大切な態度を言葉で共有しあうことで、多少ルールベースで行動ができるようになる、という手法が紹介されていました。
そんなに機械的にルールで網羅できるのか？という考えもあると思います。
もちろん、キャッチフレーズを暗唱することは目的ではありません。
挑戦や失敗を通して反省し、その学習を通して生まれた「ルール」だからこそ、重みが生まれてきます。
またこれは、習熟が必要な分野においては意味があることも記載されていました。
同じ仕事を高い質を保って繰り返すものは、理想の姿がはっきりしているため、標語化しやすいです。
では、創造的な仕事ではどうするのか？という視点では、チームの自主性を認める、というか書き方に留まっていたのが残念でした。
ただ、これはルール化しにくい、という点では仕方ないのかもしれません。
じゃあどうやったら自主的な活動がし易いか？という視点で、相手の心理を想像しながら仕事をして行ければと思います。
挙げられていたものでは、以下のようなものですね。
・チーム構成や力関係に注意を払うこと
・失敗を恐れない環境を作り、FBを与える
・自主的な行動・挑戦を盛大に祝う
長々と書きましたが、本当に何か特別なスキルが必要か？と言われるとそうではないものばかりです。
終わりに
この本を読んでいると、エンジニアとか社会人とか、そもそもそれ以前に僕たちは人間なんだ、ということを改めて感じさせてくれた本だな、と感じました。
エンジニアとして技術力をつけたい、良いプロダクトを届けたい...
そのためには○○をやらなきゃ、△△も進めないと.. みたいな気持ちになりがちで、歳を重ねるごとにドライになっていく自分がいることを感じさせました。
日々、内省はしていますがコミュニケーションに悩む機会がこれ以上に増えそうです。。笑
心理的安全や弱さを見せる、の部分で触れられているのは圧倒的にコミュニケーションに関してなので。
コロナで在宅ワークが一般的になった今、会議では画面オフになることが多くなりました。(女性はもちろん、化粧が面倒、というのもあると思います。)
その流れに違わず、チーム内も基本画面オフで会議をすることがほとんどです。
この本を読んでから、とりあえず僕は顔を出すことにしてます。
喋る側は画面が真っ暗だと結構不安になるものですが、少なくともメンバーが話している際に僕の顔が見て多少安心感を覚えてもらえば良いかな、という感じです。
別にこれを強要することは難しいと思いますし、変えるつもりもありません。
問題意識を抱いて、変わっていくプロセスを大切にして行ければと思いますし、そもそも論自分が話しすぎることが問題かもなので..
今までの自分からすると、全然やってこなかったことがほとんどなので、意識的に行動を変えていければと思います。
チームビルディングの仮説検証を行って、上手くいったこと、行かなかったことがあれば、機会を見つけてブログに投稿したいですね。
