2024-01-08

人生初の要件定義で感じたあれこれ

はじめに

人生で初めてERPの刷新プロジェクトにアサインされました。プロジェクト自体はまだまだ序盤で要件定義が終わったばかりなのですが、プロジェクトが進んでいくにつれて感じたもやもやとこういう感覚が必要ではないのかと思ったことがあるので、そちらを備忘録という意味も込めてつらつらと記述していこうと思います。

私の現在地

私はこの職場での経験は2年間で、主にデータ基盤の構築などデータ分析の推進を担当してきました。つまり、会社の基幹的な業務、特に今回刷新する会計システム周りの業務に関してはほとんど無知な状態です。ついでに会計的な知識も全くなく、ミーティングで飛び交う用語ですら理解が怪しいレベルです。必要な知識って突然求められますよね。

私に必要だったこと

業務理解

業務の理解が足りてませんでした。ほかのメンバーがベテランであり、業務経験が浅い（特に会計領域）私には多くは求められていないことはPMから伝えられていたのですが、やはりどんな小さいシーンの一つとっても会話する内容の解像度がほかのメンバーと比べて低いです。ミーティングの中で分からない業務が出てきた時にはどういうシーンがあって、どの項目に話をしていたのかを調査・質問することにしていました。理解できたことは多くあったのですが、逆にわからないことが多すぎていくら時間が足りなかったです。

質問力

他メンバーへの質問が足りなかったと上司から指摘されました。私はこのPJの中では一番若手でシステムをよくすることよりも多くのことを吸収することを期待されていました。私の疑問を解消するサイクルは

わからないことを明示的に書き出す
自分なりの方法で調査をする
調査した内容を検証する
それでもわからないことを質問する

以上のサイクルを質問までの道のりとして課していました。しかし、自分なりの方法で調査するところから時間を浪費してしまいました。もちろん自分なりの方法なので時間もかかる上に不十分なことが多いこともありました。多くの疑問が浮かぶ中でこのサイクルで疑問を解消していくことは不可能に近いことでした。足りなかったこととして質問力と書きましたが、私に足りなかったことは質問力ではなく検証力だったのかもしれません。そこに気が付いた時からは2の段階から積極的に質問することでサイクルを回していけるようになりました。

やってて無駄だったなって思ったこと

空中戦の展開

空中戦と書きましたが、これはメモやたたき台が全くない状態で会議を進行することを指しています。ユーザー部門から業務内容のヒアリングをおこなう際にユーザー部門の方が主体で話すシーンが多くありました。このときユーザー部門の方は呼ばれただけなのでなにも用意することはなく白紙の状態で話し始めることがありました。こうなると多くの時間を浪費します。

聞いている側は正しくキャッチアップできているのか不明
周囲の理解は完全に置いてきぼり
思い付きで話す人もいるので業務の構造的な理解が困難
後に認識の齟齬が発生しやすい

特に会計などの複雑な話になるときは空中戦のパターンは避けなければなりません。時間をかけた割には決まったことや共有できたことが少ないという事態に陥ってしまいます。どんなに簡単でもいいので自分がなにかを話し始めるときはたたき台になるようなものを用意しようと思いました。聞く側の認知負荷をなるべく下げ、積極的な議論になるような場を作ることが重要だと感じました。

要望の要求

要件を定義している場で要望の要求を聞く回になってしまったことがありました。要望を聞いている中でも現状の業務との比較が出ているので、問題はないシーンもありました。しかし、要望をまとめる回は別に用意されているため、要望を収集する回と要件をまとめる会で別々におこなったほうが議論がクリアになるのではないかと思いました。

まとめ

