カテゴリー: review

これは GMOペパボ ディレクター Advent Calendar 2021 の13日の記事です。 今年2021年は、個人のふりかえりを週次で行ってみた。
もともと日記を（日次で）書いてはいたけど、出来事を数行おざなりに書く程度だった。1日の終わりに書く日記にそれ以上の気力が出ず、日記の改善はあきらめて週次でふりかえるように変更した。
2021年のふりかえりとして、この週次のふりかえりについてふりかえってみる。

どういう形式でふりかえったか

以下の項目を立ててふりかえるようにしていた。
・今週のトピック
急に「今週をふりかえるぞ」と思っても、そもそもどのような週だったかが意外と記憶から抜け落ちている。まずは何が起きた/した週だったのか書き出す。
・KPT
上記の書き出しでだいたいどんな週だったか掴めたら、Keep / Problem / Try という観点からその週をふりかえる。
・課題
上記2項目は短文での簡単なふりかえりなので、もっと突っ込んでふりかえりたい出来事については別で書く。

うまくいったところ

日々の感情の動きを少し俯瞰できた

ふりかえろうとすると、心の中で思っているだけなら不要だった言語化が必然的に必要になる。
漠とした気持ちをどうにか文章に落とそうとする過程で整理されていき、感情がラベリングされる。これがその時点での俯瞰につながり、毎週の記録が積み重なっていくことで過去との差分が見えてきて、それが長期的な視点での俯瞰につながったように思う。
これは「いったい何週間同じことで悩んでいるのか、悩み方に進歩がない」ということを（薄々気づいてはいるのだが）明確に突きつけてくるので、その点でも良かったと思う。

継続して取り組むことができた

こういった取り組みは徐々にやらなくなってしまうことが多い（自分は）。今回、途中飛んだ週は若干あったものの、継続できたのは以下の点がうまく働いたように思う。
・取り組む時間と場所を決めた
毎週土曜日の午前中にやるようにしていた。休日の方が外的要因による気持ちの波が小さく、午前中だと睡眠により脳が整理されていて取り組みやすかった。また（コロナが落ち着いている時期は）カフェで行うようにしていたので、場所も固定され「この時間にここに行ったらやる」という習慣になりやすかったと思う。
・予定を設定した
やることをNotionで管理しているので、毎週このふりかえりのtodoを入れるようにした。必ずNotionは見るので、todoが未完了で残る気持ち悪さが着手を後押しした。

うまくいかなかったところ

本当にしんどい時は書けなかった

本来、何かつらいこと（≒ 学びにつながる可能性が高いこと）があった時こそふりかえるべきなのだろうけど、それができない週もあった。でもその週の記録が残っていないと「あの時期苦しかったな」という漠然とした認識になってしまうし、自分に都合の良いように記憶を改竄してしまう恐れもある。
同じつらかったこと/失敗したことでも、ふりかえりを書ける時と書けない時が存在した。 書けるのは、その出来事の直後に「しまった、ああすれば良かった」と悔いたときだった。要は次回の改善策まで思い至っている時で、失敗を思い出すのは嫌でも、とにかく書いてしまえば脳内で抱えておく必要がなくなる。そのため、吐き出すように勢いよく改善策まで書き下せてしまえる。
一方、書けないのは、つらいという感情に支配され、しかもどうすればよいかわからない時だった。つらさの渦中にあるからとにかくそれを想起したくない、文章にすると自分でそれを認めることになるから苦しくて書けない。

→ 改善策：ふりかえりのタイミングを一部フレキシブルにする

毎週土曜に固定してふりかえっていたけど、まだその出来事を消化できておらず向き合えないタイミングで土曜日となることもある。ならば、それをタイトルとして1行書いておいて、消化できたタイミングで詳細を書きに戻れば良いのではと考えた。逆パターンとして、土曜にふりかえるからいいやと放置したことで、いざ書こうとした時に記憶が薄れている場合もあった。土曜にしか書かないのでなく、段階的に書き足していく方式を取ってみたい。

ふりかえりで行動が改善されたのかが不明

毎週ふりかえってはいたものの、では実施しなかった時に比べて本当に自分の行動が改善されたのかと問われると、明確に言えないことに気づいた。ただの自己満足なら、毎週20分程度時間をかけている意味は薄い。

→ 改善策：先週のふりかえりの記録を読み返す時間を作る

KPTのTryを出したり、課題に対する対応策を書いて、それで終わりになっていることが多かった。実際にそのTryや対応策を実施できたのか、実施したならその対応は適切だったのか、実施できなかったならどうすれば実施できるようになるのか。そのあたりをふりかえる機会を設ければ、毎週のふりかえりが連続したものとなっていき、何を改善できたかもう少し実感を持てそうだと思った。 以上でうまくいったところ/いかなかったところが洗い出せたので、それをもとに来年2022年も週次のふりかえりを続けてみようと思う。

Notionを利用して、自分が学びたいことの進捗管理を半年間やってみた。
具体的にどうやったか、そこから気づいた改善点についてまとめる。

課題認識

今まで、なんとなく「これ勉強しないと」「こんなの作ってみよう」と脳内で考えて漠然と進めてきた。その時々でtodoを書き出してはいたけど、長期的な視点では整理できていなかったため、場当たり的な進捗になりがちだった。 この脳内管理には以下のようなデメリットもある。
・優先順位の整理が曖昧になった結果、結局どれも手をつけない
・常に「あれもしなきゃ」が脳の一部分を占領することになる
・進捗が可視化されていないので進んでいる実感が持ちづらい デメリットが多いことは承知しつつも、改善が面倒で「まあ仕事じゃないしね」という言い訳を盾に放置していた。重い腰を上げ、2020上期はNotionで管理する運用を試してみたので、ふりかえってみる。

