結論
Python言語を選び、その環境の構築の難易度が高く、保守管理・拡張にとても高コストな運用をしてしまう事になりました。
経緯
仕事でMacとWindows上で動作するツールを作る必要に迫られました。
そこで自分のMacマシンのターミナル（コマンドライン）から簡単に実行出来るPythonを選びました。
このツールはゲームのアイコン画像を沢山合成し出力するものです。
アイコンの素材をデザイナーさんが作成し、Googleスプレッドシート上のデータを参照しながらPythonプログラムが大量のアイコンを出力します。
（最終的にこのアイコン画像はUnityのNGUIでのAtlasという形で1枚にまとめられ、さらに複数のAtlasとなって終了となります）
Python以外の問題点
今回はじめてPythonを使ってみて分かった事としては環境構築の難しさです。
そして、ビルド（コンパイル）が要らない言語の便利さよりも、ソースコード管理への考えの甘さも有りました。
なんといっても最初は簡単な画像の合成だけを行っていたため、このツールの管理をsvnではなく自分のMacローカル上で動作したPythonのソースコードをzipにしてデザイナーさんに渡していましたし、そのせいでbatファイルや、更にはちゃんとwindows上でPythonが動作するか確認するためのwindowsマシンを用意する必要が出てくるなど、後々自分がこんな大変な思いをするとも思っていませんでした。
Pythonを選択した理由
Pythonはとてもいい言語だと思います。
既に多くのライブラリが存在し、画像編集も同じようにライブラリが用意されていますし、また多くのプログラマが扱える言語でもあります。
これはビルドを必要とせず、ツールを使う環境ごとにそれぞれ必要なPathやファイル名などのローカルなデータをPythonのソースコードに直に書いて編集できるというメリットもあったためです。
そしてコマンドラインからファイル単体で実行できるという強み。
また、現実的な課題として本当に小さなプログラムから始まったため、Mac/Windowsへのクロスコンパイルが出来るようにといった発想が欠如していたのもPythonを選択した要因の一つでした。
直面したPythonの問題点
今回作ったPythonプログラムの問題点は、コンパイルがいらないが故に動作させるマシン上にライブラリなどの環境構築をプログラマではないデザイナーさんに時間を割いて行ってもらう必要があり、自分がその環境構築を指示・実行しなくてはいけなかった点です。
今ではクロスコンパイル出来る言語を選択すればよかったと思ってます。
まず、自分がMac上でPythonをガリガリ書き上げて、ターミナルからPythonファイルを実行し動作するのを確認した後でzipにしてチャットでデザイナーさんへ渡していました。
しかし渡してみると、Windows上で動作しないのです。
チャットで状況やエラーの報告を受けて、対応しますが中々動作しません。
最終的に僕はデザイナーさんの席へ歩いて行きプログラムを確認しました。
コレによって、彼の作業を中断させ自分の他の実装を遅らせたわけです。
エラーを追ってみた所、Mac上にはあるライブラリがありませんでした。
確か Python Imaging Library (PIL) がその時は無かったです。
こいつがすごく厄介でした。
まず解決方法として、
$ brew install pil
だけで済む作業を、何時間もかけて調査して色々なライブラリを無駄に導入して貰う結果になったと記憶しています。
（gcc とかで何らかのライブラリをコンパイルまでして貰ったような・・・）
この作業が本当に辛かったです。
Googleスプレッドシート
次に、GoogleスプレッドシートからCSVのダウンロードです。
最初はUnityのAssetServer（Unity独自のバージョン管理システム）で管理されているゲームプロジェクト上にあるマスターデータからアイテムのデータを参照していました。
しかし、次のバージョンの開発が決まるとプロジェクトのブランチが新しくsvnに切られ、今まで参照していたマスターデータが古くなってしまうのです。
そのためアイテムの最新状態を保守するために、（幸いにも）常に最新を維持しているGoogleスプレッドシートを参照する事にしました。
Googleスプレッドシートを参照するにあたって、gspread というPythonのライブラリを使っています。
デザイナーさんにはgoogleアカウントとそのパスワードをPythonを呼び出すbatファイルに直接記述して貰う事にしました。
そして、まだzipでやりとりしていたため自分が知らないうちにデザイナーさんがsvnへとzipをコミットしてしまったのです。これで一生、彼のアカウントとパスワードがsvn上に残り続けてこのzipファイルをチェックアウト出来る人なら誰でも彼のアカウントを乗っ取れてしまうわけです。
パスワードは変えてもらいました。
そしてその危険性と gspread がメールアドレスとパスワードを非推薦した事で、OAuth の対応が必要になりました。
そう、”もうちょっとしたプログラム”ではなくなっていたのです。
書き飛ばしてしまいましたが、勿論 gspread もデザイナーさんの環境に構築しなくてはならず、僕はとても大変でした。
そして、このプログラムは今もまだ保守管理・拡張が行われています。
さっさと乗り換えたいですが、実際問題時間が割けないので今に至っています。
（色々とダメプログラマーですね・・・）
今後の課題と得たこと
今回のツールは、デザイナーさんの作業負担を減らすという課題がこのプログラムの使命としてずっと存在しています。
そのため、UnityEditor から実行して Atlas の import をようにしたいのですが、それも不勉強と時間不足によってずっとなされないまま今に至ります。
僕はツールプログラマではありません。ゲームの実装もしなくてはいけないのです。
しかし、今回の件で得たことはとても大きかったです。
Pythonによるコマンドラインから実行できる強み。
それとコンパイル済みのプログラムがライブラリ環境を必要としない事で実行環境への負担と管理が軽減される事が今回分かりました。
コレは自分としてはとても大事な発見であり経験だったと思います。
そして、なにより、自分のような未熟なプログラマが他にも要ると思います。
あなたが今作ろうとしているプログラムの実行環境が複数のOSを跨ぐのだとしたら、この記事が一つ参考になると嬉しです。