今回初めて要件定義を経験した私が感じたことをつらつらと書いていきました。要件定義では我々IT部門がベンダーとユーザー部門を繋ぐ役割が重要であると感じました。ベンダーさんは会議の準備をしてくれますが、ユーザー部門は呼ばれただけでお客さん気分で来る方が多かったです。呼ばれただけの会議で結構ハードな質問責めにあって準備不足であるシーンもありました。問題は他にもあったような気がしましたが、いま思いつく限りでは以上のようなことになります。やはり感じたことは何かしらの記録にとっておくことが重要ですね。今後PJは基本設計、開発、データ移行、テスト、本番稼働と進んでいきます。その中で感じたことがあればまたこのような形でまとめて記録として取っていきたいと思います。システム刷新のいい経験になるように頑張ります。

2023-12-11

PythonでCSVデータを扱うために必要な操作

はじめに

日本で働く多くの人はExcelやCSVファイルを扱うことが多いのではないでしょうか。私もデータを扱うときの多くはCSVファイルを介してデータベース（DB）に放り込んだりすることが多いです。データ基盤で扱うデータはDBから直接取りに行ってBIツールで編集なんてことがありますが、その環境が整っていない場合はシステムからCSVファイルを出力、そのファイルとExcelで編集して分析することが多いのではないでしょうか。しかし、それを続けることによって以下の弊害が生じることがあります。

分析の結果は出るが途中で何をやっているのか分からなくなる（ブラックボックス化）
データが溜まりExcelが鬼のように重い（最悪PCの再起動が必要になる）
分析をおこなうまでのExcelでの編集が大変

などなど、これらの問題に直面しているExcel戦士の方も多いのではないでしょうか。現に私の職場でも多くのExcel戦士がいます。今回の記事は簡単な処理にPythonを利用して、少しだけでもそのExcel戦士たちの手助けになればいいと思っています。簡単な処理の繰り返し、行列の挿入・削除、データの変換などありがちな操作を簡易化して記述します。

注意

ここでPythonを利用してデータ変換をおこないますが、業務などで利用する際は必ずIT部門の指示にしたがってください。野良マクロならぬ、野良Pythonを増やすことはおすすめしません。

データの編集での困りごと

データ分析ができる状態にするまでかなりの手数かつ量をこなす必要が出ると思わず、やりたくないとつぶやいてしまいます。

繰り返しの処理
商品コードやIDなどの変換
打ち間違いの発見

これらの作業を100行、10個のファイルを人力でとなると結構しんどいです。これ月次でおこなうなんて考えるなんてもってのほかです。これらを自動化できれば楽なのですが、完全に自動化するにはやはりプロの手が必要になります。完全にではなくても半自動化まで自分の手でできれば楽になります。

いざ、データの操作

import pandas as pd

データを扱う上で必要なモジュールをimportします。各ドキュメントを置いておきます。ここではpandasを使用します。

pandas : https://pandas.pydata.org/docs/
IO tool : https://pandas.pydata.org/docs/user_guide/io.html#io

処理

ファイルを読み込む

.read_csv()を使用して、CSVファイルを読み込みます。

ドキュメント：https://pandas.pydata.org/docs/reference/api/pandas.read_csv.html#pandas-read-csv

df = pd.read_csv('C:\\Users\\User_name\\folder_name\\file_name.csv')
df.head()

よくハマるのが（）内のファイルの指定です。雑な回避策ですが、\のところを\にしてエスケープしておくと大体解決できます。1行目でデータフレーム（df）の読み込み、2行目で読み込んだdfを表示しています。2行目はあってもなくてもどちらでも問題ありません。

商品ID	商品名	価格	在庫数
001	キーボード	10000	50
002	マウス	5000	30
003	モニター	20000	20
004	ノートパソコン	80000	10
005	スマートフォン	60000	40

上記のテーブルを例にデータを操作していきます。

データを指定する

at, iat, loc, ilocを使用します。

at, locでの分類
- at, iat：単独の要素を指定
- loc, iloc：複数の要素を指定
iでの分類
- at, loc：行名、列名で指定
- iat, iloc：行番号、列番号で指定

私は基本的にilocを利用します。理由は以下の通りです。

forを利用するときに番号で指定する。
データソースの列名が変更になっている可能性があるため、列名ではなく番号で指定する。
要素を複数または単数で指定できるのでlocを使用している。