具体的な管理方法

上記の課題（デメリット）を解決するには、以下の情報が整理されれば良いと考えた。
① 学びたい分野として何があって
② その分野ごとに取り組みたいことに何があり、いつ着手する予定で
③ 各取り組み内容に対して今日やるタスクは何か これを整理するために、3つのテーブルを親 – 子 – 孫の関係でリンクさせて管理するようにした。

① 親：Fieldテーブル

自分が学びを深めていきたい分野のテーブル
・例えば、統計 / マーケティング / 機械学習 / …などのような大きな粒度
　※ 専門分野を深めていく場合は、その分野の中でさらに分化した分野という粒度になる

② 子：Projectテーブル

Fieldテーブルの各分野に対して、具体的に取り組む内容（以下「プロジェクト」と呼ぶ）の各種情報をまとめたテーブル
具体的なやりたいこと、優先度、取り組む時期などを管理する。
・○○という本を読む / ○○を写経する / ○○を作ってみる …という粒度

③ 孫：Todoテーブル

実際に取り組める粒度まで分解したやるべきこと（以下「タスク」と呼ぶ）を管理するテーブル
・1章を読む / ○○について調べる …という粒度

運用の仕方

• 

以下1 ~ 3の整理を随時実施して時々見直しつつ、4の整理は日々行う形で運用した。

1. 学ぶ内容（プロジェクト）を追加する

各分野に対して、今取り組んでいる/今後取り組む予定のプロジェクトとして何があったかを眺めて、この分野はこれもやりたいというものを追加する。
この時、そのプロジェクトはどこまで取り組めたら完了とみなすかゴールを決めておくのが重要だった（「○○をやる」だけだと、完了の判定がしづらいため）。ICEスコアをつけて優先度を決め、取り組む時期を期程度の大きな単位で決めておく。（※ 途中からICEスコアはやめた　後述）

2. 学ぶ内容（プロジェクト）に取り組む時期を決める

進行中のプロジェクトの実施時期と進捗を見つつ、取り組む時期を決める。

3. プロジェクトをタスクに落とす

各プロジェクトのゴールにたどり着くまでにやるべきことは何か、タスクとして書き出す。

4. タスクに取り組む日を決める

Timelineビューで動かして、各タスクの実施日を調整する。実施日は大体で入れておいて、日々状況に合わせ気軽に動かしていた。

ふりかえり

よかったこと

「いつかあれやらなきゃな（いつかは来ない）」が多少軽減された

取り組みたい内容を登録しておくことで、次に取り組む内容を決める時に選択肢の一つとして検討することになる。

後から見た時、何をやったのか、どのくらいかかったのかがわかる

後からふりかえると「何もできなかった」という気持ちになることがあるけど、記録が残っていることで、ちゃんと進捗はしているのだ（歩みは遅くても）とわかる。
「何もできなかった」が本当に何にも取り組まなかったから正しい認識なのか、あるいは何か具体的に取り組んだけど思ったより進まなかったからそう感じているのかが判断できる。

1回仕組みを作れば、回していくのに手間はさほどかからない

よくこんな面倒なことやってるなと見えるだろうが、一度仕組みができてしまえば見た目ほど面倒ではなかった。

よくなかったこと/反省点

ICEスコアによる優先度決定はあまりフィットしなかった

当初はICEスコア (※) をつけてスコアが高いものから取り組んでいた。これだとやるべきことばかりが優先度上位に上がり、徐々に学ぶことの苦痛が大きくなっていった。
そこで、途中からはICEスコアによる判断をやめ、やりたいことも並行して取り組むようにした。結果、同時並行でいくつものプロジェクトが進むことになり、脳の切り替えが大変になった。
ICEスコアでなくても、取り組む優先度を決めるための何らかのルールは必要だった。やりたいこととやるべきこと、それぞれ1〜2個ずつしか同時には取り組まないというルールにしてみようと思っている。

タスクの割り方をもう少し工夫したい

例えば技術書を読むというプロジェクトの場合、単純に1章ごとにタスクとして登録していた。実際のところ、分量や難易度によって要する時間は異なる。そのため、複数週にわたって取り組んでも完了できないタスクが出てきた。
進捗が見えづらくなるしやる気も低下するので、もう少し実際の中身を考慮してタスクを割るように変える。

焦燥感はさほど減らなかった

脳内でタスクを管理していた時は、常に「あれもしなきゃ」という焦燥感があった。今回Notionで管理することで見える化され、それが減るのではと思っていたが、さほど減らなかった。これは、やるべきことを整理できていないことが要因の焦燥でなかった、あるいは見える化しても自分のタスクを進める速度は変わらないことあたりが要因かもしれない。

具体的な設定の仕方

似たことをやってみようという方がもしもいた時のため、直感的にわかりづらい箇所の作成手順を簡単に記載しておく。

テーブル同士の関連づけの仕方

紐づく親テーブルのTagsを子テーブルで表示したい場合を例とする。 1. 親テーブルと紐づける
子テーブルで、①プロパティがRelationのカラムを追加し、②親のテーブルを選択する。
③フィールド部分をクリックすると親テーブルのカラム一覧が出るので、紐付けたい親のレコードを選択する。

• 

• 

• 

2. 紐付けた親の任意のカラムを子側で表示する
①子側のテーブルで、プロパティがRollupのカラムを追加する。②フィールド部分をクリックすると各種設定が出てくるので、RELATIONを親テーブル、PROPERTYを表示したい親のカラムにする。

• 

• 

※ 書いておいてなんだけど、公式のhelpページがわかりやすいし詳しい

進捗率のバーの出し方

