Gaiax Engineers' Blog

Gaiaxのエンジニアブログです。 社内のエンジニア様子、イベントレポート等を発信していきます。

自分が作った小さなツールに自信を持とう

こんにちは、おがた (@xtetsuji) です。Gaiax では2015年6月に入社後、インフラチームという組織に属して、サーバハードウェアの取り扱いから大気汚染度の計測まで、幅広く担当させていただいています。

この記事は Gaiax Advent Calendar 2016 の 4日目です。

今回は「小さなツール」というテーマで書いてみることにしました。

簡単な自己紹介

私は2003年に学生を卒業してIT企業に入るまで、実は本気でプログラミングをしたことがありませんでした。もっとも、学生時代に授業等で BASIC や C を書いたことはありましたが、自分に必要だとも面白いとも感じなかったし、そもそも自分に向いているとすら思っていなかった。職業プログラマになってからも、バリバリ書くかと言われたら世代や経験年数が似たプログラマよりは全然書けないと思います。

社会人1年目の2003年は、ログファイルを集計する仕事があり、そこで Perl を使い始めたのが私と Perl との本格的な出会いでした。Perl を選んだ理由は、単に先輩方が Perl を書いていたからという理由。かれこれ10年以上 Perl を書いています。むしろ Perl 以外はそれほど書けません。

ガイアックスが3社目で在職1年数ヶ月となりました。ちなみに1社目約10年、2社目約10ヶ月という経歴です。

万能なツールを目指すべきか

1社目には、東京のオープン系ITエンジニアにしてはかなり長い年数在職していたので、その間に様々な先輩・後輩・同僚と出会い、様々な仕事を体験することができました。もちろん、商用サービスの開発を進めていたこともあれば、その周辺領域で大小様々な社内ツールの作成も行いました。

「せっかく社内ツールを作るなら万能ツールにしたい」と考えるのは自然な考えでしょう。私もあります。

しかしながら作成可能性を考えず万能ツールが作れたとしても、意外に使ってもらえなかったり、保守運用フェーズでの属人性の問題が露呈したり、そもそも日々変化を続ける業務に合わせるコストがツールの重厚長大さによって引き上げられる問題等、時間の経過に従って悩みが噴出する、そんな印象があります。

私もクラスファイルが何十何百にも及ぶ重厚長大な社内ツールを書いたことがありますが、努力の割に使ってもらえなかった思い出があります(作った楽しさは置いといて)。たとえ多少使ってもらえたとしても、重厚長大なツールはメンテナンスコストが掛かるのも無視できません。

そのツールを開発した私は、本来その業務から別の業務の開発に移っているはずなのに、前の業務の重厚長大なツールの保守のために呼ばれることもある。愚直な作業フローであればアルバイトを増やして対応できる業務が、重厚長大なツール自体がボトルネック、さらに悪いときには単一障害点になる状況もあるのです。それは他者が作った社内ツールでも似たような状況でした。

保守運用をする立場の私

凄腕プログラマが腕を振るえば何の問題も無い万能ツールが生まれるのかもしれませんが、誰しも凄腕ではないし未来予知ができるわけでもないので、ツールの保守運用を任される立場だと悩むことになります。

ガイアックスに入社してからは、自分でツールを作るより他者が作成したツールを保守運用する機会が多く、まさにツールの保守運用を任される立場というのが今の私かもしれません。

ガイアックスにある社内ツールはそれこそ大小様々。手を入れたくても何が起こるか分からないし作成者はもういないしで難儀している重厚長大な社内ツールもありますし、比較的気軽に手を入れても大丈夫な小粒な社内ツールというものもあります。前者の立場の気持ちも分かるので、開発者の当時の気持ちを考えながら保守運用の方法を考えるというのも私の仕事の醍醐味と言えましょう。

ガイアックスのエンジニア風土には、とにかく「無ければ作る、あってももっと良く作れそうなら作る」という精神を感じます。保守運用フェーズでの問題点を上述しましたが、「作る人」であるわけで、とてもポジティブな精神でしょう。問題点を解消する文書化だったりといった手法は、これから強化していってもいいと思います。

小さなツールが意外に喜ばれる

私は前職で大小様々な社内ツールを作りましたが、ある年の年末、後輩に「僕が作ったツールで今年一番だったものは何?」と聞いたことがあって、その回答に仰天したことがあります。

「おがたさんが書いた、数字を与えるとその長さのランダム文字列が返ってくる Perl スクリプト、あれ超役立っているんすよ!」

「え?」と素で声が出てしまいました。「あの色々なデータを取り出して集計できる管理ページとか、mod_perl であらゆるガラケーコンテンツを透過的に変換したりリダイレクトしたりするやつとか、もっとスゴイやつ書いたじゃん!?」とか言っても、得てして重厚長大ツールは大きすぎて存在に気づかないし、見えないところで透過的に処理する仕組みはそもそも見えないのです。

そのスクリプト、これぐらいだったような…。

#!/usr/bin/perl

use strict;
use warnings;

my $num = shift;
my @char = (“a”..”z”, “A”..”Z”, 0..9);

my $str = join “”, map { $char[ int rand @char ] } 1..$num;
print “$str\n”;

使用者にとって、そのツールが何千行何万行かは関係なく、目下の業務にどれだけ役立つかが大事なんですよね。この後輩の返答はしっかりと私の心に刻まれ、その後もオーバーテクノロジーの抑止などの教訓としています。

複雑なロジックが必要になる場合の一つの考え方 もちろん、上述の後輩が本当は「必要不可欠かつ無意識に使用していた」重厚長大ツールの存在に気づいていないだけということもあります。対峙している業務には一定以上の複雑さを持ったものもあり、それに対峙するには社内ツールも一定以上の複雑さを持つのは仕方がないでしょう。

複雑なツールを扱いやすい状態に置くにはどうすればいいか、数年前に色々考えたのですが、そのヒントの一つは「UNIXという考え方」という書籍にあるかもしれません。本書に書かれていることをざっくり言えば、「ツールは一つのことだけやる」「ツールを組み合わせる」ということでしょう(え、ざっくり過ぎる?)。

本書は ls コマンドですら複雑だと一喝します。ls は本来のファイルリストに集中すべきで、n*m のテーブル表示は別のコマンドが行う(ls はそのコマンドにパイプで出力を渡す)べきだとさえ言います。確かに自分が ls のメンテナだったら、(最初は楽しく書くかもしれませんが後々忙しくなったら)ファイルシステムを扱うこととテーブル表示を扱うことは分けて考えたいかもしれません。極端に感じることもありますが、それくらいの考え方でいないとツールはすぐ重厚長大になってしまい、保守が難しくなるのかもしれませんね。

こういう機能分離が意識される用語はいくつもありますが、一つは層(レイヤー)という言葉があります。具体例は枚挙に暇がないですが、Perl でウェブアプリケーションを作る際には Plack::Middleware を利用したり、その思想の根底には HTTP のリクエストフェーズがあったり、さらに OSI 参照モデルもあったり…。複雑なロジックが必要になる場合は、一つの方法として層という切り口で考えることで、一つ一つの問題を単純化できるかもしれません。

(まだもうちょっと追記予定です)