#1列目を指定する
df_iloc = df.iloc[1]
print(df_iloc)

商品ID	商品名	価格	在庫数
002	マウス	5000	30

以上の結果がdf_ilocに指定されます。at, locを使用して自分のイメージ通りにデータを指定できるようになればpandasでのデータ編集も慣れてくると思います。

以下、参考使用です。公式ドキュメントではありませんがいつも参考にしているサイトです。記事中に公式ドキュメントのリンクもあるのでそちらも参照してください。

note.nkmk.me：https://note.nkmk.me/python-pandas-at-iat-loc-iloc/

for, ifとの組み合わせ

上記のコードでデータを指定したところで、だから何だというのか私の正直な感想です。ここからfor文などと組み合わせていきます。行数を取得してその行数分の指定の列のデータを取得します。

row = len(df)
col = 1
for i in range(row):
    df_iloc = df.iloc[i, col]
    print(df_iloc)

row：行数
dfの長さを取っています。これでデータ列数が変わっても列数分だけ処理を実行することができます。
col：列数
ここでは1を指定していますが、ここも目的に沿って指定してください。

商品名
キーボード
マウス
モニター
ノートパソコン
スマートフォン

あとはfor文の繰り返し数や処理の内容を変更したりすることで自由な処理を記述できます。指定のデータのみを編集したいなどがあればif文で条件を指定します。ここまでイメージできればかなり自由に感じないでしょうか。

データを編集する

データの編集は簡単です。locなどでデータを指定してあげてそこに代入する値を与えてあげます。

df.iloc[1] = 0
print(df)

商品ID	商品名	価格	在庫数
001	キーボード	10000	50
0	0	0	0
003	モニター	20000	20
004	ノートパソコン	80000	10
005	スマートフォン	60000	40

ilocで指定した1行目の値が全て0になりました。先ほどのfor文の中身をこのデータを編集する処理に変更すれば一括でデータを編集することができます。さらにif文で条件指定して指定したデータのみを一括で変更することができます。だんだんなんでもできるような気がしてきませんか。このように条件と繰り返しと処理で自分のやりたい操作を表現していきます。

あとは応用の世界

これらの方法でデータを扱うことができれば、次のステップは自分のデータと向かい合ってどのような処理が必要になるのかを考えるだけです。だけと言いつつも、この点が一番難しく（想定外の動きをしたり、自分のロジックが間違っていたり）、一番面白いところであると私は思います。データの動きとプログラムの振る舞いに向き合う時間が好きです。

あとがき

ここでは一部の簡単な処理を紹介しましたが、私が初めの頃に悩んだ点を思い出しました。こういう記事で紹介されている処理をどのような環境で実行するのか、すぐに結果がわかるような環境がほしかったことがあります。いつかそんなことを書いていこかなと思います。

2023-11-17

【ThinkPad】ハードウェアの使い心地を考える

こんなことがあった

ある日、こんなエントリを見つけました。

おかえりThinkPad

ThinkPad → macbook → ThinkPadの変還をマシンに対する愛情たっぷりにか書かれています。自分もここまでのこだわりをもってマシンなどのデバイスを選んでいきたいと思うと同時に同じような題材で自分も文章を書いてみようと思い、この文章を書いています。

HHKB Studioの発売

あとはHHKB Studioが発表されて、飛ぶ鳥を落とす勢いで売れている（ように見えます）。私自身、HHKB professional HYBRID Type-Sを利用していますが、HHKBファンとしては気になる一品です。気になる点としては、、、

話題のポインティングスティック
後述で紹介しますが、私は仕事用のマシンとしてThinkPadを使用しておりトラックポイントを使用しているため、気にならざるを得ません。
ジェスチャーパッド
Xで話題になっていたのは上記のポインティングスティックでしたが、個人的にはこちらのジャスチャーパッドのほうが気になっています。キーボードから手を離す理由は画面のスクロールやカーソルを一気に飛ばしたいときになるので、それらのときにジェスチャーパッドで解決できるのではないかと期待しています。

現在の利用ガジェットの紹介

