公開日: 2024/04/23
最終更新: 2024/04/25
参考資料
- 2024.04 Tableauルノアール会登壇Viz(2019JTUG総会登壇より抜粋&一部改）
- 【あいまい回避】技術力とかいうよくわからんワードを分解する
- 技術力の構成要素2024年からWorkout WednesdayのCoachを任せて頂いたり、公開しているTableau実践問題集を本格化させ始めました。
過去にはMakeoverMondayやWorkoutWednesdayの参加ガイドを執筆しました。
また継続的にTableauやデータ可視化に関する様々なブログ記事を執筆してきました。
一貫して「Tableauの基礎知識を学んだ方々が、次のステップを踏み出すための手助けをする」ことを目的に活動してきましたが、このようなスキルアップが必要な理由について言語化をしていないことに気付き、この記事に書いてみようと思います。
端的には「これまでに学んだ内容で業務上の支障は無いと思っているが、それでもTableau技術力を伸ばす活動をするべきか」という問いに対する回答を考えます。
本記事の作成に当たり、Ganekoさん（@ritz_Tableau）の資料を大いに参考にさせて頂きました。
ぜひ合わせてご覧ください。
技術力を伸ばすことで目指すこと
自分の考えを最初に述べます。技術力が必要と考える理由は以下です。 「要件に対する最適な可視化を提供するために、自分が知っていて実装できて適切に使えることを広げ、また実際に最適な可視化に落とし込めるようにするため」
要は「提供価値を最大化するために技術力が必要だから」という簡単な理由です
単純化すると、下図の状態を達成することです。
注:「最適な可視化」という表現について
データ可視化は最適解を定義して目指すというよりは、その時々でより適切・より妥当なものを目指して作成していくものだと思います。したがって「最適」という言葉は強すぎるかもしれません。
ただし、簡単のためにこの言葉を採用します。
（また星マークで表現しましたが、実態は広がりを持つ雲のイメージが近いように思います）注: 提示された要件について
可視化を通して達成したい目標に対して、提示された要件が過剰である場合もあります。
その場合は要件を一緒に再検討し、結果的に、上図の「提示された要件」の内側に「最適な可視化」が置かれることがあります。
ただし、簡単のためにその場合は考慮しません。注: 時間軸について
簡単のために今回の議論には含めませんが、時間軸のイメージも大切かもしれません。
何らかの制約条件（時間などの資源）において可視化作成は進むため、無限に資源を書けた場合の最適解と、その制約条件における最適解は異なる場合があります。
また、一度に最適な可視化に近付けるというよりは、対話や試作の提供など、段階を踏んで近づくことが多い印象です。
この状態に自身を置くことが出来れば、以下を達成することができます。
提示された要件に対して、達成したい目的により合致した可視化を提案することができる。
知識や経験の引き出しから、上記の可視化を実現する方法を考案し実施することができる。
上記から、提示された要件を昇華させた「最適な可視化」を作成し提供することができる。
したがって、なぜ技術力が必要かという問いには「可視化の作成を通した価値提供を最大化するため、この状態が達成できる確率を上げる必要があるから」と答えます。
注：技術力以外の要素について
効果的な可視化作成にあたっては、実際には技術力だけでは十分ではなく、対象とする領域に関する知見など技術以外の要素が要求されます。
ただし本記事では技術力に焦点を当てるため、この点については満たされている前提として考慮しません。この状態をさらに理解するために、逆の場合を見てみましょう。
「最適な可視化」が「知っていて実装できること」の外側にあるとき
下図の状態を考えます。
この場合では、備えている技術力が不足していることにより、本質的に作成するべきだった可視化を作成できない場合です。
このような可視化は、以下のような問題を内包するかもしれません。
本質的なニーズを捉えられなかったので...
期待していた成果を可視化の利用から得られない。
徐々に利用されなくなってしまう。
必ずしも適切な設計で作られていないので...
表示パフォーマンスの問題がある。
適切な可視化表現ではない／分析設計ではないので、洞察を得にくい。
不必要に複雑な設計のため、運用上の困難がある。
ただし、このような作成物自体が無価値であったり、必ずしも価値が低いものではないことは言及しておきます。 最低限の要件を満たしていれば何らかの貢献は認められるかもしれませんし、可視化などが全く行われてこなかった文脈においては、どんな可視化であっても、それは大きな一歩かもしれません。
ただし、組織にデータ可視化が浸透するにつれて、要求される要件は多様化・高度化していきます。
そのような変化に対して技術力の成長が追いつかない場合は、上記で挙げた問題が顕在化し、最終的には組織のデータ可視化に関する体験を悪化させるかもしれません。
この状況を避けるためにも、技術力の（継続的な）向上が必要になると考えます。
技術力をどう定義するか
ここまで抽象的に「技術力」と言ってきましたが、Tableauやデータ可視化の文脈における「技術力」とは何でしょうか？
「技術力」は文脈や人により様々な定義がされる言葉ですが、ここでは簡単のため、以下の2軸で考えてみます。
高度な実装も可能にする、技術自体への知見
適切な方針を選択できる、使い方への知見
この2軸をこれまでの図に適用してみましょう。
この図を踏まえて、Tableauやデータ可視化の文脈における技術力を「十分な技術および使い方への知見を備えた状態で、適切な実装を選択することで、最適な可視化を作成する能力」と定義してみます。
実装方法に対する技術的知見だけが備わっていても、その技術の使われ方への理解が十分でない場合は、適切な実装が出来るとは限りません。
同様に、適切な方法を知っていても実現のための知見がなければ、それは価値提供に繋がりません。
また、知見があるだけでは不十分で「適切な実装に落とし込む」ことが重要です。
知見があるからという理由で、必要以上に高度な技術や使い方を選択する場合を考えます。
これは最適解に対して両方が過剰なので、不必要に複雑である、運用性に問題がある、などの課題を含むことが懸念されます。
また一般に高度なことは時間や工数を要するので、必要以上に時間を要し、そもそもの価値提供が遅れるかもしれません。
つまり、冒頭の技術力の定義「十分な技術および使い方への知見を備えた状態で、適切な実装を選択することで、最適な可視化を作成する能力」とは、前提として「知っていて実装出来て適切に使えること」が十分にある状態で、最適解を定義または発見し、そこに落とし込む能力と言い換えられるかもしれません。
下図は引力のメタファーを用いて「技術力」を図解した試みです。
自分の技術力を評価するために
ここまでの議論では1つの課題を前提にした技術力の定義を進めてきました。
ただし個々の課題に対して最適解は同一とは限らず、最適解やそれを実現するのに必要な技術力は、課題に対して相対的なものだと思います。
そして「技術力」という言葉は、個々の課題に対してというよりは、その人が持つ総合的な能力を指すことが多いと思います。
総合的な技術力を評価するためには、日々の課題に対して提供した可視化が、平均してどの程度最適だったかを評価する必要があります。
日々の課題に対して概ね最適解を出せているのであれば、総合的に見ても、業務上必要な技術力は備わっていると言えるように思います。
ところで「最適解だったか」を、どのように評価できるでしょうか。
もし本当の最適解が自分の知識や経験の外にあれば、それを自力で認知することは難しいです。
もし本当の最適解が「適切な実装を選択できる能力」の外側にある実装方法を取るべきだったのであれば、同様にそれを自力で認知することは難しいです。
「知らないことを知る」ことは大変難しいからです。
このような前提の中で、どのように自分の技術力を評価すれば良いでしょうか。
大きく2つの方法が考えられます。
類似の事例と比較する
フィードバックを貰う
類似の事例と比較する
類似の事例と比較するために、可視化事例やTableau Public等にある作品を調べます。 類似の課題に対しての可視化と自分が作成した可視化を比較し、同じような問題設定に対して大きく劣っていない、または優れている可視化が作成できているかを確認します。
ただし、可視化を評価できる程度の技術力がそもそも問われるため、この方法が実践できる程度の技術力が必要になります。
フィードバックを貰う
一方で、フィードバックを貰うことは誰にでも出来ます。
また複数名のフィードバックからは、様々な視点で調整された意見や評価を得ることが出来ます。
データ可視化の技術力が自分より高い方がいれば、その方にフィードバックを求めてみると良いと思います。
専門家としての評価や改善点を貰えますので、その内容を元に「どのくらい最適解に近そうだったか」を考えます。
またデータ可視化を提供した相手にもフィードバックを求めてみましょう。
この際はデータ可視化それ自体に対する評価ではなく、実際に使用してみた感想や、この可視化がどのように業務に貢献したかを聞いてみましょう。
その内容を元に「どのくらい最適解に近そうだったか」を考えます。
ここまでのまとめ
ここまでの内容を踏まえて、「これまでに学んだ内容で業務上の支障は無いと思っているが、それでもTableau技術力を伸ばす活動をするべきか」という問いには、自分は以下3点から回答します。
必要性：「要件に対する最適な可視化を提供するために、自分が知っていて実装できることを広げる」ために、技術力を伸ばす必要がある。
現状への評価：これまでに学んだ内容や実績から「課題に対して知識と経験が十分で、また適切な方法を概ね選択できている」ことへの自信や材料があれば、無理に技術力を伸ばす必要は無い。
将来への評価：また「組織へのデータ可視化浸透に伴う要件の多様化・高度化が生じても概ね対応できそう」だと判断する自信や材料があれば、同様に無理に技術力を伸ばす必要は無い。
解決したい課題に対して技術力が不十分だと感じる場合は、貢献度を上げる意味でも技術力を伸ばした方が良いと思います。
ただし、データ可視化は結局のところ何かを達成するための方法の一つなので、必ずしも無理に技術力を伸ばすものでも無いかなと思います。
また時間や熱量は大切な資源なので、他に学びたいもの／学ぶべきものがあれば、そちらに注ぐべきだと思います。
技術力の伸ばし方
最後に、Tableau技術力を伸ばすヒントについて少し述べます。
色々な可視化に触れるようにする。
TableauにはTableau Publicという素晴らしいプラットフォームがあります。ぜひ活用しましょう。
手を動かす。
色々なコミュニティプロジェクトや問題集を解いてみましょう。
気になったワークブックをダウンロードし、中身を見ながら再現してみましょう。
関連書籍を読む。
実装方法に関する本でもいいですし、データ分析の考え方の本でも良いと思います。
Tableauは有志ブログ等が揃っていますが、書籍など体系立てられた知識に触れることも技術力向上に役立ちます。
周辺領域にも手を伸ばしてみる。
プログラミングの学習からTableauやデータ可視化に応用できる内容が見つかることもあります。
デザインを学んでみても良いかもしれません。
一見すると全然関係なさそうな領域でも良いかもしれません。 興味ある分野を学んでいると、思わぬところで応用できるものが見つかるかもしれません。
最後に
「何で学ぶんだっけ」と聞かれた場合への思考実験から、自分の考えを何とか言語化してみました。
スキルアップを支援する一方で、その動機を考えるいい機会になりました。 また技術力を考えるうえで、冒頭に記載した参考資料を読むことも良い経験になりました。
「このような判断基準に置いて、必要だと思うなら頑張ってみれば良いのでは？」という控えめな結論で締めましたが、技術力を付けることによる社会的資本と金融資本への恩恵はあると思いますので、個人的には気持ちが向くなら積極的に技術力を付けても良いのでは、と思っています。
（端的には、技術力向上による人脈や存在感の向上、待遇の向上などです）
ただし今回の記事は自分の思考の言語化を試みたところが大きく、また自分も技術力を語れるほどの人間でもないので、今後も経験や体系知を通してアップデートしていく内容だと思います。
また今回の記事を書くにあたり何か書籍を参照したかったのですが、良さそうなものを見つけられずでした。オススメの書籍あればぜひ教えてください。
謝辞
Xで記事を共有しフィードバックや知見を求めたところ、大変有用な知見をいただきました。
4月23日に公開しましたが、議論を経て技術力への理解や考えが深まり、本文および図を大きく加筆修正しました。 ぜひ以下の返信欄もご覧ください。コミュニティの方々にとても感謝です。
特に「技術力の伸ばし方」項は、推薦いただいた以下書籍を読了した後に、ぜひ加筆してみたいと思います。
熟達論：人はいつまでも学び、成長できる
本記事の内容がTableauやデータ可視化を学ぶ／教える上での参考になれば幸いです。
質問などありましたら、XかLinkedinまでお願いします。