1. はじめに
この記事は タダの2年目 Advent Calendar 2023 の記事です。めちゃくちゃポエムです。
今の自分なりの感覚をメモして、「頑張れ自分」のエールを送るポエムでございます。
- 初稿: 2023/12/11 (配属されて2週間くらい)
- 最終更新日: 2023/12/18
きっかけ
転職してfirst projectで1mmも知らないHadoop/Spark処理のアーキテクチャのToBeについて、「論点を出せ」とかいうわけわからんPjtに放り込まれたついでに、脳みそを言語化してみる。
(本当に飲み会きっかけな話)
真面目な話
- 色々な意味で ("色々") 本当に貴重な体験をしていると思うので、今感じていることをきちんと残しておきたい。
- 誰も議論の軸を知らない中で、言い過ぎない AND 建設的な提案を試みる AND 文脈の知識が不足している 中でバランスを取りながら仕事を進めるための行動基準を、今の自分なりに言語化したい。
※ めちゃくちゃ主観で、随時アップデートが必要な内容です。
懺悔
ほんとはLLM系の話を書きたかったんや...なんでこんなポエムを話しているんや...
2. まずは結論
この記事で書く個人的ポイントは、次の3つ。
上記ポイントをやり切るための個人的capabilityは、次の2つ。
- 適度に黙る & いつでも素人のように質問する
- 知らないトピックの勉強にチャレンジして、自分なりに学ぶことに慣れる
3. 状況説明
これまでの経験:
- 大学・大学院:
- 因果推論寄りの統計解析
- 個人的な学習で基礎的な機械学習・DeepLearning・Transformers系の話, ベイズ推論
- 社会人~1.5年目:
- AWSのコスト最適化の文脈で
- CloudWatch, CloudTrail周りのログ系の話
- 課金管理・コスト低減措置の話
- AWSを利用したData Science Capabilityの文脈で
- SageMaker周りのData Science Architecture系の話
- 純粋なData Science系の文脈で
- Analytics/Data Scienceのビジネス適用の話
- Skill Building系の話
- AWSのコスト最適化の文脈で
ぶっこまれたPjt:
- Hadoop/Spark処理のアナリティクス・アーキテクチャ改善の"論点"の整理
(うわああ、開発しましょうとかじゃなくて、議論のポイントの整理とかいう、くそ上流ふわふわ案件だああああ、しかも何も知らねええええ)
4. 各種ポイント
a. 人の話を聞く
文脈がわからないと何も言いようがないので、どんな些細なミーティングも自分にとっては宝の山。とにかくメモを取る + 自分の思考回路的に疑問に思ったら、「ど素人で追いつけていないっていう文脈での質問なんですけど、なんでそういうこと or 状況 or 仕様になってるんですか？」とか言いながら、とにかくキャッチアップする。その文脈で１番の素人は自分なのだから、聞いちゃえばいいんですよね。むずかしいことは何もない。
個人的便利な接頭語シリーズ
(最初だと言いやすい)
- お勉強/後学のために教えてほしいんですけど
- 知識不足で純粋に教えてほしいんですけど
- 理解が追いついていないんで教えてほしいんですけど
- 素朴な疑問なんですけど
- 今更かよって話かもしれないですけど
(Pjt配属からしばらく経ってもいいやすい)
b. 再現可能なFactを積み重ねる
脳筋なので言い切ってしまいます。とにかく以下を走りきって、「自分の中でも検証したし、公式にもコメントもらったよ」の状況を目指すのが早い気がします。
- 1次ソースをあたって、公式ドキュメントを読む
- 実際に環境をつくった上でコードを書く
- (可能であれば) コードをサポートにぶつけて、とっとと回答をもらう
少なくとも、実際にコードを書いて実際に検証すれば、その場のFactになります。 とっととFactを作らないと議論が動かないし、コードが汚かろうがなんだろうがとにかく手を動かすことで仕事が前に進むきっかけを作れるはずです (そう信じてる)。そして、「〇〇の条件下で、このような処理を行った際、この挙動となりました」はいつでも言い過ぎにならないというのも良いところ。検証条件・前提を伝えた上でFactを重ねれば、常に自分の努力は価値の礎になるわけです (そのstatementが価値を生むような範囲であれば)。
動くコードを作るためには、日本語でググらず、公式ドキュメントのsyntaxを確認しましょう。公式に準拠したコードはたいてい動きます (脳筋)。
(Factが少ない？それは基本ダメな案件っすよ)
c. 己の腹落ちする所までやり切る
どうせ君がプレゼン or 報告資料を作る羽目になるのだから、きちんと自分の言葉で話せるようになっときましょうや、というお話でございます。(君がやったことは、君がスライド作るくらいの気概は持とうね)
最近、「真に正しいかどうか」という軸ではなく、「自分にとって納得しているか？」のほうが良い問なのでは？という気がしています。 理由は、真に正しいかどうかは自分で判断することは難しいけれど、納得感は自分に問えば秒で答えが返ってくるからです。真に合っているかどうかはかなり難しい問いで、短期間の仕事では答えを返すことが困難です。一方、自分が納得しているか、それとも納得していないかは、自分の気持ちに聞けば1秒で答えが返ってきます。そして、自分が納得していない/腹落ちしていない理解は、資料に落とすと大抵ゴミです。
自分の腹落ちする所まで、きちんと言語化しましょう。言語化できないなら、コードを書いたりPoCを進めてfactを集めましょう (脳筋)。
5. どうすれば、わからないなりに動く AND 求めらるものを返せるか？
時に黙って、質問せよ
適度に黙るスキルは、すごく大事だと思っています。
前提: 自分にとってわからないことを進める作業はストレスフル→ 下手に話すと、刺々しい内容になったり、でしゃばった内容になりがち。下手なことを言わずに、事実と推論に基づく意見・質問を口に出せ。
PoCに慣れよ
脳筋です。飲み会で感じた感想は結局ここなのです。わからないなりに手探りでコードを書いたり、意味不明なドキュメントを読む経験は、結局慣れでしかないと思います。
やるしかないので、暇なうちに練習しましょう。練習不足なら、人的ネットワークを借りましょう。経験もなくてネットワークもない人は、生成AIを頼りましょう。
個人的に、以下のような遊びは気づかぬうちに自分の支えになっているんだろうなあと思います。
- 適当にプログラミング/分析本を買って、写経しつつ、コードを一部書き換えて気になることを検証する。
- プログラミング/分析本のイチャモンをつける (大学院のとき、今井先生の名著に文句言ってたのおこがましすぎる)。
- 個人的遊びで気になることを遊びで作ってみる。
- 最近、Llama-2を使って遊びをゆっくり進めてる。
とにもかくにも『例示は理解の試金石』なので、自分の理解を確かめる具体的ななにかを自分で作ることがすべての始まりなんじゃないかなあと、改めて思う今日このごろなのです。
コンサルの言葉で言うと「仮説を検証する」とかになるんでしょうけど、そんな仰々しいことは言わずに、単にアイデアをみんなが見れる形にすれば良いだけなんじゃないかなあと。
検証されていないアイデアを疑え
またまた脳筋です。人は意外と雑な推論を行うものです。「何がfactなんですか？今手元で見せてもらうことって可能ですか？」と問えば死ぬアイデアは多数あると思います。真に事実かどうかは難しいけれど、体験として実現・共有可能かどうかはすぐ問うことができます。体験へと昇華できないアイデアはエビデンスとして弱いから、どんどん殺していきましょう。たとえ、相手が誰であっても、「それほんとに顧客に言えるレベルなんですか？腑に落ちてないなら、ちゃんとfactとして価値を体験にしましょうよ」と提案しちゃいましょう。
まとめ
PoC主義でアンチ・"コンサル" (机上の空論だいっきらい) の人間からすると、やっぱり "コンサルティング" は好きになれませんでした。一方で、机上ではないトピックを語るコンサルティングはとても大好きなんです。なかなか目には見えない価値を、言葉や体験として共有可能にしていく試みを忘れずにお仕事していきたいです。
p.s.
数学ガールはいいぞ。『例示は理解の試金石』