Surface Laptop2
一人暮らしのときにプログラミングを始めようと思い立って買ったPCがこちらです。現在も現役でこのブログやプライベート的な作業も全て担ってくれる優れものです。
ThinkPad X1 Carbon 7Gen
仕事用のPCです。元々は役員が使用していたものですが、バッテリーの不具合から2年ほど使われなくなったものをサルベージしました。最新のBIOSアップデートをして、電源の抜き差しをして完全に復活しました。仕事だと重い処理あるけど頑張ろうな。
HHKB
一念発起して買ったキーボードです。在宅勤務の大きな味方です。さすがに仕事場にもっていくのは気が引けるので在宅勤務のときのみ活躍してもらっています。
Logicool トラックボールマウス
書くほどでもないかと思いましたが、面白い体験だったのでここに記述します。最初は慣れない感覚がありましたが、3日も使って慣れました。通常のマウスと比べて場所を取らないのがいいです。

使ってて良い点

使用しているガジェットのお気に入りのところを書いていきます。

ThinkPadいいよね！

トラックポイント
 ThinkPadと言ったらこれ！みたいなところがありますが、まだまだ慣れません。ふとした時に使ってみようと思い使うのですが、やっぱりトラックパッドのほうがいい。カーソルの移動もページのスクロールもジェスチャータップもあるし不便さをあまり感じません。トラックポイントは遊び心という点でとても好きです。
ディスプレイ
色調が他のPCと比較して抜群に綺麗、鮮やかです。電源を入れてパッと出る赤色のLenovoのロゴのところから綺麗です。難点として外部のディスプレイに繋いだ時に外部ディスプレイの淡さに違和感を感じてしまいます。
キーボード
深いタッチとしっかりとした押し心地はクセになります。他のPCのペシャペシャしたタッチにはもう戻れません。あと音が静かです。ThinkPadの外付けキーボードが売っているようですが、まじで買おうか悩むところです。
サイズ感と重量
13インチのものを使ってますが、持ち運びも何も苦労はありません。ここ1か月くらい出張の機会がありました。そこでもThinkPad大活躍です。15インチPCだと多分耐えられなかったと思います。サイズ感とは別の話ですが、出先でパワーサプライを忘れたことに気が付いたのですが、給電ポートがUSB Type-Cなので何とかなりました。こういう汎用的なところも魅力的です。

Surface Laptopもいいよね！

4:3ディスプレイ
なんといってもSurfaceシリーズのいいところ！画面の見やすさが段違いです。調べてみると少し昔のPCなどの採用されていたアスペクト比とのことです。
キーボード
文句はないのですが、強いて言えば押下圧が重いです。重いためSurfaceを使用するときには打ち損じからのタイポが多くなります。
アルカンターラ素材
公式のページでは高級感を出すための素材と書いてありますが、こちらも経年での汚れが気になってきました。あえて汚れそうな素材を使わなくていいのではないかというのが感想です。アルカンターラは一部のSurfaceのみで、他のものはメタル仕上げとの記載があります。そうすると次は重量が気になってくるところです。
光沢のディスプレイはちょっと残念
個人的にノングレア液晶のほうが好きなのでここもちょっと残念な部分です（書いてて気が付きましたが惜しいところが多い）。ディスプレイもカスタマイズで選べればいいのにと思います。

もろもろ使っててヤバイところ

ヤバイというか設定次第で何とかなるのですが、惰性で使ってしまっているので何とかしたいなと思っている点です。

ShiftキーとCtrlキーの位置
使用している全てのデバイスでShiftキーとCtrlキーの位置が違います。
- Surface Laptop
  上からShift、Ctrl、右にいってFn（これが普通）
- ThinkPad
  上からShift、Fn（なぜ）、右に行ってCtrl
- HHKB
  上からCtrl、Shift、Fn（これはこの配列に魅力を感じた）

このように使用してる全てのデバイスで各々キーの位置が違うので混乱することがしばしばです。特にThickPadは設定でなんとかできるのですが、そのまま使ってきているので慣れつつあります。デバイスが増えるとこういうこともあるんですね。