今回の例だと、そのプロジェクトに紐づくタスクのうち完了した割合を進捗バーとして表示するようにしている。
具体的な設定の仕方については、35D BLOG | Notion でプロジェクトの進捗を可視化する（Formula 機能の使い方）を参照させていただいた。

---

脚注 (※)
ICEスコア：複数の着手すべき事案がある時に、優先すべきものを順序づける方法
ICEは影響力(Impact) / 信頼度(Confidence) / 容易性(Ease)の頭文字で、この3指標の掛け合わせが大きいものから着手する

※　ここでのCSはカスタマーサービス（コンピュータサイエンスではない）

昨年、分析を中心としたディレクター職から、CS職に異動して半年ほど過ごした。
この半年間の経験から何を得て、意識や行動がどう変わったのか、再びディレクターに戻り数ヶ月経った現在までに感じた差分をふりかえってみる。

• ユーザーの姿が以前より立体的になった
  CS業務の中心である問合せ対応を行うなかで、自分の中のユーザー像が少しずつ具体的になっていった。以前はデータから「こういうお客様がいるのかな」と思ったり、周りから「こういう傾向のユーザーが多いよ」と聞いて、漠然とユーザーの姿を想像していた。それが、お客様からの問合せを千数百人分読み、1件ずつ自分の手で回答文を作成することで、「〜を目的として操作する人には〜でつまずく人が多く、それはこの部分が理解しづらいことが原因かもしれない」などの仮説が自分の中に蓄積されていった。
  データを見るとき全体的な視点になりがちだったけど、1件のデータの裏にいる1人のユーザーを実感を伴った形で想像できるようになったことで、データから仮説を考えやすくなったと感じている。¹

• 「分析が役に立てる」と認識する範囲が広がった
  CS業務を毎日していると、「こういう傾向の問合せが多いから改善したい」という部分（明らかな不具合であれば即エンジニア等に対応してもらうけど、そうではなく、より使いやすくなるような改善点）が見えてくる。そう感じる部分は同じサービスに携わるCS内では大抵共通認識となっていたけど、他職種の人も同様に認識しているかというと必ずしもそうではない場合もあった。
  その内の1つについて、事象の起こっている件数、それによる損失額、具体な原因と改善案を問合せ対応の合間にまとめ、CS外に提案したところ、実際に改善に至ることができた。
  以前は、当たり前なことを可視化しても「そうだね」「知ってる」となるだけで、さほど意味がないのではと思っていた。でも、当たり前の範囲は人により差があり、各自が認識しているサービスの姿は思っている以上に異なっていることがわかってきた。また、当たり前であってもその課題の大きさや姿は具体的に認識されていない場合もあることもわかった。
  こういった点について、分析者が媒介になる（課題を適切に可視化して共有することで、解決につなげる）ことも分析が役に立てる範囲なんだなと認識が広がった。
  媒介となるためには、分析者が課題の存在を認識している必要がある。CSにいればサービスへの反応を自然と知ることができるけど、現在は離れているし半年で認識できた範囲はわずかだと思うので、これからもCSのメンバーに積極的に話を聞かせてもらいに行こうと思っている。

• 分析を通じて貢献するぞ、という意識が強くなった
  CS在籍中、エンジニアやデザイナーなど色々な人が折にふれ、気にかけて声をかけてくれた。また、CSの同僚も私が分析をやりたい（CSとして今後やっていきたいわけではない）ことを知った上で、色々質問しても、どの部分を見てどう考えた結果その判断に至ったのか、サービスがそうなっている経緯など納得するまで教えてくれた。
  ディレクターに戻り、それらに報いたいという気持ちとともに、分析面でしっかり貢献できないと（分析専門でない部署で分析中心にやっている分余計に）自分がここに存在する意味がなくなってしまうなと思うようになった。
  存在意義を示すためには、分析により改善につながる部分を見定めること、分析結果を示すだけでなくそれを施策に落として提案することが必要だと思っている（そもそもの分析能力も当然まだまだ精進が必要だけど）。色々スマートにできなくて転げながらやっている毎日だけど、分析を業務としてやれることが嬉しいから、かっこわるくてもやっていく。

初めてWebアプリを作ろうとして、方法の検索からデプロイ（失敗した）まで色々試行錯誤したので、経過を記録しておく。

目的

そもそも作ろうと思ったのは以下のようなことが理由だった。

• 途中まで作った日陰の計算を一般的に使えるものにしたい
  以前、道路にかかる影の割合を計算して、任意のルートの涼しさを調べようとしたことがあったので（「夏には日陰を歩きたい」という欲望を満たすために計算する）、これをローカルで実行できるだけでなく一般的に使えるようにしたいと考えた。
  考えた時点ですでに夏が過ぎていたので、涼しい道でなく暖かい道を調べられるよう、直射日光の量を計算するように変えた。

• Webサイトの仕組みについて、雰囲気だけでもつかみたい
  「ブラウザからリクエストが来たら、なんか処理して、レスポンスが返されるんでしょ…？」という非常にふわっとした理解だったので、「なんか処理」の部分がどのように作られているのか少しでもイメージできるようになりたいという気持ちがあった。
  普段仕事をしていても、エンジニアやデザイナーが何をして、サイトの表示やアカウントの登録等ができているのか、それを実現するコードがどのようなものなのか想像ができなかった。一緒に仕事するにあたり、詳しくはわからなくても、概略をイメージできるとよいなあという気持ちがあったので、自分で作ってみることにした。

できたこと

緯度経度と日時を入れたら、暖かいルートを表示する仕組みを作った（ローカルでは動く）

できなかったこと

ライブラリがうまく扱えず、デプロイができなかった
※うまくできなかった部分の詳細については、こちらに記載した。

