Demo or Die(SI現場でいろいろ作った話) - Fujitsu Advent Calendar 2016 13日目
Fujitsu Advent Calendar 2016 13日目の記事です。
ワクワクする夢の技術ではなく、ドロドロした現実の現場での話。
Demo or Die
Demo or Die ―デモを見せられないアイディアは、死んでいるのと同じ。
MITって大学のメディアラボのスローガンだ。うちの研究室はこの文化でやってるよ。
大学教授の言葉がずっと印象に残っています。動かさなければ意味は無い、と。
小学生の頃からプログラミングが楽しくて、社会に出てもその道で人を幸せにしたいと考えていました。
入社して
配属、そして疑問
いわゆる"客先常駐型"の、開発プロジェクトごとに人が集まる現場に配属。
言語はJava、人数は約60人。既に稼働し、改修や保守を行うフェーズでした。
たくさんの人の役に立てるシステムに携われるんだ、とワクワクしていました。
ほどなくして、不思議に思うことが出てきます。
- 配属初日、偉い人に「SEは体力だからな!」と言われる。
- "自動化できそうな手作業"がたくさんあって、しかし手作業のまま続けている。
- 問題が起きると、解決せずに"避ける"ための面倒なルールを作る。
- Software Designやオライリー本を出すと、値段を見てびっくりされる*1。
…ここは本当にIT企業なのか?
まずは、自らがITをもっと活用すべきでは? と思うくらい、"泥臭さ"の漂う現場でした。
葛藤、のち行動
嫌だ、どうにかしたい。でも、新人に何が出来るのか。
入ったばかりの新人の意見など取り合ってくれません。そもそも誰に意見をすればいいのやら。
そんなとき、『Demo or Die』を思い出しました。
そうだ。つべこべ言わずに実際に動かして、見せつけてやろう。よりよく出来ることを証明してやる。そんな意気込みだったと思います。
Demo 1: Alt+Tabキーの早打ちをやめる ~試験結果の一覧表示~
ユニットテストは、実行結果を1ファイルずつ開いて確認する面倒なものでした*2。
テスト仕様書(Excel)、エクスプローラ、それにテキストエディタを素早く操作するスキルが求められました。皆、フルHDに満たない解像度のディスプレイでAlt+Tabキーを酷使していました。
違うやり方を作ってしまう
実行結果を下記のような表形式にまとめて出す、というGUIツールを作りました。
テストNo | 実行日時 | 終了ステータス | エラー情報 |
---|---|---|---|
test-01 | 12/13 9:45:15 | 00 (正常) | - |
test-02 | 12/12 9:45:17 | 91 (システムエラー) | (例外発生) |
test-03 | 12/12 9:45:18 | 11 (チェックエラー) | 項目: ID, NAME |
言語はJava、GUIツールキットはSWT。起動すれば表示は自動更新。
テストを実行したら、あとは表示が更新されるのを待つだけになりました。
反響
幸いだったのは、OJTのトレーナーがいたことと、新しいものに抵抗を示さない人が一定数いたことでした。
「新人がこんなの作った」「なにこれ、めっちゃ楽じゃん。ちょうだい」
ツールは徐々に浸透し、プロジェクトの便利ツールフォルダにめでたく入りました。
Demo 2: ビルド、ビルド、ビルド! ~自動ビルド~
2年目にして製造サブリーダという謎の立場になりましたが、
ソースコードの管理やビルドにあたって、いくつか問題が起きていました。
- コミット漏れなどでリポジトリ上のソースがビルド出来なくなっても気づかず、別の誰かが困ってようやく発覚する。
- テスト用サーバへデプロイする資産をPCでビルドするのに10分掛かる。
- 誰かが時折古いソースでビルドしたものをデプロイしてしまい、別の誰かのテストが突然失敗しはじめる。
これらの問題を"回避"するために設けられたルールは窮屈なものでした。
「フォルダ全体でリポジトリと差分チェックし、コミット対象を洗い出すこと」
「PCでビルドする前に、リポジトリとの差分チェックを必ずやること」
たった1行、条件式の不等号を逆に修正するだけでも大変な作業量でした。
どうしてこんなことになってしまったのか。
そもそもデプロイ資産のビルドって各自でやる必要あるっけ?
答え:ない。まっっっったくない。
「継続的インテグレーション」が外で叫ばれる*3中、テスト用サーバで自動ビルドさせようと考えました。
が、常駐先PCはネットワーク的に外と隔離されており、Jenkins等は導入できません。
しかし、幸いなことにテスト用Linuxサーバにrubyが入っていました。
WEBrickという標準ライブラリを使用して、Webサービスを立ち上げられるのです。
メールを全員に出しました。
「自動ビルド、はじめました。もうPCでビルドする必要はありません」
ビルド結果のメール通知機能も備え、失敗にすぐ気付けるようになりました。
(※再現イメージ)
自動ビルドの利用はスムーズに進みました。誰だって楽をしたいですからね。
Demo 3: 探し回るのをやめる ~ファイル名検索エンジン~
複数のファイルサーバに数十万ファイルが散らばっていました。
当然、Windowsのファイル検索機能は役に立ちません。
「手順書、探しても見つからなくて。どこにあるんですか?」
「えっとね、このフォルダじゃないな… ここ…でもないか。じゃああっちかな… ああ、あった、ここだよ。フォルダのパス、メールで送るね」
こんなやり取りもしばしば。
表面上は「1分のロス」ですが、作業の中断(コンテキストスイッチ)は集中が途切れてしまうので、実質1分じゃ済まないのでは… と思っていました。
ファイル"名"検索エンジン
Namazuのような全文検索システム*4がほしい。
そうでなくとも、単にファイル名を検索できるだけでも、便利になるのでは?
レビューに飽きてコーディング欲が限界に達し、土曜日に出社して
再びRubyとWEBrickライブラリを使ったWebサービスを作成しました。
ファイルサーバへの接続はmount.cifs、ファイル名のインデックス化はfind。
Excelファイルに限って、JavaとApache POIライブラリ*5で全文検索に対応。
ひと目でどんなサービスか分かるよう、ロゴはGoogleそっくりに。
(※再現イメージ)
「すごいね。別のファイルサーバも検索対象にできる?」
これまでと違い、製造工程以外の方からも好評でした。
季節ごとにロゴを変えたり、いいね!に相当する"ハラショー!"ボタン*6を追加したりと、ちょっとした遊び心を付け加えました。
波及
これらの"Demo"は、最小限のメンテナンス手順を記して引き継ぎました。
私がプロジェクトを離れてからも使われていると聞いています。
嬉しかったのは、こんな言葉でした。
「私もツールを作ってみようと思って書いてるんだけど、ここどうしたらいい?」
「影響調査は機械的な方法、例えば全文検索でやろう」
私のやってきたことが、ちょっとだけ周囲に"響いて"いるようでした。
プログラミングで人を幸せに出来ているか?
少なくとも、現場はちょっとだけ幸せになったはずだ、と思っています。
別のプロジェクトに移ると、前のプロジェクトでお世話になった方がいました。
「前のプロジェクトで動かしてたアレ、ここでも動かさないの?」
or Die (限界)
と、偉そうに書きましたが、すべて順調かというとそうではありません。
失敗したDemoは倍以上ありますし、そもそも変化はとても小さなものです。
大きな変化を起こすには… おそらく、面倒なプロセスが山ほど。
このまま現場に居続けて、現場を変えることにこだわる必要はあるのだろうか。
そういう考えがあるのも確かです。
いいアイディアなら、さっさとやってしまえ
私は名言を都合よく使うことが大好きです。
Step Back and Automate, Automate, Automate
面倒でも自動化できることは自動化する
Cay Horstmann (ケイ・ホルストマン)
Kevlin Henney編 (2010)『プログラマが知るべき97のこと』
和田卓人監修, 夏目大訳, オライリー・ジャパン.
プログラマの三大美徳は「怠惰」「短気」「傲慢」です。
目の前の機械を活用して、楽になる。そのための手間は惜しみません。
If it's a good idea, go ahead and do it. It's much easier to apologize than it is to get permission.
いいアイディアなら、さっさとやってしまえ。許可を得るよりも謝るほうがずっと簡単だから。
COBOL開発者 Grace Hopper (グレース・ホッパー)
やってみたいことがあるなら、とりあえず、やってみませんか?