今後なにを使いたいよ？

このエントリをつらつらと書きながら、調べながらで思ったことは次はThinkPad一択かなと思っています。ThinkPadの購入画面までいったことがある人はわかると思いますが、柔軟なカスタマイズで自分だけのPC感がやはり魅力的です。Surface Laptopに不満があるわけではないのですが~~上記で惜しいとかいいつつ~~、ThinkPadを買ってみたいという点に尽きるでしょうか。今回は分かりやすくPCの買う動機になる点や使ってみてわかる特徴を書いています。皆さんがPCを選ぶきっかけになるといいと思っています。PCの購入話になると必ず出てくるのがスペックについての話があると思いますが、今回は割愛しました。CPUやメモリやグラボなどありますが、ノートPCを個人用で買う人に取っては通常のスペックのもの（一番売っていて汎用的なもの）を買っておけば特に問題ないのかなと思っています。見た目で購入を決定することもいいんじゃないのかなと思いました。

おまけ

私は非IT企業の情報システム部にいるのですが、社内では基本的にはOSはWindows、アカウントの管理もMicrosoft Entra ID（最近名前変わりましたね）を利用しています。一部のユーザーからマックを使いたいという声を聞くのですが、なぜ？？？？？と思ってしまいます。普段の業務ではExcel、Word、パワポくらいしか使っていないのに？？それがキーノートとかに変わるだけのような気がしています。もちろんIT企業なら開発したり、様々なソフトを使ったりする場合は用途によって選択の自由があっても良いと思います。非IT企業でマックにして何がしてみたいのか今度聞いてみようかな（地雷）。と言ってる私はWindowsユーザーなのでマックのいいところがあったら教えてください。

2023-10-21

ハッピーハックキーボードを買った（自分の身の丈にはあっていないものを買うということ）。

2022年1月26日のできごと

先日、ずっと前から購入を検討していたハッピーハックキーボード（HHKB）を買いました。しかも、Professional HYBRID Type-S。タイピングはそんなに早くもないし、ガリガリコードを書くようなこともしたことはありません。そんな私のような若輩者が買うには高級すぎる代物です。今もこの文章をタイポしまくりながら打っています。

購入にはかなり悩みました。日本語配列か、英語配列か、本当にType-Sが必要なのか、いやその前に本当に自分が欲しいと思っているのだろうか。買ってもそんなに使わないのではないか。様々の不安と葛藤と戦いつつ、もやもやとした日々を過ごしていました。アマゾンの履歴を見るたび思い出し、Twitterの広告で流れてくるたびにもやもやしていました。

何かを買うときに後押ししてくれること

高価なものを購入するときは誰だって悩みます。しかしインターネットを見ていると買い物に対するいろんな人の考えに触れることがあり、

「お金は紙だから、どんどん使って経験にしていきたい」
「まだ20代だぞ、破産するほど好きなもの買って好きなだけ使え」
「お金はなんにでもかけがえのあるものだから、それをたくさん使ってかけがえのないものを育てていきたい」

出典は忘れ、正確な表現ではないけれども、様々な立場の人が様々なことを言っていました。

これらの言葉から購入にする勇気をもらいました。おかげさまで購入を決める前はどのタイプを買うのか悩むのは楽しくありませんでしたが、購入することを決めてから悩むことも楽しくなりました。

そこからYoutubeでレビューの動画を見漁り、ほかのタイプも検討したがやはり一番魅力的だったProfessional HYBRID Type-Sを選びました。これが悩むことから考えることに変わった瞬間であると実感しました。「悩む人ではなく考える人になれ」という言葉を聞いたことがあります（これも出典を忘れてしまって申し訳ない）。まさに今回のことだと思いました。

まとめ

今回の記事もHHKBで何か書きたいと思って衝動的に書いているものです。職場のキーボードでタイプするより何倍も打ち心地が良いです。ぼーっとしたときにHHKBでタイピングしたいなと思いだすほどです。