作業経過

1- 調べる : 1h
「Pythonでweb上で動く仕組みを作るにはどうしたら良いのかな〜」と思い、そのまま「Python Webアプリ」と検索した。
DjangoとかFlaskというのが有名で、Djangoの方が色々やれることが多いらしいとわかった。自分のやりたいことに対してFlaskでもできるかの判断がつかず（多分できた）、Djangoでやってみることにした。

2- Djangoの学習をする : 24h
最初にDjangoのチュートリアルをやった。
丁寧に手順を追ってくれていてその通りに操作をすることはできたけど、各操作が何を目的としたものなのかや、全体的なファイル構成とかがわからなかったので、下記のような感じで各ファイルのつながりをメモしながら再度なぞってみたら少し理解ができた。

この時点で実際に自分の作りたいものに着手して、よくわからなくなったら本や動画を参照する形で進めた。以下を参考にさせていただいた。
本：現場で使える-Django-の教科書《基礎編》
動画：【3日でできる】Django 入門

3- 暖かいルートを計算するにはどうしたら良いか考える : 18h
以前計算した道路にかかる影の割合（「夏には日陰を歩きたい」という欲望を満たすために計算する）をベースに、暖かいルートをどのように計算したら良いか考えた。
結果、厳密には正確ではないだろうが「距離当たりの体の受ける直射日射の量」で代替することにした。太陽から降り注ぐ日射のうち、角度のついた鉛直面の日射量を計算する方法を本やネット上の論文から調べた。また、計算に用いる道路の緯度経度をOpenStreetMapから得て、各道路の方位角と長さを求めた。
大まかには、以下のような計算を行っている。コードはこちら

4- コードを書く : 28h
日射の計算のコードを書いていたのが10hくらいで、残りはDjango関係のコードを書いていた。地図の表示や、Djangoでの画像の表示がうまくいかず、時間がかかった。
コードはとりあえずこちらに置いてある。

5- デプロイする（失敗） : 22h
最初は別サービスを使ってデプロイしようとしたがうまくいかず（色々いじっているうちになぜかpipがうまく働かなくなり、最終的にOSの再インストールに至った）、Herokuを利用して進めていった。
Herokuのアカウントを作って、チュートリアルをやった。丁寧に説明されていて、例となるコードをクローンして進める形だったので静的ファイルの取り扱い等も参考にでき、初めてでもすごくわかりやすかった。
結局、ライブラリの扱いの部分でうまくいかず、年内の完成を目指していたのでいったん諦めることにした。
※うまくできなかった部分の詳細については、こちらに記載した。

やってみてどうだったか

当初の目的に対し、どうだったかをふりかえる。

• 途中まで作った日陰の計算を一般的に使えるものにしたい
  →　結局デプロイできなかったので、一般に使えるものにならなかった。悔しいので、またもう少し理解が深まったら、つまづいた部分を解決してデプロイまで至るようにしたい。

• Webサイトの仕組みについて、雰囲気だけでもつかみたい
  →　（Djangoの場合の）各ファイルがどのように関係して、サイトが表示されるのか（MTVモデル）がうっすらわかった。Djangoの内部でどのような処理が行われているかはわかっていないので、「フレームワークすごいな〜」という気持ちになった。Webサイトの作りについて、さわりだけ知れたかな…という感じ。

統計検定を受けた時のふりかえりで「何に時間をかけているか意識をしよう」と考えてから、ちまちまと記録をしていたので、半年間の時間の使い方をふりかえってみる。
以下、自分で「学び」系の区分に入れていた時間の内訳を記載する（なので、一般に「これは学びというより趣味なのでは…」という部分も含まれる）。

⑴ データ分析関係

• 分析手法を学ぶ 18h 7冊
  データ分析の手法や、業務として分析を進めていく方法などについて書かれている本を読んだ。読んだ中では、以下の本が一番実際の業務に当てはめながら読めて、学びが多かった。
  ビジネス活用事例で学ぶ データサイエンス入門

• 機械学習について学ぶ 15h 2冊
  scikit-learnのライブラリを利用して実行する方法と、機械学習に使われている数学の基礎について書かれた本を途中まで読んだ。半年で15hと、お前やる気あるのかという状態なので、来期はもう少しまじめに勉強する。
  機械学習を理解するための数学のきほん
  Pythonではじめる機械学習 scikit-learnで学ぶ特徴量エンジニアリングと機械学習の基礎

• 実際のデータで試す 62h
  上記で学んだ手法を実際のデータで試して遊んでいた時間。けっこう時間かけている割には、ちゃんとまとめておらず、ちょっと試してみたJupyter Notebookが散逸しているような状態で、自分の中に残っているものが少ないのが反省点。

⑵ エンジニアリング関係の学び

• Gitについて学ぶ 10h 2冊
  Gitに苦手意識があったので読んだ。脳内のイメージは以前より深まったが、実際にその状態を作り出して試してみないと「わかった」状態にならないだろうなと思う。
  エンジニアのためのGITの教科書

• Linux コマンドについて学ぶ 6h 1冊
  まだ途中までしか読めていないけど、現在の自分にとっては学びが大きかったので最後まで読む。
  Linuxの教科書

• SQLを学ぶ 8h 1冊
  ごく基礎の部分をひととおり知ることができてよかった。
  スッキリわかるSQL入門

• インターネット関連の基本的なことについて学ぶ 6h 3冊
  よくわかっていないので読んだ。
  DNSがよくわかる教科書
  この一冊で全部わかるネットワークの基本
  この一冊で全部わかるWeb技術の基本

⑶ 業務理解

