Diary over Finite Fields

515ひかるの日記と雑文

技術書典7にて『scikit-learnでこなすPoCプロジェクト』を頒布しました

技術書典7にてPDFを頒布してきました。現在は Booth でも販売中です。

515hikaru.booth.pm

ちょっとこぼれ話をここには書きます。

Pipeline クラスを紹介する本ではない

もともと、scikit-learn の Pipeline を中心に据えた記事や本を書きたい、ということは考えていました。しかし、単に道具としての Pipeline クラスを紹介するだけでは足りない、という直感がありました。実際、本書は目次にこそ Pipeline という文字はありますが、タイトルには Pipeline という単語は出していません。この本は Pipeline の使い方を解説した本である、とは思われたくなかったからです。

実際、3 章に書いたように Pipeline の仕組み自体は極めて単純です。その仕組みやメソッドの実装を網羅的に解説したところで「どんな益が(PoCプロジェクトに)あるの?」という疑問には答えられません。その仕組みや実装内容自体に惚れ込んだわけではないのです。1

わたしが Pipeline クラスを "選んだ" のは、PoC プロジェクトを通して踏みぬいた地雷、見聞きした落とし穴を解決する手段として最適だと思ったからです。それは本文にも書いた、

  • 前処理(特徴量エンジニアリング)とコアの学習器は本来はまとめてひとつのオブジェクトであるべき
  • 前処理、学習器は可変であるべき

という 2 つの内容を実現するための手段として選んでいます。今回は "たまたま"2 scikit-learn の Pipeline クラスが選ばれただけで、上記の状態を実現できるのであれば手段はなんだっていいとさえ思っています。

だからわたしは先に課題、問題点に焦点を当て、第 2 章を書きました。どんな技術も課題に対して適用するものであり、技術が発達すれば自動的に課題が解決されるのではありません。よくあるコードで生じる問題に対し、 Pipeline クラスという技術を適用するという構成をとっています。

技術を紹介するだけの本にはしたくない

技術はそれ単独では何の意味もなしません。わたしは数学を学んでいる最中にそのことを痛感しました。正確には当時は技術ではなく、概念とか定義とかいうふうに呼ばれるものでしたが。

いわゆる純粋数学であっても、何かしらの問題意識がありその意識を前提にして様々な概念や手法が生み出されます。定義・概念が生まれたときは何かしらの課題を解決するための道具なわけです。いわんや、プログラミングをや。ソフトウェアもサービスも勝手にできるわけではありません。誰かが課題解決のために労力を払ったから存在しています。3

わたしは技術者ですが、常に課題に目を向けたいと思っています。課題を解決すること、それこそが技術者の使命だとわたしは思っています。技術を高めることも当然重要です。しかし、課題に対して適切に技術を適用できないのでは最終的には価値を提供できません。

こうした哲学が、本書を通じて少しでも表現できていたら、伝わっていたら、とても嬉しいなと思います。

おわりに

会社員になって初めて技術ブログ以上の粒度の文書を作りました。まとまった文書を作るのは大学の卒業レポート以来なので3年半振りくらいでしょうか。

実際に目の前で自分が書いたものが売れていくのはとてもうれしいことでした。買っていただいた方、本当にありがとうございました。

この本に関する宣伝記事はこの記事で終わりです。また何か世に出せるような文書を出したいなと今は思っています。


  1. わたしはこんな記事を書くくらい Pipeline クラスに惚れ込んでいます。しかし、このような複雑な問題が Pipeline クラスで解決できる課題であるとは一見では思えないでしょう。もっと Pipeline クラスの可能性を感じる情報をもっと増やしていくべきだと思っています。

  2. scikit-learn の Pipeline を実装した人が、どのようなモチベーションでそのクラスを実装したのかはわたしは知らないので、実は偶然ではなく必然なのかもしれません。わたしにはわかりません。

  3. 作りたいから作るという人も一定数居るとは思います。