今はHHKBを使いこなしていないが、まずは好きになることはできたと思います。まだ身の丈にはあっていないものを買ってしまったという実感はしています。しかし、身の丈に合っていようがいまいが、誰かが見ているわけでもないし、自分の身の丈を合わせていくように頑張るという決意の象徴としても使っていくと考えればよい買い物になったと確信しています。

あれから1年半（現在）

実は上記は昔のブログからの移植です。何を書こうかなと考えた時にまずは書きためている記事を移植しようとして、一部再編成した記事を書きました。改めて読み返すとなんだか恥ずかしいです。

手に馴染み、使いやすいツールに

1年半前には身の丈がどうのこうのと書いていましたが、それからパームレストの購入、キーキャップのアレンジなど好き勝手やっています。在宅で仕事するときのモチベーションの一つとなっており、今でもいい買い物をしたと思っています。

HHKBの購入に悩んでいる人へ

HHKBの購入に多くの人が悩むのは金額だと思います。キーボードに4万円、、、なにを血迷えばそんな金額になるんだ、、、と思いますが、使ってみると4万円の価値を感じることができるし、何よりも長く使えば愛着も出てきて使い勝手も良くなり、いい買い物をしたなと思える商品だと思います。個人的には自分のスタンダードなキーボードを選定してからいろんなキーボードに手を出していきたいと思っているため、そのスタンダード（随分と高価なスタンダード）には間違いないかと思います。

2023-09-30

【Redshift】ユーザーにアクセス権を付与するときのハマったこと

目的

Redshiftにおいて、あるユーザーでSELECTを実行したときに以下のように怒られました。

Invaild operation: permission denied for schema

このエラーを解決するしたときのメモとして残しておきます。

概要

上記のエラーは現在使用しているユーザーに権限がなく、クエリが実行できないことを示しています。これを解決するためにはユーザ―に権限を与えます。

解決方法

GRANTを実行して、指定のユーザーに指定の権限を付与します。

以下のクエリを実行します。

GRANT USAGE ON SCHEMA [権限許可をするスキーマ名] TO [権限付与をされるユーザ名];
GRANT SELECT ON ALL TABLES IN SCHEMA [権限許可をするスキーマ名] TO [権限付与されるユーザ名];

説明

USAGE

PostgreSQLドキュメントによると、

スキーマにおいて、指定したスキーマに含まれるオブジェクトへのアクセスを許可します（オブジェクト自体の権限要件が満たされている場合）。基本的には、この権限によってスキーマ内のオブジェクトを"検索"する権限も認められます。

Redshiftドキュメントによると、

特定のスキーマに対して USAGE 権限を付与します。これによって、そのスキーマ内のオブジェクトにユーザーがアクセスできるようになります。ローカルの Amazon Redshift スキーマでは、これらのオブジェクトに対する特定のアクションを個別に許可する必要があります (例: テーブルに対する SELECT または UPDATE 権限)。

USAGE権限を付与しますって何でしょうかという感じですが、Usageは「使用法」「用法」「利用」という意味なので、利用を許可するという解釈にしておきます。私はこのUSAGEを実行せずにSELECT ONのみを実行していたため、スムーズに権限を与えられていませんでした。

SELECT ON ALL TABLES

TO以下のユーザーに全てのテーブルに対してSELECT権限を与えています。このALL TABLESという文言でVIEWを含んだ全てのテーブルへのSERECTが許可されます。VIEWを許可する場合、それらに関するテーブルの権限も与えることも忘れないようにしましょう。

まとめ

GRANTを使用して特定のユーザーに権限を与えようとしたとき、USAGEも忘れずに実行しましょう。

参考資料

2023-09-25

英語を学んで1ヶ月くらい？経ったこと〜知ってるけど意識できなかったこと〜

この記事はなに？

恥ずかしいお話ではありますが30歳の今のいままで英語から逃げていました。コンプレックスがあるくらいには苦手意識があります。そんな私がちゃんとした英語を学ぶ機会があり（おそらくこのチャンスを逃せば一生英語に苦手意識をもったまま生涯を過ごすだろう）、それを続けて1ヶ月が経ちました。その所感をまとめてみようと思います。

