気がつくと初期設定だけで1日終わる話
Pythonプロジェクトを始めてすぐの10分間で、何から手をつければいいのか…うーん、毎回迷ってしまう。最初に手際よくセットアップしておけば、その後も一貫性が保てるはずなのに、実際は「どこまで準備したら良いんだろ?」と逡巡することばかりだ。ま、いいか。ここでは初日から活用できる有益なユーティリティツールを3つ紹介したいと思う。ちなみに、この画像は自分でDALL-E使って作ったやつなんだけど…あんまり関係ないか。
Medium会員じゃないなら_[こちらで無料で読むこともできる]_けど、それはさておき──開発者って案外、全体の10–15%もの時間をプロジェクトの初期環境設定とかボイラープレートコード作成に費やしているっていう調査結果があるらしい。一年単位で考えると約1ヶ月半くらい?えっと…ちょっと信じたくないけど、自分でも「また同じようなこと繰り返してる」って思い当たる節がある。
空っぽのフォルダ見て、「srcディレクトリ作った方が良いかな」とか、「my_packageディレクトリのほうが雰囲気出る?」みたいに悩む場面、多分誰しも経験あると思う。そしてテストとかドキュメントとか依存関係管理とか…考え出すときりがなくなって結局進まなくなる。「ブランクキャンバス症候群」なんて呼ばれてたりする現象、本当に存在するみたい。そのせいで生産性下がっちゃうという話も耳にするし。
> セットアップ作業ばかり延々とやっていると、新しいアイデアへ向かう勢いごと失われちゃう危険性がある
もしPythonプロジェクト立ち上げ時の煩わしいフォルダ構成や繰り返し設定――それ全部すっ飛ばせたらどうだろ?いや、本当にそうだったら最高なのにな…。シンプルなコマンドひとつ叩くだけで整然とした構造のコードベースを自動生成できれば、大抵の場合圧倒的に効率的になる。それ専用に設計されたもの――つまりプロジェクトスキャフォールディングツール、これこそ答えなんじゃないかな、と最近よく思う。(あれ、自分だけ?いや多分そんなことない。)
Medium会員じゃないなら_[こちらで無料で読むこともできる]_けど、それはさておき──開発者って案外、全体の10–15%もの時間をプロジェクトの初期環境設定とかボイラープレートコード作成に費やしているっていう調査結果があるらしい。一年単位で考えると約1ヶ月半くらい?えっと…ちょっと信じたくないけど、自分でも「また同じようなこと繰り返してる」って思い当たる節がある。
空っぽのフォルダ見て、「srcディレクトリ作った方が良いかな」とか、「my_packageディレクトリのほうが雰囲気出る?」みたいに悩む場面、多分誰しも経験あると思う。そしてテストとかドキュメントとか依存関係管理とか…考え出すときりがなくなって結局進まなくなる。「ブランクキャンバス症候群」なんて呼ばれてたりする現象、本当に存在するみたい。そのせいで生産性下がっちゃうという話も耳にするし。
> セットアップ作業ばかり延々とやっていると、新しいアイデアへ向かう勢いごと失われちゃう危険性がある
もしPythonプロジェクト立ち上げ時の煩わしいフォルダ構成や繰り返し設定――それ全部すっ飛ばせたらどうだろ?いや、本当にそうだったら最高なのにな…。シンプルなコマンドひとつ叩くだけで整然とした構造のコードベースを自動生成できれば、大抵の場合圧倒的に効率的になる。それ専用に設計されたもの――つまりプロジェクトスキャフォールディングツール、これこそ答えなんじゃないかな、と最近よく思う。(あれ、自分だけ?いや多分そんなことない。)
フォルダ迷宮と地味なファイル地獄
このブログでは、Pythonプロジェクトを始めるときに使える3つのツール――_**Cookiecutter**_、_**Kedro**_、それから_**PyScaffold**_について取り上げていこうかなと思う。まあ、特にまとまった話じゃないけど、それぞれ特徴とか利点、ちょっと気をつけたほうがいいこと、それからどんな場面で役立つか…あー、ここで一旦脱線するけど、自分も最初は「名前が似てて混乱するな」って思った記憶がある。ま、ともかく本筋に戻して――これらのツールにはそれぞれ独特のカラーというか持ち味があって、本当にプロジェクトによって向き不向きが違うんだよね。
---
## 課題:なぜプロジェクトセットアップは手間がかかるのか
最初に自分がPythonプロジェクトを立ち上げようとした時なんだけど、とりあえず毎回同じようなフォルダ構成をまた一から作っている気がして妙な既視感ばっかりだった。例えばさ、**_src/_**, **_tests/_**, そして _**docs/**_ みたいなディレクトリをぽちぽち手動で作成したりするわけ。でもそこだけじゃ終わらなくてさ……途中で「あれ? __init__.py もう書いたっけ?」とか迷子になるんだよね。えっと、そのあと _**requirements.txt**_, _**setup.py**_, あと最近だと _**pyproject.toml**_ とかも準備しないといけないし、更には _**.gitignore**_ を忘れて後悔したことも何度あったことやら…。こういう繰り返し作業って思いのほか時間泥棒だから、「さあ新しいもの作るぞ!」って意気込んでも、その前段階ですでに消耗してしまった経験――正直、一度や二度じゃないんだよなぁ。
---
## 課題:なぜプロジェクトセットアップは手間がかかるのか
最初に自分がPythonプロジェクトを立ち上げようとした時なんだけど、とりあえず毎回同じようなフォルダ構成をまた一から作っている気がして妙な既視感ばっかりだった。例えばさ、**_src/_**, **_tests/_**, そして _**docs/**_ みたいなディレクトリをぽちぽち手動で作成したりするわけ。でもそこだけじゃ終わらなくてさ……途中で「あれ? __init__.py もう書いたっけ?」とか迷子になるんだよね。えっと、そのあと _**requirements.txt**_, _**setup.py**_, あと最近だと _**pyproject.toml**_ とかも準備しないといけないし、更には _**.gitignore**_ を忘れて後悔したことも何度あったことやら…。こういう繰り返し作業って思いのほか時間泥棒だから、「さあ新しいもの作るぞ!」って意気込んでも、その前段階ですでに消耗してしまった経験――正直、一度や二度じゃないんだよなぁ。
Comparison Table:
ツール名 | 目的 | 主な特徴 | 使用シーン | 利点 |
---|---|---|---|---|
Cookiecutter | プロジェクトテンプレート生成 | 柔軟なJinja2ベースのテンプレート機能 | 多様なプログラミング言語やプロジェクトに対応可能 | 迅速なプロジェクトスタート、カスタマイズ性が高い |
Kedro | データサイエンス向け構造化プロジェクト管理 | 再現性を重視したデータパイプライン設計支援 | 大規模データ処理やMLOpsに最適 | 信頼できるモデルのデプロイメントを実現する |
PyScaffold | Pythonパッケージ作成効率化ツール | 標準的なディレクトリ構造と設定ファイルを自動生成する機能を持つ | オープンソースライブラリや社内向けパッケージ作成時に有用 | 手動より圧倒的に効率化され、初心者にも優しい |
比較結果総括 | ||||
各ツールの特性と適応範囲が異なるため、特定のニーズに応じて使い分けることが重要。 |

Cookiecutter:型紙から始まる自由設計
セットアップ作業のオーバーヘッドって、なぜか実際の開発そのものよりも疲れる気がする。いや、これだけで一日終わることない?まったく…何やってんだろう、自分。でも本題に戻すとさ、
## Cookiecutter:**カスタマイズ自在なるプロジェクト設計図**
Cookiecutterはコマンドラインからテンプレートベースでプロジェクトを生成するためのツールで、その柔軟性たるや評判通りという感じ。まあ、「型紙」って言葉が妙にしっくり来るんだよね。Python以外にも使えるとか聞いたけど、本当なのかな?少なくとも、多種多様なテンプレート――例えばシンプルなPythonパッケージとか複雑怪奇なWebアプリケーション、それからデータサイエンス向けなんかも――ちゃんと用意されている。その上、自分自身でゼロから独自テンプレートを作成して好き勝手カスタマイズできる点もちょっと面白いと思う。ああ、ごめんつい脇道それたけど…つまり、このツールは思った以上に奥が深い。
**ステップ1:Cookiecutterをインストールする**
まずはターミナルにて次のコマンドを叩くことでライブラリ導入、と。この辺は特別難しくないかな。
pip install cookiecutter
えー、シンプルすぎて逆につまらないくらい。
**ステップ2:Cookiecutterテンプレートを探す**
- _**[GitHub]**_ で適したテンプレート選び…。ふう、ときどき膨大すぎて目移りするけど(気力切れそう)。この例では汎用的なPython開発向けの _**[pypackage template]**_ を利用してみようと思う。
**ステップ3:最初のプロジェクト生成へ進む**
- プロジェクト作成先ディレクトリへの移動…。新しいプロジェクト置きたい場所までcdコマンド等で辿る必要あり(例:)。ここでもちょっと面倒になって途中お茶飲みに行っちゃったりね。でも仕方ない。本筋戻ります。
## Cookiecutter:**カスタマイズ自在なるプロジェクト設計図**
Cookiecutterはコマンドラインからテンプレートベースでプロジェクトを生成するためのツールで、その柔軟性たるや評判通りという感じ。まあ、「型紙」って言葉が妙にしっくり来るんだよね。Python以外にも使えるとか聞いたけど、本当なのかな?少なくとも、多種多様なテンプレート――例えばシンプルなPythonパッケージとか複雑怪奇なWebアプリケーション、それからデータサイエンス向けなんかも――ちゃんと用意されている。その上、自分自身でゼロから独自テンプレートを作成して好き勝手カスタマイズできる点もちょっと面白いと思う。ああ、ごめんつい脇道それたけど…つまり、このツールは思った以上に奥が深い。
**ステップ1:Cookiecutterをインストールする**
まずはターミナルにて次のコマンドを叩くことでライブラリ導入、と。この辺は特別難しくないかな。
pip install cookiecutter
えー、シンプルすぎて逆につまらないくらい。
**ステップ2:Cookiecutterテンプレートを探す**
- _**[GitHub]**_ で適したテンプレート選び…。ふう、ときどき膨大すぎて目移りするけど(気力切れそう)。この例では汎用的なPython開発向けの _**[pypackage template]**_ を利用してみようと思う。
**ステップ3:最初のプロジェクト生成へ進む**
- プロジェクト作成先ディレクトリへの移動…。新しいプロジェクト置きたい場所までcdコマンド等で辿る必要あり(例:)。ここでもちょっと面倒になって途中お茶飲みに行っちゃったりね。でも仕方ない。本筋戻ります。
テンプレ選びで迷子?使い方メモ的手順
g. , cd
)。あ、今ちょっとディレクトリ移動のコマンド書こうとしてたけど…まあ、そのまま進もう。で、選んだテンプレート(_Fig1_)に対してCookiecutterを走らせるには——これが本題だったっけ?——
cookiecutter https://github.com/audreyr/cookiecutter-pypackage.git
ってやるだけ。でも、データサイエンスプロジェクト用のテンプレートも試してみたい人いるよね?なんか飽きてきたとか思ったらさ。
pip install cookiecutter-data-science
ccds
ほら、こんな感じで。えーと、それから…プロンプトに答える場面が来る。その時はテンプレートの設定内容にしたがって新しいプロジェクトをカスタマイズするために質問に一つひとつ答えていけばいいと思う。あれ…ちゃんと全部説明できてるかな…。
![出典: Author | Fig 1: 標準的なPythonパッケージ | Fig 2: データサイエンスプロジェクトのテンプレート]
### 利用タイミングについて
Cookiecutterって、ほんと多用途だと言われているんだよね。でも「言われている」だけじゃピンとこないこともあるし…まあ実際、自分で使ってみるしかわからない部分も多い気がする(疲れるけど)。特定かつカスタマイズされたプロジェクト構造が必要な時とか、「専門的なツールじゃ対応できないぞ」みたいな瞬間にも助かったりするし、とくにPython以外でもアプリケーション作成を標準化したい場合なんかはチーム全体で導入してたりするっぽい。ああ、そうそう、一部ではコーディング規約を守らせたり初期ファイルを抜けなくセットアップさせる目的で利用されていて、このおかげでレビュー段階のやり取りが減ったという話もちらほら耳に挟むこともあるんだよね。不思議。それとも当たり前なのかな……いや、大事な点なので戻すけど、とりあえず色々応用効くツールです。
![]
---
![出典: [Github Repo]]
## Kedro: 構造化されたデータサイエンスプロジェクト
うーん、この辺になると急に専門臭く感じちゃう人もいると思うけど……Kedroは今データサイエンスとか機械学習界隈ですごく注目されていて、それこそ高度に構造化されたフレームワークという立ち位置になっている気がする。不規則になりやすいデータワークフローを再現性・保守性・共有可能性まで見据えたパイプラインへ変換できちゃう仕様だから、生産レベル向きの手法として推されても無理ない感じ。ま、べつに推しじゃなくてもいいし。
**Step 1: Kedro のインストール**
pip install kedro
**Step 2: 新しいKedroプロジェクトの作成**
希望するディレクトリへ移動した上で、
kedro new
CLI経由で何個か質問飛んできたら、それぞれポチポチ回答しておく。一瞬戸惑うかもしれないけど大丈夫、多分慣れるから。その中には「プロジェクト名:人間にも読みやすい名前(例:e.g)」みたいなのも含まれていたりするので適当に工夫して入れておけばOKっぽい。

みんな大好きデータサイエンス流Kedro現象
えっと、リポジトリ名についてだけど…あれ、なんでこんなに名前考えるの面倒なんだろうね。例として「my-data-pipeline」っていうのが挙げられてるけど、本当にこれでいいのかな?まあ、それは置いといて、プロジェクトフォルダーやGitリポジトリの名前も一緒なんだって。ふう…。ちょっと余談だけど、最近パソコンの動きが遅い気がする。まあいいや、話を戻そう。
あと、Pythonパッケージ名についても決めなきゃいけないんだけど、「my_data_pipeline」とか書かれててさ、もう少しオシャレな名前にしたくなる衝動。いや、本当はどうでもいいけど、一応メインとなるパッケージだしね。でも現実的にはシンプルなのが無難だったりするんだよなあ。うーん…。
それからスターターテンプレートについても選べるらしくて、「spaceflights」みたいなサンプルから始めるのもアリらしい。ちなみに学習目的ならそっちがおすすめされているらしいけど、自分でゼロから組む根気は正直もう残ってないかも。ま、いいか。
……何を書いていたんだっけ、とにかく、この辺りをちゃんと決めておけば後で困らないと思う、多分ね。
あと、Pythonパッケージ名についても決めなきゃいけないんだけど、「my_data_pipeline」とか書かれててさ、もう少しオシャレな名前にしたくなる衝動。いや、本当はどうでもいいけど、一応メインとなるパッケージだしね。でも現実的にはシンプルなのが無難だったりするんだよなあ。うーん…。
それからスターターテンプレートについても選べるらしくて、「spaceflights」みたいなサンプルから始めるのもアリらしい。ちなみに学習目的ならそっちがおすすめされているらしいけど、自分でゼロから組む根気は正直もう残ってないかも。ま、いいか。
……何を書いていたんだっけ、とにかく、この辺りをちゃんと決めておけば後で困らないと思う、多分ね。
答えはCLIの中に、Kedroプロジェクト開始まで
【出典: Author | Fig 3: Structured data science projects】
---
### いつ使うべきか?
データサイエンティストが、なんていうか…整理されていないノートブックとか再現性低めのスクリプトに手を焼いている時、Kedroって選択肢が浮上することが多い。ああ、でも別にこれだけじゃなくて…まあ、その話は置いておく。Kedroはデータサイエンス領域でソフトウェアエンジニアリング的な進め方を推奨している感じでさ、信頼できるモデルのデプロイメントにはかなり大切らしい。
自分のローカルPC上だとうまく動いてたのに、本番環境になると不思議とうまくいかない——そんな「え?」って瞬間から、「どこでもちゃんと動作する」状態へと移行しやすくなる、とよく言われてる。でも実際どうなのかな…。MLOpsや規模の大きなデータプロジェクトとも相性は良好っぽいし、うーん、自分も前試したことあるけど便利だった記憶がある。本筋戻るけど、このツールはそういう現場で真価を発揮すると思う。
![Source: [Github Repo]]
## PyScaffold: Pythonパッケージ作成を効率化
PyScaffoldという名前からしてもう目的が明快なんだけど——つまり構造化されて配布もしやすいPythonパッケージづくり、それだけに集中して設計されてる。ちょっと話逸れるけど、最近パッケージング基準も色々厳しくなってきたしね。PyPI(Python Package Index)への公開や他のPython環境でライブラリとして利用できるようなプロジェクト構築にも適応しやすいんだとか。
しかもセットアップ時点でsetuptools_scmみたいな自動バージョニング用ツールも普通に統合できたり、Sphinxによるドキュメント生成までサポートしてたりして…ほんと至れり尽くせり(まぁ全部使うとは限らないけど)。実は最初Sphinxって何?となった覚えあるけど、慣れると便利だね。それはともかく、とにかく必要不可欠なツールとの連携もしっかり考えられているから、無駄な手間を減らしたい人にはありがたい存在だろうなと思う。

PyScaffoldでパッケージ配布したい欲求爆発
PyScaffoldって、まあ正直なところ、何かの拍子に知ったんだけど。_**pyproject.toml**_と_**setup.cfg**_をセットで生成してくれるし、標準的なsrcレイアウトも勝手に用意される。いや、「勝手に」って言い方はちょっと雑かな。でも本当にテストとかドキュメント作成のためのプリセットまで全部揃えてくれるから、最初は「えっ?」と思うくらい親切なのだ。
**ステップ1: PyScaffoldのインストール**
pip install pyscaffold
なんかね、このコマンド入れただけで全て始まる気がしてきちゃうんだよね…。
**ステップ2: 新規プロジェクトの作成**
putup my-awesome-package
![出典: Author | Streamlining Python package creation with PyScaffold]
### **使用タイミングについて**
再利用できそうなPythonライブラリを書いてみたい時とか、オープンソースを夢見た時、それとも社内向けでもちゃんとパッケージ化したい場合——そんな場面ではPyScaffoldが“良き相棒”になり得る。うーん、というか実際には必須じゃないんだけど…。でも配布関連でベストプラクティスへ導いてくれる感じがあって、自分一人だったら面倒だったコード共有やパッケージ化もまあ楽になる、と信じている人も多い(たぶん)。
それに複雑怪奇な設定ファイル編集地獄――ほんとうにこれ苦手なんだ――から解放される可能性もちょっとある。今思えば昔は手作業ばっかりだったから…あ、ごめん話逸れた。本題戻すと、その調整労力を減らせるってことですね。
![]
---
> ちゃんとスキャフォールドされたプロジェクトは、とても整理されているように見えるし、それ以上に未来への土台にもなる。“基盤”って大げさかな? でも案外そうかもしれない。
---
**ステップ1: PyScaffoldのインストール**
pip install pyscaffold
なんかね、このコマンド入れただけで全て始まる気がしてきちゃうんだよね…。
**ステップ2: 新規プロジェクトの作成**
putup my-awesome-package
![出典: Author | Streamlining Python package creation with PyScaffold]
### **使用タイミングについて**
再利用できそうなPythonライブラリを書いてみたい時とか、オープンソースを夢見た時、それとも社内向けでもちゃんとパッケージ化したい場合——そんな場面ではPyScaffoldが“良き相棒”になり得る。うーん、というか実際には必須じゃないんだけど…。でも配布関連でベストプラクティスへ導いてくれる感じがあって、自分一人だったら面倒だったコード共有やパッケージ化もまあ楽になる、と信じている人も多い(たぶん)。
それに複雑怪奇な設定ファイル編集地獄――ほんとうにこれ苦手なんだ――から解放される可能性もちょっとある。今思えば昔は手作業ばっかりだったから…あ、ごめん話逸れた。本題戻すと、その調整労力を減らせるってことですね。
![]
---
> ちゃんとスキャフォールドされたプロジェクトは、とても整理されているように見えるし、それ以上に未来への土台にもなる。“基盤”って大げさかな? でも案外そうかもしれない。
---
設定ファイルって必要?PyScaffoldの真価体験談
## 結論
えっと、Pythonプロジェクトのスキャフォールディングツールについて、_Cookiecutter_ とか _Kedro_、それに _PyScaffold_ を実際に比較してみたんだけど…まあ、それぞれ微妙に性格が違うというか、目的ごとに適した使い方がある感じだった。ああ、急に部屋の温度が気になってきたけど…いや、それはさておき。要するにコード整理がうまくいかない時とか、「このプロジェクト構成どうしよう?」と迷子になる時でも、とりあえずこれらのツールを試すことで効率的なセットアップへの道筋が見えてくることも多いっぽい。実はそうでもなくて、一発で全部解決とは限らないけど、新しいPythonプロジェクト立ち上げ初期からベストプラクティスを意識できる支援役としては頼りになるやつらだと思った(いや本当に)。パッケージ作成の基本から、高度なデータパイプライン設計まで幅広くカバーできるところも結構いい。
- **Cookiecutter**:柔軟なテンプレートによる生成
- **Kedro**:構造化されたデータサイエンスプロジェクト向き
- **PyScaffold**:プロフェッショナルなPythonパッケージング支援
## 著者とつながる
_**[Linkedin] | [Github] | [Medium]**_
## このストーリーを楽しんだ場合
_[Subscribe for free]_ クリックすると新しい記事公開時に通知されますよ。いや別に強制じゃないし、気軽でOK。
---
もし「ちょっと参考になった」と思っていただけたなら、この辺の記事も暇つぶし程度には読めるかもしれません。
> [**Generative AI**]
---
## FAQ
**Q1: Pythonにおけるプロジェクトスキャフォールディングとは何ですか?**
A1: えーっとね、Pythonのプロジェクトスキャフォールディングっていうのは、その……新規開発用の基本ディレクトリ構造とか主要ファイル群、それから設定系ボイラープレートなんかを自動生成してくれる便利ツール群(まあ手抜きアイテムとも言える)活用術ですね。一貫性確保や開発時間短縮にも寄与する——らしい、多分。でも油断すると逆効果にもなるので注意。

三つ巴比較表—どれも一長一短らしいけど…
Q2: CookiecutterはPython以外のプロジェクトにも使えますか?
A2: うーん、実際のところ、Cookiecutterは驚くほど柔軟なんですよね。Jinja2ベースのテンプレート機能が肝で、たとえば任意のプログラミング言語、それこそGoやRustみたいなやつでも、プロジェクトテンプレートを作成できるわけです。あっ、急に話が逸れたけど…Python限定って誤解しがちだけど全然そんなことない。そういう意味では、ファイルタイプも問わず活用できる感じかな。ま、便利なツールだと思う。
Q3: Kedroは機械学習プロジェクト専用ですか?
A3: ああ、それよく聞かれるんだけど…Kedro自体は主としてデータサイエンスとか機械学習ワークフロー向けに作られているものの、「再現性」とか「データパイプライン」の構成が重要視されてる点が特徴なんだよね。でも実際には複雑なデータ処理なら何でも応用できたりするし。いやまあ私自身も最初は「専用」って思い込んでいた時期あったけどさ…。だから幅広い用途で役立つ、と考えていいんじゃないかな。
Q4: PyScaffoldを使う主な利点は手動セットアップと比べて何ですか?
A4: えっとね、PyScaffoldを使う大きな利点と言えば…たぶん標準的なPythonパッケージ構造を自動生成してくれることだと思う。_pyproject.toml_ や _setup.cfg_ が最初からちゃんと揃ってるし、そのおかげで配布とかバージョン管理とかテスト環境づくりまで楽になる(いや、本当に!)。ま、途中で別件考えちゃったけど—要するに手動より圧倒的に効率化される感じ。それだけじゃなくて初心者にも優しい印象ある。
Q5: これらのツールは初心者には難しいですか?
A5: 実はそうでもなくて…。もちろん慣れるまでは「なんだこれは?」って戸惑う部分もあるとは思うよ。でもガイドやコミュニティ情報も豊富だし、少しずつ触ればすぐ馴染む印象(最初の壁越えれば案外平気)。あっ今ふと思ったけど、人によって感じ方違うから一概には言えないかな。でも無理ゲーでは絶対ないので安心してほしい。
よくある質問(FAQ)と知らない裏ワザも少し
A5: まあ、どのツールにもやっぱり学習コストっていうのは多少あるものなんだよね。うーん、でも…大抵の場合は普通のユースケースに困らないような設計になってることが多い気がする。ユーザーフレンドリーって言葉だけだと曖昧だけど、分かりやすいクイックスタート用ドキュメントとかもちゃんと用意されてたりするし。あ、そういえばこの前読んだ時も「これなら迷わず始められるかな」なんて思ったっけ。でも疲れてたから実際には手を動かしてなかった…ま、とにかく説明書きは親切な方だと思う。
Q6: えっと、これらのツールで生成されたテンプレートってカスタマイズできるの?
A6: うん、3つとも一応色んなレベルでカスタマイズできるようになってる(たぶんね)。Cookiecutterは独自テンプレートまで作れちゃうサポートがあるし…あ、ちょっと余談だけど名前が可愛いよね。Kedroにはスターターテンプレートが揃ってて、「もう最初からこれ使っとけば?」みたいな雰囲気もある。一瞬PyScaffoldどうだったっけ?と思ったけど、拡張システムもしっかり備えているらしいので、自分好みに調整したい人にはありがたい存在かもしれない。まあ正直そこまで全部使いこなせる自信はないけど…。
---
## 参考文献
[https://github.com/kedro-org/kedro]
[https://kedro.org/]
[https://github.com/cookiecutter/cookiecutter]
[https://cookiecutter.readthedocs.io/en/stable/]
[https://www.cookiecutter.io/]
[https://pyscaffold.org/en/stable/]
[https://pypi.org/project/PyScaffold/]