ユニケージ開発手法のデメリットについて

はじめに

Googleでユニケージ開発手法について軽く調べると、メリットについてはすぐに情報が出てくるのですがデメリットについてはなかなか出てこない現象に遭遇します。
デメリットまで理解したうえで技術は使うべきだと思っているので、自分がデメリットだと思っていることを書くことにしました。（こういうデメリットもあるよ！その認識は間違ってるよ！などのご意見大歓迎です！コメントください）
ちなみに、自分はメリット・デメリットを比較した結果、仕事で「使いましょう！」と進言したことはありません。

そもそもユニケージ開発手法とは

簡単に言うと「ソフトウェア自体をシェルスクリプトで構築してしまおう！」という開発手法です。
これによって、「ある程度の品質の担保」、「（特定環境への）移植性の高いソフトウェアの開発」、「開発速度の向上」などの恩恵を受けることができます。¹

デメリット

ここからが本題です。

シェルスクリプトのデメリットを全面的に引き継いでしまう。

シェルスクリプトを使用するので当たり前っちゃ当たり前なのですが。。。多少はユニケージ開発の「お作法」によって改善？されてるとはいえ、やはりデメリットとして出てきてしまいます。

シェルスクリプトの代表的なデメリットとしては

• 可読性が低い
• （標準的な環境では）実行するまでエラーかわからない
• デバッグがやりにくい

などがあげられると思います。

ユニケージ開発手法を経験したことのある会社が少ない

開発を行っている会社が少ない為、発注先を変えることが難しくなってしまいます。
付き合いなどもあるので現実ではなかなか発注先を変えるということは無いかもしれませんが、様々な可能性を考慮していくとこれはリスクとしてあげられると思います。

自社のみで完結（自社システムを社内で作っている）している場合でも、様々な理由で途中から外部の会社に任せる可能性があります。その場合はユニケージ開発手法を経験したことのある会社に頼めばいいと思うかもしれませんが、実はここは一筋縄では行かない可能性があります。例えば特定のプロダクトを一緒に使用していた場合（BigQueryやRedShiftなど）、どうすればいいのでしょうか。そのプロダクトが得意な会社に任せますか？ただ、そういう会社はほとんどユニケージ開発はやったことがないはずです（APIなどがコマンドから叩く形で整備されていないことが多い。整備されていても機能が制限されているので、結局モダンな言語を使用することが多い）。では、ユニケージ開発手法を行っている会社に頼むとどうでしょうか？まともにユニケージ開発手法を行っている会社であればユニケージ開発手法で何かプロダクトを使用してビッグデータを扱おうとは思わない為、（ビッグデータもファイルで処理する）なかなか渋いことになると思います。

また、根本的な問題として経験している会社が少ないということは、経験している人材も少ないのです。集団離職などが起きた場合、最悪詰みます。

様々なユニケージ開発の「お作法」を知らないといけない

これに関しては後半に軽く触れます。

うさんくさい会社がユニケージ開発を名乗っているときがある

これはユニケージ開発の直接的な問題ではないのですが、ユニケージ開発を行っている会社が少なく、そんな会社に当たる確率が高いと思ったのでデメリットとしてあげておきます。
うさんくさいかどうかの確認方法ですが、以下の質問をするといいんじゃないかと思います。即答できなければその時点でアウトです。（即答できても胡散臭い場合もあるので、可能であれば親戚に一人はいるシェルスクリプト大好きおじさんに聞いてみてください²）

• シェルショックについて
• バージョン管理はどうやって行っているか
• コマンドセットは何を使用しているか
• 改行コードは何を使用しているか
• インデント幅は何文字か、また、インデントはなにで行っているか
• シバンには何を記載しているか
• コマンドをパイプで繋ぐ際の注意点は何か

最初にユニケージの直接的な問題ではないと書いたのですが、正直これが一番問題な気がします。
少しフェイクを混ぜて書くのですが、以下のようなことを平気でします。

• 1から10000までの数をカウントする処理で1の桁が9から10になる際に0にし、2桁目の数字を1足す。それを繰り返し10000を目指す。なお、処理にバグが存在し、300から400の間はカウントされることはない。
• bashの機能を使用しているのにも関わらず、シバンはsh
  • そもそもシバンを書かないこともある
• その時その時使いたい共通処理スクリプトを作成する。（そもそもユニケージ開発では全有の考えがあるので、共通ルーチンは本来呼び出さない）
• ユニケージ開発のワンプログラムワンフローの原則を平気な顔で破る（関数の使用も原則禁止。他の言語と同じように書きたいなら他の言語で書くべき）
• そもそもソフトウェア開発に従事するのであれば知ってて当然のバージョン管理を知らない、もしくはソースコードにコメントで日付、変更start -> 変更endみたいな前時代的なことをやっているところもある。
• テストのことを全く考えていない書き方。固有情報がベタ書きで書かれているのでテスト時にソースコードを書き換えないといけない。

などなどです。

こんなもん、あとからどこの会社に保守をお願いしてもうまく行くわけがないです。

終わりに

書きなぐる感じで書いたので後で細かく修正するかも？
個人的には結構好きなんですが、（仕事で使うとは言ってない）如何せん流行らないですね。
メリットとデメリット、正しく知った上で技術は使いましょう！