むかし

この年齢まで英語ができないことで人生詰むことがなかった（と思っている）のは日本が本当に英語なくても生きていける国だから、それに限る。私の英語のレベルはというと喋れない、聞けない、書けない、読めない（読むとは言わず解読するという）という酷いもので5年に1回くらい仕事またはプライベートで不便な思いをしてきました。

いま

たかが1か月勉強しただけで英語に自由なるなんて毛頭思っていません。今も四苦八苦しながら時間を捻出して単語帳やシャドウイングに取り組んでいます。時間を見つけては単語10個覚え、15個忘れ、英文を見つけては構文が読み取れずAIの翻訳を任せ、曲りなりに進んでいると信じたいところです。

苦しい中でも発見はある

日常英語、ビジネス英語、研究英語、どれも使い方が違うって言われていましたが、その違いを理解することができてませんでした。同じ英語じゃんって思っていましたがそれは大きな間違いでした。それを自覚したのは日常英語からビジネス英語に切り替えたときです。ビジネス英語の言い換えができず、英作文が全くできませんでした。日常英語であれば言い換えをして何とか英語にできるのに対して、ビジネス英語のなると点でできませんでした。これが私が実感した英語の種類の違いでした。よくよく考えてみれば、研究論文などの英語もよく出る表現があり、もしかしてこれも違いの一部なのかもしれないと思うようになりました。違いがわかるようになるということはある程度実践を積み、意識しないと発見することができないことなのだと実感しました。ただ分かった振りで終わってしまうこと、よく言われるからなんとなくそうなんだろうと思い終わってしまうことが世の中にどんだけ多いことか、、、まだまだ一部ではあるが、英語において実感できることがあり、気が付いた時には勉強してよかったと思いました。

みらい

皆さん、意外な人がスラっと英語をしゃべり始め、まじかよと思ったことはないでしょうか。私も何食わぬ顔でスラっと英語をしゃべれるようになりたいです。そして皆さんが言うように私も「私の英語なんて全然ですよ～」と言えるようになりたい。語学学習は生涯を通じで取り組んでいく分野であると認識しています。ゆっくりと少しでもコツコツと、時間をかけて、地面に染み込み磨かれていく水のように取り組んでいけたらなと思います。英語学習をしている皆さん、頑張りましょう。

おまけ

データエンジニアのブログと書いてあるのに、データエンジニアっぽいことを全く書いていないことに焦りと不安を感じています。次は技術系の記事を書くことを誓います。

2023-08-27

データ分析失敗事例（其の壱）

概要（なにがあった？？）

最近にデータ分析失敗事例集※1を読んで、この内容のことがまさに自分の身の回りで起こってることだ！と興奮気味にページをめくり、読み終えたころには少し悲しい気持ちになっていました。事例ごとに細かく記述されておりとても読みやすく問題点や改善方法も具体的に記載されていたため、データ分析の経験が浅い私にとっては良書でした。
話は逸れましたが、この記事では仕事上で私がマーケティングセクションからの依頼でデータ分析を担当し、失敗してしまったなと感じた苦い経験に基づいたデータ分析失敗事例を記述していきます。技術的な要素がメインではなく、ポエム的な要素が多いため、その点はご了承の上で楽しんでいただけたらと思います。

背景（どんなこと？？）

マーケティングセクションからの依頼は以下のようでした。

定期的に消費者から収集しているアンケートを分析を自由にできるようになりたい（アンケート会社から提供されているデータは生データ（CSVファイル）とBIツール（Tableau）で決まった切り口での分析しかできなかった）
結果をレポーティングする際に発生するExcelの集計作業を簡略化したい
定期的に取っているデータだが時系列的に分析ができない項目がある
- 同じ質問だが質問文が若干異なるため時系列で並べることができない
- 同じ質問だが質問番号がアンケートごとに異なり、それらを収集する作業ができない
活用されていない質問項目があるため、活用できるようになりたい