• ビジネス系の本を読む 34h 16冊
  周りの人がごく普通に感覚として持っていることでも、自分は知らないなと思い、なるべく業務に関係しそうな本を読んだ。

この辺は、知識として読んでよかったなと思う。
カスタマーサクセス――サブスクリプション時代に求められる「顧客の成功」10の原則
サブスクリプション――「顧客の成功」が収益を生む新時代のビジネスモデル

逆に、直接的に業務とつながるわけではないけど、「面白い」と思ったのはこの辺り。
TRUST 世界最先端の企業はいかに〈信頼〉を攻略したか
Airbnbが登場当初、「見知らぬ人の家に宿泊する」というアイデアへの理解・信頼を得るため、どのようなサイト構成にしたのかという部分が興味深かった。

すいません、ほぼ日の経営。
“いまは「あなたはなにもしなくていい」という商品ばかりが売れる時代です。でも手帳は、あなたがなにかをしなければいけない商品です。使いながら完成させていくものです。ぼくらは、いわば未完成品を売っているわけで、それを完成品にするのは使う人です。”

色々条件は異なるけど、作ってもらうという部分は今の仕事で扱うサービスと共通で、なんかヒントがありそうだなと思った。

• インタビューについての本を読む 17h 3冊
  社内で分析課題について探る時、「その業務に精通している人から的確に話を聞いて、分析課題に落とす」ことが上手くできていないなという気持ちから、インタビューにヒントがないだろうか、と考え読んだ。メモを取ってまとめたは良いものの、そのままになってしまっていたので、見返して日々に活かすにはどうしたらよいかを考える必要がある。

マーケティング・インタビュー 問題解決のヒントを「聞き出す」技術
ユーザーインタビューをはじめよう ―UXリサーチのための、「聞くこと」入門
インタビュー 木村俊介

⑷ アウトプット

• 日影の割合をPythonで計算してみる 91h
  (ブログ)「夏には日陰を歩きたい」という欲望を満たすために計算する
  スライド
  • 作成時間 64h
  • ブログ記事を書く時間 14h
  • LT用のスライド作成・発表練習 12h

仕事でPythonに触れる割合が減ったので、忘れないようにという意味合いもあって行った。作成のふりかえりはすでに書いた。
はじめてのLTで緊張したけど、一人で作っていたものについて人が話を聞いてくれて、感想まで教えてくれるってすばらしいなと思った。

• データベースを作成してみる 29h
  (ブログ)MySQLでCSVファイルからデータベースを作る
  • データベースの作成 11h
  • ブログへのまとめ 12h
  • その他（データベース作成前のデータ整理／作成後のデータ追加） 6h

ブログへのまとめに時間がかかっている。本編より長い。まとめ出すとよくわかっていない部分に気づいて調べたり、どう書いたらわかりやすいのか考えたりとかしているうちに時間がかかってしまっている状態。もう少し短縮したい。

⑸ その他

• ふりかえり 14h
  主に「今週のふりかえり」（何をしたか、何を考えたか）をしていた時間。平均0.5h/週。今のところ「やっててよかった」と思う機会は訪れていない。

• 色々考える時間 23h
  仕事／仕事外両者について、「こういう分析やれないかな」「やるには具体的にどうしたらいいか」等考えていた時間。のはずなんだけど、しっかりまとめてメモしていなかったせいで、かかっている時間の割には実りが少ない。平均1h/週。

• その他 28h
  Pythonのライブラリ入れてうまくいかなくて調べたり、疑問に思ったことを調べたりしていた時間。

• 不明 26h
  「何やったか書くのめんどいな…」と思ってその場で書かないとこうなる。⑴〜⑶のいずれかに入ると思われる。

ふりかえっての所感

記録を取ることで時間に対する感覚が転換した

以前から、時間の使い方は毎日記録していた。ただ、それは睡眠x時間、仕事y時間…という項目別のレベルの記録だった。それだと、学びに対して「今週はx時間かー」というふりかえりになり、「いかに学びにかける時間を増やせるか」という見方になっていた。
それが学びの中身を具体的に記録するようになったら、「この本読むのにもうx時間かかってるのか…急ごう」となり、「いかに短い時間で学べるか」という見方に変わった。
どちらも「記録する」という点では同じなのに、自分の見方が逆に変わったのは面白いなと思う。

漫然と学んでしまっている

その週、仕事で触れていた分野だったり、図書館で偶然借りた本だったりを学んでいることが多かった。計画性に欠けていた。
半年単位で集計すると数十時間かけていたことでも、ふりかえると「こんなにかけてた…？ていうか何も得てなくない…？」と思う分野もあった。特に「本を読んだ」分野だと、メモを取っていないと内容がほぼ記憶に残っていない（メモを取っていても、鮮明には残っていない）。

勉強すること自体には意味がない

そう、「勉強すること」自体には意味がないのである（※ 娯楽として勉強する場合は別として）。今の自分の学びは、基本的に「データ分析の観点から役に立てるようになる」ためにやっているので、学んで「なるほど」で終わったら意味がないのである。この点の意識が不十分だったなと思う。

半年あったら、もっとできるんじゃねーの、と思った

総量的な意味でも、時間あたりの質的な意味でも、ふりかえるともっとできるよね？という感じ。

図書館を利用することの弊害が出ている

8割方の本は図書館で借りさせていただいて読んだ。図書館で借りることのメリットは、返却期限があることで、強制的に勉強する期限が設定できることだ。
一方、図書館で借りて「腰を据えて勉強しよう」と思った本は買って読むんだけど、そうすると「いつでも読める」と思ってしまう。結果、自分にとって重要度の高い本を読まずに、返却期限のある本を優先することになってしまっていた。

バックアップはちゃんと取ろう

