Day 1講義の振り返り
前日に作成した講義ノートをもとに、Day 1 に行われた講義内容を振り返りました。
チームごとにそれぞれ約5分間で、講義ノートを参照しながら即興で説明しました。
アイディア創出
デザインスプリント
各チームごとにデザインスプリントを行いました。
デザインスプリントとは？
デザインスプリントは、GV（旧 Google Ventures）が提唱した「5 日間で課題の特定からプロトタイプ作成まで進める」問題解決メソッドで、新規サービス創出などに活用されます。(参考: https://www.intra-mart.jp/im-press/useful/design_sprint )
デザインスプリントの進め方
- 解くべき課題を見出す
今週直面した課題・問題・悩みを付箋に書き出します。
- お気に入り案の共有
各自1枚ずつ付箋を貼り、指差ししながら口頭で要点を説明しながら、類似のものは近くにまとめます。
1人が貼り終えたら次の人へ進めます。
- 無言投票
発言力の大きさや立場に左右されず、誰もが本当に良いと思うアイデアを平等に選ぶため、投票は無言で行われます。
参加者には2種類のシールが配られ、以下の基準で投票します。
- 赤丸（1枚）：「主観的に」最も心を動かされたアイデアに投票
- 黒丸（3枚）：「客観的に」最も優れていると判断したアイデアに投票
- How Might We（HMW）を考える
「どうすれば私たちは課題を解決できるのか？」を付箋に書き出し、上記と同様に共有・投票します。
- 解決策の発散
HMW を実現するための解決策を考え、同様に説明・投票します。
「付箋1枚につき1テーマ」など、より良い進め方についてメンターから助言を受けつつ、議論と選定を行いました。
講師中間レビュー
PRD作成に着手する前に、デザインスプリントで使用した模造紙を持参し、アイデアに対するフィードバックを講師から受けました。
PRD作成
中間レビューで得たフィードバックを踏まえてPRDを作成し、アイデアを具体化しました。
PRDとは？
PRDは、ある製品に関するすべての要求事項を含む文書であり、製品が何をすべきかを理解できるようにするために書かれます。(参考: https://en.wikipedia.org/wiki/Product_requirements_document )
講師レビュー
作成したPRDについて講師から講評と改善点の指摘を受け、次回以降のブラッシュアップ方針を整理しました。
データサイエンスハンズオン
牧垣さんに「データサイエンスハンズオン」についてお話ししていただきました。
データ分析の裏側にある地道な作業から、クラウド技術を駆使した大規模なデータ処理、そしてAI時代におけるデータサイエンティストの役割まで、示唆に富んだ内容が満載でした。
1.データの旅「ETLからELTへ」
データ分析の仕事は、データを集めてきてすぐに分析、というわけにはいきません。まず、データを「使える」形にするための旅が始まります。その代表的な流れがETLです。
- Extract（抽出）: 様々な場所（データベース、CSV、JSONファイルなど）に散らばるデータを抜き出します。これらのデータはまず、スケーラビリティに優れたオブジェクトストレージのような場所に集められます。
- Transform（変換）: 抽出したデータをそのまま使えることは稀です。エラー値の修正、フォーマットの統一、集計など、分析しやすいようにデータを「綺麗にする」作業を行います。参加者からも「データ分析で最も時間がかかるのが前処理」という声が上がるほど、ここは重要なステップです。
- Load（格納）: 綺麗になったデータを、分析の拠点となるData Warehouse（DWH）に格納します。講義では、Google Cloudが提供するDWHサービスであるBigQueryが、その強力な機能から「稼ぎ頭」と紹介されていました。
最近では、DWHの性能が非常に高くなったため、先にデータをLoadし、DWHの強力なSQL関数などを使ってTransformするELTという手法も主流になりつつあるとのこと。これにより、より柔軟なデータ活用が可能になるというメリットが語られました。
2.ビッグデータを捌く技術「分散処理とクラウド」
X(Twitter)ではかつて1秒間に1TBものログが流れていたという話もあり、現代のデータ量は個人のコンピュータで扱える範囲を遥かに超えています。そこで重要になるのが、膨大な計算を複数のコンピュータに分担させる分散・並列処理の技術です。
この複雑な処理をプログラマーがより簡単に扱えるようにするのが、今回ハンズオンで利用したApache Beam（分散処理プログラミングのフレームワーク）とDataflow（実行基盤サービス）です。これらのツールを使えば、開発者は「個々のデータをどう処理するか」という本質的なロジックに集中でき、面倒なサーバーの割り当てや管理は自動で行ってくれます。まさにクラウド時代のデータ処理の強力な味方です。
3.ハンズオン実践「不動産価格は予測できるか？」
講義の後は、実際の不動産売買データ（約550万行！）を使ったハンズオンが行われました。Pythonの有名ライブラリであるPandasでデータを前処理し、Scikit-Learnを使って機械学習モデル（線形回帰モデル）を構築し、住宅価格の予測に挑戦しました。
結果は…「そう簡単には当たらない」。特に、高価格帯の物件で予測が大きく外れる傾向が見られました。
しかし、ここからがデータサイエンスの面白いところ。「なぜ当たらなかったのか？」を考えるフェーズが始まります。
- 訓練データに偏りがあるのではないか？
- 銀座のような極端な土地（外れ値）を除くべきか？
- そもそも線形回帰ではなく、Random Forestなど別のモデルを試すべきでは？
このように、期待通りではない結果から仮説を立て、検証を繰り返すプロセスこそがデータサイエンスの本質なのだと実感しました。
4.Q&Aから見る「データサイエンティストの思考」
セッションの最後に行われた質疑応答では、データサイエンティストの思考に触れる貴重な機会となりました。
良いデータサイエンティストとは？
星の数ほどある手法から、課題に対して最短で適切なモデルを選択し、構築できる人物。そのためには、まずデータの分布、平均、欠損値の割合などを観察し、データが持つ特性を正確に把握する着眼点が重要になるとのことでした。
AI時代のデータサイエンティストの役割は？
「LLMの登場で仕事はなくなる？」という問いに対しては、「作業は楽になるが、仕事は楽にならない」という回答が印象的でした。LLMに任せる範囲を正しく認識し、出てきた結果が期待通りか、なぜそうなったのかを深く考察する能力が、これからのデータサイエンティストにはより一層求められます。AIを使いこなし、その先を考える思考力が価値になるのです。
このハンズオンを通じて、データサイエンスが単なる機械学習技術ではなく、データ収集・加工、ビジネス課題の発見、仮説検証までを網羅する総合的な学問だと改めて学びました。特に、地道な前処理の重要性やクラウド技術の活用、そして何よりも「なぜ？」と問い続ける探究心こそがデータと向き合う上で不可欠だと痛感し、大変有意義な時間となりました。
開発の基礎、ハマりどころ
湯川さんに「開発の基礎、ハマりどころ」をお話ししていただきました。
この講義では、プログラミング技術そのものだけでなく、開発プロジェクトを進める上で誰もが一度は経験するであろう「ハマりどころ」と、それを乗り越えるための実践的なノウハウが凝縮されていました。
1. 「毎週進捗を出す」
開発において最も大切なことの一つは、「継続的に進捗を出すこと」です。そのためには、意図的に締め切りを設定することが非常に有効であると語られました。
- Snippetsの習慣化: 毎週のチームミーティングなどで、以下の3行を共有するシンプルな習慣です。
- 今週やったこと
- 来週やること
- 困っていること
- この簡単な報告（断片＝Snippet）を習慣化するだけで、自身のタスク整理になるだけでなく、チームメンバーが互いの状況を把握し、助け合うきっかけが生まれます。
- タスクは5営業日で: 壮大な計画は、結局どこから手をつけていいか分からなくなりがちです。WBSを作る際は、1つのタスクを5営業日程度で完了する粒度に分割することが推奨されました。これにより、着実に達成感を得ながらプロジェクトを進めることができます。
2. 「さっさと作る vs ちゃんと設計する」
「後のことを考えて完璧に設計すべきか」「いや、まずは動くものを早く作るべきか」という議論は、開発現場で常に起こります。今回の講義では、特に初心者が陥りがちな「セカンドシステム症候群」（最初の成功体験から、次作で過剰に機能を盛り込みすぎて失敗すること）にも触れつつ、現実的なアプローチが紹介されました。
それは、「仮のインターフェースを決めて、全体をざっと作る」という方法です。
まず機能間の連携部分（インターフェース）だけを仮決めし、中身は不完全でもいいので、全体の骨格を素早く作り上げます。これにより、プロジェクトの全体像を早期に掴むことができ、手戻りを最小限に抑えながら、各機能の詳細を詰めていくことができます。
3. すぐに質問
「分からないことがあればすぐに聞く」のは重要ですが、その前にワンクッション置くことで、質問の質と自己解決能力が格段に向上します。
- 15分の法則: 問題に直面したら、まずは15分間、自力で調べてみる。それでも解決の糸口が見えなければ、遠慮なくチームに質問する。このルールは、「自分で考える力」を養いつつ、無駄な時間で悩み続けることを防ぐための、非常に効果的なガイドラインです。
4. 最大のハマりどころ「XY問題」とは？
今回のセッションで最も強調されていたのが、この「XY問題」です。これは、質問する際に陥りがちなコミュニケーションの罠です。
- X: 本当に解決したい、本質的な課題。
- Y: その課題を解決するために、自分が思いついた表面的な手段。
多くの人は、本質的な課題Xを伝えずに、自分が考えた手段Yのやり方だけを質問してしまいます。
【例：ファイル拡張子を取り出したい】
- X（本質的な課題）: ファイル名から拡張子を取り出したい。
- Y（自分で考えた手段）: とりあえず文字列の末尾3文字を切り取ればいいだろう。
- ダメな質問: 「文字列の末尾3文字を取り出すにはどうすればいいですか？」
この質問では、回答者はその方法しか教えられません。しかし、もし拡張子が「.jpeg」のように4文字だったら、この方法は失敗します。
【良い質問】
- 「ファイル名から拡張子を取り出したいのですが、何か良い方法はありますか？」
このように本質的な目的Xを伝えることで、回答者はより的確で、堅牢な解決策を提示できます。これは質問する側だけでなく、回答する側も「この人は本当は何がしたいんだろう？」と相手の言葉の裏を読み、ユースケースを考える意識を持つことが重要だと語られました。
この講義では、開発とは単にコードを書く行為ではなく、計画、記録、見直し、そして何よりも人とのコミュニケーションの上に成り立つ知的生産活動であることを改めて教えてくれました。特に「Snippets」による進捗の可視化と、「XY問題」を意識したコミュニケーションは、明日からでもすぐに実践できる強力なツールです。技術力だけでなく、プロジェクトを円滑に進めるための「現場の知恵」を学ぶ、非常に有意義な時間でした。