以上がざっくりとした依頼内容でした。データ分析がまだ広まっていない我が社ではこのような依頼がビジネス部門から出ること自体が珍しく、私は嬉々としてこの依頼を受けました。勘のいい人は気が付いていると思いますが、この時点が安請け合いしてしまったことから間違いは始まっているのかと、今となっては思います。

手法（お前はどうした？？）

依頼を受けた時の私がざっくり考えたことは

生データであるCVSファイルはS3へ格納
S3からAurora(PostgreSQL)に格納
いくつか成型用のSQLとViewを作成するSQLを作成
ViewをBIツールで分析できるようにする

かなりざっくりとしているが以上のような構成でデータ基盤を作成すれば依頼の内容の8割は達成できるのではないかと思っていました。

まず、なにが起きた？？

依頼を受ける前に生データ、もといデータソースは確実に確認しておくべきでした。受け取ったCSVファイルの中身は既にアンケート会社の元で編集されたものであり、人が見やすいようなデータ構造になっていました（正規化がされていない...）。これを直すためにデータ成型にPythonを使いました。早速ではあるが、ここで時間を使ってしまいプロジェクトの計画が詰まってしまいました。

何が問題？？

今までの説明でお分かりになると思いますが、ぶっちゃけクリティカルな業務でないためプロジェクトが遅くなっても業務に何か影響が出るわけでもありません。今まで通り工数のかかるExcelでの集計作業が続くだけです。しかし、担当者だけはそうではありません。調査業務を主担当としてやっていたため、このプロジェクトの遅延で上司からのプレッシャーはかなりかかっていたようでした。その雰囲気を感じていたため、私たちは急いでそのプロジェクト回していきました。

結果（そのあとどうなった？？）

程なくして、実装が完了し集計作業までの自動化を終えました。私たちは担当者に対してデモとして集計作業の自動化と依頼要件を満たすようなダッシュボードをリリースしました。デモの動きと要件の達成度に関しては申し分なかったのですが、担当者の顔が浮きません。なぜなのか話を聞いてみると、その担当者の上司からの要件と私たちが達成した要件がずれていることが分かりました。

集計ができるようになったことは大きい成果だが、その先はどう考えているのか（それはお前も考えるのでは？？）
報告レポートはExcelを廃止し、BIツールのみで統一すること（え、なにそれ？なんのため？？）
通常業務が忙しいため、BIツールの教育コストを払うことができない（）

などなど、歪んだ要求を含め理解できない点が多かったため、その上司と直接話さないといけないと感じました。しかし、担当者が休職、担当変更がありました。

そこに罠が、、、

変更後の担当者は「まずは、私が使ってみて疑問点や変更点などがあれば連絡します。次のMTGは1か月後で」ということで、変更後のMTGはすぐに終わりました。私は使っていれば疑問がわいてきて連絡が来るだろうと思っていましたが、ここも間違いでした。そもそも使わないのです。何回が連絡を入れましたが、使っていないので疑問が出ることもなく、返信もなく、そのまま1か月が過ぎました。私のタスクの状況もあったため、ここでいったんプロジェクトは終了しようと私のほうからクローズを申し出て、成果と課題をまとめて終了しました。

まとめ（結局何が悪かったの？？）

データソースは確認しよう
課題設定を間違えないようにしよう
担当者の上司がどこまで期待しているのかまで考えよう
新しいものはなかなか使われない、というか興味ある人しか使わない

私の安請け合いから始まり、課題設定、擦り合わせ、持続的なモチベーションなど問題が様々あり、回収しきれない感じがしてしまいましたが、データ分析業務は一筋縄ではいかないなと痛烈に実感するところでした。救いのない話ではありますが、これが現実であり、この現実を変えるために勉強して、経験積んでいかないといけないと痛感するばかりです。

脚注

※1：データ分析失敗事例集, 共立出版, https://www.kyoritsu-pub.co.jp/book/b10032587.html