6/29、PCが壊れ、ここ半年で学んでローカルに保存していたファイルやデータベースが消えた。バックアップの重要性が身にしみた。この記事もスマホで書いているけど、画面が小さくてつらい。

で、これからどうするの？

• もう少しこまめにふりかえって、軌道修正するようにする
• 学んだ内容をちゃんと文に落とす
• 図書館で本を借りるのはもう少し抑える
• 理論面、技術面を真剣に学ぶ

やろうと思った目的

• GW10日間チャレンジ
  今回、10日間という例年にない長期休みだったため、普段の勉強とは違い、何か具体的な課題に取り組みたいと考えた。

• 課題への時間の見積もりができるようになりたい
  業務で分析課題を行う際、「どのくらいでできるか」と問われてもなかなか答えられなかった。これは、経験値が少ないことも当然あるのだけど、自分が「何の作業にどのくらいかけているか」をあまり意識できていないこともあると思った。
  今回、解決までが見通せていない課題に取り組む中で、どのような過程で何を考え、何に何時間かけたかを記録して、時間感覚を得たいと考えた。

• 見えていないものを見える化してみたい
  普段漠然と感じていることを数字に落とし、それを視覚化することで容易に理解できる形にする。すでにある数字から何かを作るのではなく、数字化する部分からやってみたいと思っていた。

当初目標としていた内容

当初は、地図の画像を読み込んで建物を検出し、それぞれに高さを与えて任意の時間における影を地図に重ねて描きたいと考えていた。
結果的に、以下の理由により断念した。

• 建物の輪郭だけを得るのが大変
  無料で使用できる白地図が見つからなかったので、OpenStreetMapを利用させてもらうことを考えた。だが、自分の技量不足により、建物の輪郭を検出する際に、地図上の建物名や通り名等も検出されてしまい、うまくできなかった。

• 建物高さを得るのが大変
  とりあえず自分の行動範囲だけでよかったので、Googleマップ等で目視で調べようかと思っていた。だが、GW中に完成させるという目標に対し、それをしている時間がなかった。また、地図上の建物と高さを機械的に紐づける方法も思いつけなかった。

8日目の時点で諦め、目標を「単純化した建物モデルに対し、道路の方位角ごとに影のでき方を調べる」に変更した。

作業の変遷

開始時点では、以下のような認識だった。

• 各建物のコーナー部の座標が得られれば、そこから影は求められそう
• 建物の色と地の色に差があれば、画像処理でうまく建物だけ検出できないかな？　画像処理ってどうやるのかわからないけど
• 著作権の問題で、Googleマップとかは使えないかもなあ…　無料で使える地図ってないのだろうか

そのような認識から始めたので、作業は以下の3分野を並行して進めていくことになった。

• 地図から建物外形を得る：地図に描かれた建物の枠線を検出しようとしていた。建物名や通りの名前が入った状態の地図から枠線をうまく検出できず、最終的に断念した。

• 建物の座標を得る：テスト用の図を自分で用意し、その図の中の建物の枠線を検出し、コーナー部のみになるよう間引き、その座標を得ることができた。

• 影を計算して描く：建物のコーナー部の座標に対し影の位置を計算し、影の枠線を描き、道路のうち影の重なる面積を求めた。また、ある経路の方位角を求め、日陰になる割合を求めた。

3分野ごとの作業内容を時系列で示すと以下の通り。

円の面積はかかった時間に比例している。また、灰色の円は結果的に不要だった作業を示す。
かかった時間は全体で60時間、そのうち結果的に不要だった作業は9時間くらいだった。また、色々調べたり検討したりしていたのが12時間、コードを書いていたのが48時間くらい（後者はコードを書くために調べていた時間も多いとは思う）だった。60時間と聞くと「かかりすぎだな」と思うけど、上図のように一つずつの作業に分解すると、「今の自分の力だとそのくらいはかかるか…」という気もする。

次回の改善点

• 作業に取りかかる前にゴールを明確に設定する
  今回、8日目の段階で当初の目標を断念して目標を変えたため、結果的に無駄になる作業が出たり、回りくどいコードになったりしてしまった。開始当初の時点で「現時点の知識からして、10日間でこの目標を達成するのは難しそう」と感じていたので、変更した目標を当初から目標としていれば、もう少し短時間で目標を達成できたと思う。

• もう少し系統立てて進められるようにする
  やり方を調べるところから始める部分が多く、最後の数日になるまではずっと混沌の中で進めていた。
  「今どこまでできていて、何が課題なのか」を脳内で考えるだけでなく書き出して進めていけば、自分の脳内を整理する意味でもよかったかなと思う。

感想

• 普段の土日を何週か使って進めていたら、たぶん途中でやめていた。「遊びのコード書いてないで、普段の業務に直結することやろう…勉強したいこともたくさんあるし」となっていたと思う。「この10日間で完成まで持っていく、何らかの形にする」と決めてやったことで、集中してやることができた。
• 段階ごとに自分で小さな問いを立てて、それをクリアするとゴールに近づいていく嬉しさがあった。今回の課題は、さらにそれが現実世界とつながっている面白さみたいなものもあったと思う。
• 楽しかったけど、やっている最中は「どこが間違っているかわからない」「落ち着け」「あと3日なのに、全然ゴールが見えない」「ここ直したいけど数時間かかるだろうし」とほぼ焦燥感の中にいた。他者が作ってくれたライブラリを利用させてもらっているだけで、しかもうまく使えてないし、色々わかってないし、と道のりの長さを感じるけど、足元に目を落として一歩ずつ淡々と進んでいくしかない。

先日、統計検定2級の試験を受けた。感触がいまいちだった¹ので、結果が出る前にふりかえりを書いてしまおうと思う。（後日、運よく受かっていたことがわかった）

