トップ «前の日記(2011年09月06日) 最新 次の日記(2011年09月08日)» 編集

KeN's GNU/Linux Diary
... 料理とDebianと雑多な記録


2011年09月07日

_ [life] 社内システムや社内ツールの開発ポリシー

Twitterでの自分の発言から少し膨らまして。

社内用システムや社内用ツールを作ることがままあるんだけど、そのときに常に配慮していることがある。それは「引き継ぎ可能である」こと。

私の勤務先は編集プロダクションなので、コードで語れるプログラマがいるわけじゃない。今後専属のプログラマを雇うというのも業種的に難しいだろう。

でも、自分が何かの拍子にバスに轢かれたり、病気で意識不明になったり、あるいは唐突に退職しなければならなくなったりすることはゼロとはまったく言えないわけで、そのときに誰もシステムやツールがわからなくて企業活動が停滞するようでは困る。

黒魔術で技巧を凝らしたプログラムやシステムというのは、属人化してしまう。属人化したシステムや組織は脆い。そもそも自分は飽き性なので、変化のない保守作業をするよりも、新しいことにチャレンジしたい。

ということで、引き継ぎ可能な社内ツール/システム開発にあたって、自身に次の3点を課している。

  • スクリプト言語で書く
  • すぐにドキュメントを書く
  • 宣伝する

スクリプト言語で書く

スクリプト言語の良い点は、コードをそのまま読めて、すぐに実行して試しやすいこと。

業務ドメインとして、高速応答性などよりも正規表現での文字列マッチングみたいな場面がほとんどなので、スクリプト言語の欠点は目立たない。

昔はPerlで書いていたものが多いけど、最近作るものにはたいていRubyを採用している。 Perl/Ruby/Pythonあたりなら引き継ぎはなんとかなるだろう。 サーバ系のものも、展開がしやすいように外部ライブラリの使用は極力避けている。 当然ながらコードは全部、社内VCSに入れる。

実験的に別の言語で書いてみたりすることはあっても、あくまで個人用途や勉強・遊びの範疇。たとえば関数型言語がどれだけ素晴しくても、保守できる人が自分だけというのはとてもとてもまずい状況。

InDesign DTP用のツールは、(自分がそれしか書けないこともあって)JavaScriptで作っている。AppleScriptでやったほうがいいこともあるのかもなぁとは思いつつ、「AppleScriptがわかる人」vs「JavaScriptがわかる人」で現在および将来での引き継ぎ性を考えると、JavaScriptのほうが探しやすいと判断した。

すぐにドキュメントを書く

コードをわかりやすく書けばそれでよしと言えるのはプログラマ相手だけで、専門プログラマでない人に保守や運用を委託するには、やはりドキュメントを揃える必要がある。

といっても厳密な納品などじゃないので、無駄に細かく作らなくちゃいけないわけではなく、セットアップ手順や簡単な使用方法があればひとまずは十分。

業務の片手間に作ることが多く、作り終えて時間が経つと自身ですらいろいろと忘れてしまうので、作りながら、せめて作り終えたらすぐにこのドキュメントは書く。ドキュメントの更新作業やこの後の「宣伝」も考えると、社内Wikiにまとめておくのがいいと思う。

宣伝する

ツールやシステムは使ってもらわなければ意味がない。自分専用に作ってみたものだって、もしかしたら同僚の作業の役に立つかもしれない。

そこで、宣伝する。社内メーリングリストであったり、直接関わりそうな人に話してみたり。

宣伝のためには説明文が必要だ。ここで前述のドキュメントがその役割を担う。

意見をもらえたら改良する。中身に興味を持ってもらえたら開発仲間に引き込む。1人より2人、2人より3人、中身がわかっている人がいてくれれば、引き継ぎなど心配する必要がなくなる。

まとめ

「スクリプト言語で書く」は業務ドメインや引き継ぎ候補の同僚のスキルによっては変わってくるかもしれないのでともかくとして、「すぐにドキュメントを書く」「宣伝する」はどこでも通じる話ではないかと思う。

黒魔術な「オレッてばスゲー」ソフトを作るのはとてもいいことだけど、社内ツール/システムではそこから一歩引いて、客観的に保守しやすい形になっているか問うてみる必要がある。ということで終わりー。

_ [cooking] ひつまぶし、厚揚げとカブの味噌汁

最近のウナギの高騰に困ってたけど、中国産のが安めに売っていたので。ミニトマトとは相性悪いな…