知識のついていく過程

基本的に、過去問²を解くことを中心に学習した。その合間に、公式のテキスト³を読んだり、理解が曖昧で何度も調べる部分をまとめたりした。
過去問の年度別に、正答を導けた割合の変化を時系列で見てみると下図のようになっている。

一応、どの年度も解き直しをする度に少しずつできる割合が上がってはいる。今見ると、解き直しでも8割程度しか取れていないあたり、理解や演習が足りていない様子が表れているなと思う。

大まかに次の3段階で理解が進んでいった。
– 初期：理解していることが自分の中で整理できていない状態。全体の5割は解説を読めば理解できたけど、3割くらいは解説を読んでも理解できなかった。
– 中期：公式テキストをざっと読んで自分の中で整理し、最低限公式的な部分は覚えてしまうことで、過去問の解説を読めばほぼ理解できるようになった。
– 後期：1度理解しただけでは自分で再現できないような、あやふやな部分を解き直した（が、おそらく身についてはいなかった）。

かけた時間

初見の過去問に対し正答を導けた割合と累積学習時間を重ねてみると、割と比例していることがわかる。おそらく、この分野に対する学習がまだ初期段階だから、やるだけ理解が上がっていく楽しい時期にいるんだと思う。

試験終了後に集計してみるまで、これほど時間を投入していたと思わなかった（合計で40~50時間の感覚だったのに、2倍くらい費やしている）ので、投入時間の割に自分の理解のレベルが低く感じ、数日悲しい気分になった。

いったいどの部分にこれほど時間がかかっていたのか？
体感だけど、過去問に下記の時間をかけていたと思う。

これに公式のテキストでの学習やまとめていた時間を足しても、おそらく60時間程度にしかならない。
約30時間が闇の中である⁴。

統計検定の勉強による変化

良いこともあって、社内でやってもらっていた読書会⁵に使用していた本（統計学入門⁶）に対する見え方が変わった。
読書会中はだいぶ難しく感じて、「統計とかデータ分析やってる人ってみんな天才なのかな…?」「ていうか自分が向いていないだけか」と思ったし（今もこれはよぎる）、本に対し30回くらいは「いったい何言っているんだ…」と思った。統計検定の勉強をした後に見ると、理解できるようになっていて「かなりわかりやすく丁寧に書いてくれているな」「確かに入門の本だな」と思えるようになった（入門レベルだと判断できることと、その内容を完璧に理解できることはまた別ではあるが）。

学習へのふりかえり

今回、学習時間は記録していたけど、その中で何をしたかは記録していなかった。遊びとして記録していたから、最初にしっかり考えなかったけど、最後に何を見たいのかを考えて記録すべきだった。
今まで学ぶ量（時間）を増やそうという方向に意識が向かっていたと思う。でも時間は有限で、さほど若くないのに新たな分野を物にしようとするなら、何をしたのか、それに時間がどれだけかかったのか、もう少し自覚的になる必要があると思った。試しに1ヶ月、勉強した時間とその内容を記録してみようと思う。

具体的にやったこと

データサイエンス領域
「基礎統計学Ⅰ 統計学入門」

• 1ヶ月めに引き続き、読書会形式で一緒にやっていただいた。先月より内容的に難しく感じる部分が増えて、進捗としては本の半分を超えた程度。
• 数式を追っていくとそうなることはわかるけど、その結論は感覚的には納得できない、というような部分で引っかかっていた。
• そういった部分について、具体的にPythonで計算してみたりした。結果、納得とまではいかなくても、やる前よりはその概念に対する理解を少し進めることができた。

データエンジニア領域
「Pythonによるデータ分析入門 ―NumPy、pandasを使ったデータ処理」

• 上記の本を参考にしながら、Pandas等で何をすることができるか学び、実際のデータに適用してみて理解を深める、ということをした。
• 先月やった1冊めの本(Pythonの基本的な使い方を網羅する本)では出てこなかったデータ分析のためのPythonでの書き方を知ることができ、先月より具体的なイメージを持つことができた。

事業ドメイン領域
実際のデータを分析して、事業に貢献する会が始まった。

• 実際のデータに触れるのはとてもテンションが上がる。学習用のデータと何が違うんだ、と言われると明確な差があるわけではないけど、おそらく、本当の出来事のデータであるという点と、そのデータを通して自分が貢献できる可能性があるという点が異なるからだろうと思う。（逆にいうと、貢献できなかったら自分の存在価値をどこで示していけるかというプレッシャーも当然ある）
• 残り2つの領域が、データ分析における道具に当たるのに対し、この領域は分析の前提に当たる根幹部分だと思う。道具でない分、その身につけ方は不定形で捉えづらい。実際、上記の会でも話についていけない部分があって、一方でそれを理解できるようになるにはこれを学べばよい、という類いのものとも思えず、漠然と悩んでいる部分である(悩みが漠然としている点からも、考えの整理ができていないことを示しているなと思う)。
• 当初は浅く広く事業全般を知ろうとしていたけど、割と今は上記の会のミッションに向けた知識のつけ方に向かっていて、まずはそれをしっかりやるべきだろうと思う。

全体的なふりかえり

学びの第2段階に入った（特にデータエンジニア領域）

• 1ヶ月めは、本に沿って一項目ずつ押さえていく学び方をしていて、これはPythonの全般的な使い方を学ぶという目的に合致していた。今月やった2冊めは、本の内容を全て学び切るというより、データ分析という目的に向け、本は参考として自分を分析できる状態にすべく統合的に学ぶ必要があったのだと思う。それが当初は理解できていなくて、メンターの方の言葉で気づかせてもらえて、学び方を変えることができた。
• 学び方は段階によって違うんだなと思った。学ぶ目的は、別に本の内容を完全に理解して再現できることでなく、その技術を使って自分のやりたいことをできるようになることである、という根本的なことを認識することができた。
• まだ第3段階、第4段階とあると思う(例えば、今はまだできていないけど、関数の中身がどのように書かれているかのぞいてみるとか、他の人のコードを読んで書き方を学ぶとか)ので、学ぶ方法も深化していけたらいいと思う。

3領域が融合し始めた

• 統計学で学んだ分布をPythonで書いてみたり、実際のデータを使って分析し始める等の変化があった。1ヶ月目では完全に各分野を分けて学んでいる状態だったのが、それらの知識を統合し始める段階に入ってきた。知識はそれ単体で持っているよりも、自分の中で有機的につなげることができると面白くなってくる。
• 今の立場は、各領域の専門家に比べると知識が浅く広く必要になる立場で、自分がどういう方向に向かっていくか意識しないと中途半端になる可能性もあると思うけど、この立ち位置ならではの面白さもありそうだなと感じた。

学習に入る前の状態

• データ分析・プログラミングとも未経験で、全く別分野の仕事をしていた
• 休日に趣味として少し勉強していた
• データ分析は、本当に基本的な統計の本を何冊か読み、当時触っていたデータが時系列データだったので、それに必要な専門書を数冊斜め読みした
• プログラミングは最初Pythonを勉強していたけど、具体的にデータ分析ができるレベルになるのはなかなか難しいと感じ、途中からRを使うようになった
• 手元のデータを実際に触ってみて、わからなくなったら参考書に戻って、という繰り返しをしていた

1ヶ月目にしようとしたこと

大まかには、下記3領域について¹

• 事業ドメイン領域
  事業に関し、社内／外部・競合／ユーザーの概要について理解する

• データサイエンス領域
  基礎的な統計知識を身につける　：　「基礎統計学Ⅰ 統計学入門」
  データ分析の概要を掴む　：　「データサイエンティスト養成読本」

• データエンジニア領域
  Pythonの基本的な文法の使い方を習得する　：　「詳細!Python3入門ノート」

結果、できたこと

事業ドメイン領域

• 事業の概要についてお聞きした。
• ユーザー側にいた時にはわからなかったサービスの現状や課題、目標を知ることができた。ただ、今知っているのは本当に概要のまとめで、もっと事業ドメインの知識やその肌感覚を知らないと、仮に分析手法が身についたとしてもできるのは表面的な分析になってしまうだろうと感じた。
• 今後、特にディレクターの方が、日々何に取り組んでいるか、具体的に何を解決しようとして今何を考えているのかを知ることで、自分の中の理解を深めたい。CSの方が日々どんな問合せを受けているかという点もデータの宝庫だと思うので、お話をお聞きしたいと思った。

データサイエンス領域

「基礎統計学Ⅰ 統計学入門」

• 原則毎日1時間、読書会をしていただいた。1冊の1/3くらいまで進んだ。自分で読んで理解した内容を言葉にしたりホワイトボードに書いたりして、逆に理解できなかった部分を教えていただくような形式で進めた。読書会後、内容をまとめていると、実は理解できていなかったことに気づいて考え直すこともしばしばあった。
• 今までは、初学者向けの本を数冊と、趣味でやっていた分析に必要な部分の本を読んでいるだけだったので、この本によって網羅的に知識を身につけることができると思う。
• 統計学的にでなく数学的に理解ができず時間がかかった部分があったので、微積や行列など、統計に関連する部分の復習をしたい。

「データサイエンティスト養成読本」

• 読んで、不明な点を調べてレポートにまとめ、それに対しレビューしていただく形で進めた。3章分。データ分析の流れや各段階での注意点、データベースについて等。
• 本で解説している用語に対し、その解説内で出てくる単語がわからないという状況だったので、調べる中でおぼろげにデータ分析の世界が見えてきたような知識レベルにいる。実際に分析をやっていくことで、こういうことを言っていたのかと理解できるようになるのではないかと思っている。
• 分析結果の表現はその意図がなくても恣意的になってしまうので、自身に対する健全な猜疑心が大事という文が印象的だった。確かに、導いた結論を象徴している部分に注目しがちになるので、気をつけたいと思った。

データエンジニア領域

「詳細!Python3入門ノート」

• 写経してjupyter notebookに章ごとにまとめ、レビュー（不明点についての回答やコードの書く際の注意点など）していただく形で進めた。一応1冊最後まで一通りやった。
• 前半は以前に自分で学んでいた内容と概ね重なっていたが、後半ジェネレータやクラスの辺りは初見の部分があり時間がかかった。まだ腹落ちした感覚がない部分もあるけど、何度も触れることで頭の中にその分野の回路ができるので、定期的に復習するようにしたい。

全体的な感想

• 学習に対して、1ヶ月はあっという間だった。もう少しスピードを上げていきたいと思いながら、この業界にいる人はおそらく身についているのが当然なのであろうGitやシェルの使い方など、基本的な部分で引っかかって時間を食うことが多かった（自分で調べて解決する力が必要なので、無駄ではないとは思う。また、ごく基本的な部分しかわかっていないので、もっと習熟する必要がある）。

• 20代の時間を別分野の事に使ってきたので周りの方との差があるのは当然で、焦りはあるけれど、毎日今の自分にできる、自分の力を伸ばすためにできることは何か考えて、それに取り組み続けるしかないと思う。やりたいことはいっぱいある一方、1日で進むのは微量でもどかしいけれど、3ヶ月後、1年後の自分に期待するわくわくする気持ちがあって、自分は学び続けることができることを知っているので、がんばりたい。