一番経験あるのはPHPだけど一番好きなのはRuby

Web系アプリソフトウェア開発者としての僕のキャリアにおいて、開発に使用したプログラミング言語は大半がPHPです。だから最も経験があって慣れているのはPHPなんですけれども、でも一番好きかと言われると、そうでは無いですね。

なんていうか、PHPって気をつけないと行儀の悪いプログラミングが容易に出来てしまいますからね。プロジェクトによってはソースコードが無法地帯で世紀末と化している場合もあります。書いたプログラマの秘孔を突きたくなりますができません。残念。

じゃあ一番好きな言語は何だと言われれば、そりゃやっぱりRubyです。学生時代の頃、研究室で自分の研究をサボりつつする傍ら、Rubyで皆が研究で使うツールを開発していたことがありまして、その時にRubyの魅力に浸かりました。

Rubyはやりたいことが素直に書けるのが魅力ですね。Rubyを作ったまつもとゆきひろ氏も、書いていて楽しくなるような言語にしたと確か言ってましたし、実際そのとおりだと思います。

ついでに言うと僕がオブジェクト指向について初めてまともに理解したのもRubyを書いている時であり、オブジェクト指向によるプログラミングを初めて本格的に行った言語でもあります。その意味でも思い入れがあるんですよね。

で、今進めているプロジェクトでは、メインの部分で僕が自分で使う言語を決めていい状況にあり、ついに仕事でRubyをメインに使えるということで非常にワクワクしてます。今ちょうどRuby周りを準備中でテンション高いです。そのうちこのブログにもRuby関係の投稿をしていけると思います。

※この記事について指摘・意見・提案・感想などありましたら下のコメント欄にどうそ。

仕様書を書きつつ別作業

現在プロジェクトの初期段階にあり、仕様書を書いておりますけれども、ドキュメントをずーっと書いてるとさすがに飽きてきますし、かなり脳味噌を使うので疲れるということもあります。

そこで仕様書を書きつつ、区切りのいいところで後の作業で必要になるサーバの構築・設定とか使う言語やフレームワークについて調べたりとか、ドキュメンテーション以外の作業を挟むようにしてます。

これがコーディングですと結構長時間どころか何日も集中して作業し続けたりできるんですがね。不思議なもんです。脳の使う部分が違うんでしょうね。ドキュメンテーションもコーディングもどちらも面白くて頭を使う作業ではありますけれども。

ということで、ドキュメンテーション以外にも色々やることはあるので適当に時間を配分しつつ進めていこうと思います。この辺の作業への時間配分が自由にできる今の環境はありがたいですね。

※この記事について指摘・意見・提案・感想などありましたら下のコメント欄にどうそ。

画面仕様書にはどこまで詳細を書くか

仕事でソフトウェア開発をしていて仕様書を書いてますけれども、今週から画面設計の部分にとりかかりました。そこで考えるのは、仕様書に画面設計の詳細をどこまで書くか、ということです。

以前仕事をしたある職場では、画面仕様書に関係する関数名や変数名の一覧まで書いてありましたけれども、ちょっとそこまでやるのはやり過ぎだと思います。実際コードを書く際にいくらでも変更される部分ですし、いちいちドキュメントを修正していたら手間がかかりすぎてそのうち仕様書を見向きもしなくなるでしょう。

逆に、以前アジャイル開発をした時は画面設計というはむしろ仕様書自体、開発中は全く手を付けていなかった状態でした。それはそれで最後に時間がなくなり、結局まともな仕様書を残すことはできませんでした。まあ、それは仕様書を残す必要のない性質のプロジェクトだったからよかったものの、そうでなければ少々まずい事態でしたね。

その辺の落とし所は一概にこうすればいいというものではなく、プロジェクトごとの個々の状況に応じて変わってくるんだろうなと思います。今回の僕の方針としては、機能を文章で説明しつつ、ごくごく簡単なワイヤフレーム（白黒で装飾の全くないもの）でボタンやテキスト等の要素の配置を示すことにしたいと思ってます。詳細に立ち入りすぎず、かつ機能の説明を最低限のラインで果たしているという感じを目指します。

あえて、「全ての機能を完全に」書くのではなく、文章の文脈や図などを見れば必然的に想像できることについては記述を省略する・・・って構成にできれば理想的です。この加減や方法については今後も研究していきたいと思います。

※この記事について指摘・意見・提案・感想などありましたら下のコメント欄にどうそ。

エンジニアのための「セーブポイント」仕事術

よくロールプレイングゲームだとセーブポイントってあるじゃないですか。最近のゲームはいつでもセーブできるものが多いと思いますけど、昔は特定の場所でしかセーブが出来なくて、それをセーブポイントと呼んだわけですよ。うっかり失敗して全滅して、セーブポイントまで戻らざるを得なくなった、なんて経験した諸氏も多くいらっしゃることでしょう。あれは実に時間を奪ってくれましたよね。

さて、ITエンジニアとして仕事してますと、なんか仕事にも「セーブポイント」に似たようなものがあると感じるんですよね。例えばプログラミングだったら、とあるモジュールのコードを書いていて、最後まで書き終わればそれで「セーブポイント」に達したようなもので、そこで仕事をやめても次から続きをすんなり開始できるわけですが、途中でやめて帰ると、次の日前日にやってたことを思い出さなくちゃいけなくなり、結局前日に書いたコードを読み直さないといけなくなってしまうので、それが以前の「セーブポイント」まで戻される感覚に近いわけです。他の仕事、例えば事務作業なんかだと別にいつ仕事を中断しても続きから始められるのかもしれませんが、エンジニアの仕事だとそうは行かないと思います。

その意味で、自分の仕事はどこまでやったら「セーブポイント」なのか常に意識しておくと仕事の効率を上げることができます。例えば、帰る予定の時刻まで残り１時間しかない状況で、「セーブポイント」まで２時間かかりそうな仕事を始めると、結局「セーブポイント」に達する前に帰る時刻になってしまい、無駄が生じるわけですよ。

ここで注意していただきたいのは、「セーブポイント」と言っているのは仕事の全体量を言っているのではないってことです。上で挙げた例でも、残り１時間だから「１時間で終わる仕事をしよう」と言いたいのではないのです。例えば全体が６時間かかる仕事でも、「セーブポイント」が１時間おきにあるのであれば問題ないわけですね。

もしフレックスタイム制など時間の調整の自由が効くのであれば、日々の勤務時間を「セーブポイント」のキリの良い時間に合わせるという手も使えます。そうすれば仕事の効率をかなり上げることができます。

ということで、普段から仕事をする上でも「セーブポイント」を見つけるようにしておくといいですね。

※この記事について指摘・意見・提案・感想などありましたら下のコメント欄にどうそ。

派遣エンジニアとキャリアパス

僕も昔、派遣エンジニアをやっていたことがありまして。いわゆる特定派遣ってやつですね。どっかの会社の正社員でありながら職場は別の会社で、そっちに毎日通うというやつです。僕自身の現場経験を思い出してみてもこの形態のエンジニアは多く、IT業界にはかなりの人口がいるはずです。

別に派遣エンジニアそのもの自体は悪くもないと思うんですよね。１つの組織にとどまらず様々な現場を経験するのはそれはそれで面白いと思いますし、バリエーション豊富な経験というのはエンジニアとしての財産であり武器になります。

ただし問題は、特にIT業界の構造として年齢の上昇とともに派遣エンジニアの受け入れ先が少なくなるということです。これはIT業界の構造が原因ですね。

派遣エンジニアの仕事が発生する主な場面の１つとして、システム開発を請負う会社がプロジェクトを受注し、そこで自社で足りない人員を募集するというものがあります。その際に人員募集の情報をエンジニアを擁する会社に流して、条件に合うエンジニアを派遣してもらうわけですね。派遣されたエンジニアは、受け入れ先企業ではチームリーダーの下に就くわけですが、プロジェクトのチームリーダは受け入れ先企業の正社員である場合が多いです。そしてその際に、チームリーダーより年齢の高い派遣エンジニアがいると気まずいだろうと受け入れ先企業は考えるんですね（僕自身はそんなのどうでもいいと思いますが）。だから、条件として明記してなくても、年齢の高いエンジニアは敬遠される傾向があります。

また、派遣エンジニアは炎上したプロジェクトに増員要員として現場に集められるケースが多々あります。そういったプロジェクトはスケジュールが既にかなり伸びてしまっており、赤字の危機（もしくは既に赤字状態）にあります。ということは追加費用はなるべく抑えたいわけです。だから、集める派遣エンジニアも安く済ませたいわけで、すると単価の低い若いエンジニアが選ばれてしまいます。（それで実際大丈夫なのかというと全く違いますが。）

このような事情があるいせいで、派遣エンジニアは年齢が上がると仕事が少なくなるんですね。

僕がIT業界に飛び込んだ時はこういう業界構造を理解してませんでしたし、最初に入った会社がエンジニア派遣で主に儲けていることも分かっていませんでした。だいたい求人情報には「エンジニア派遣やってます」とは書いてません。一般派遣と違って正社員ですし、求人情報見ても区別はつきません。ある程度業界経験積めば分かりますけどね。

それでも最初の切っ掛けをつかませてくれたという意味で派遣エンジニアは大きな意味がありましたし、業界の構造も知ることが出来ました。最初のステップとしてはアリだと思ってます。

ただ、今派遣エンジニアの人は、将来のキャリアパスを見据えて次のステップは早めに考えておくべきとは思います。ある程度経験を積んだら、例えば独立してフリーのエンジニア（個人事業主）になるとか、派遣エンジニアではないビジネスを自社でしている会社に転職するとかですね。ちなみにエンジニア派遣会社の営業になる人もいますが、オススメできません。（ここで書くと長くなるんで別の機会に。）

本当は、業界全体がもっと変化して年齢の高い派遣エンジニアも積極的に受け入れられるようになっていくのがベストだと思います。実際、様々な現場で経験を積んだエンジニアは頼りになりますよ。チームリーダより年齢が高いからと避けるのはもったいないし、高い報酬を出すだけの価値はあります。

しかしいかんせん、業界が変化を待ってたら先に自分が食えなくなるかもしれませんから、やっぱり対策を打つしかありません。

※この記事について指摘・意見・提案・感想などありましたら下のコメント欄にどうそ。

エンジニアの大切な要素「しつこさ」について

ITエンジニアに必要な知識なんて無限にあるわけですよ。ある物事についてあらゆる知識を持っている人を「生き字引」なんて言ったりしますけれども、ことITエンジニアの世界においては「生き字引」ってあまり価値ないんですよね。何故かというと１つの理由は必要な知識はネットにあるので覚えておく必要がない、もう１つの理由は新しい技術が次々に生まれるので、古い知識は凄まじいスピードで役に立たなくなるということです。（だからといって知識の蓄積に意味が無いと言っているわけでは勿論ありません。）

さて、いくら勉強しても尽きることのない知識の広大な海の中で僕らエンジニアは成果を出していかなければならないのですが、その際大切になってくる要素の一つが「しつこさ」であると僕は考えてます。

結局日々仕事に取り組む中で目の前に現れてくる問題というのは、自分にとって未知の問題であるわけです。そもそもIT関係のプロジェクトというのは今まで無かったものを実現したり、新たな仕組みを構築したりするわけで、その意味でルーチンワークにはなり得ないんですね。それがこの仕事の面白いところであり、同時に難しいところでもあります。ともあれ、仕事の性質上、ぶち当たる問題は未知の問題であるというのは納得頂けると思います。

だから問題に取り組む時は常に自分の持たない知識を調べ、試行錯誤を重ねなければなりません。ところが、ここで分かれ道があります。

例えば、あるシステム開発プロジェクトで開発を進めるうちに、ある機能の実現について問題にぶち当たったとします。エンジニアとしては、諦めてそれは技術的に不可能ということもできます。しかし、もっと調べたり考えればもしかしたら実現可能かもしれません。

じゃあ、実現可能な方法を発見できる、あるいは考え出せるかどうかは何で決まるのか。知識？経験？いえ、上で述べたように、過去の知識や経験はすぐに陳腐化する業界です。多少はアドバンテージになっても、決定的な差にはなりません。

だからこそ、僕は「しつこさ」が重要だと思ってるんですよ。結局のところ、問題にぶち当たったら僕らエンジニアはほとんど同じスタートラインに立つわけです。過去の知識や経験はほんの数歩のリードくらいにしかなりません。その状況において、問題を解決できるかどうかというのは、やっぱり諦めの悪い人間、すなわち問題が解決するまでしつこく粘れるかどうかで決まるんじゃなかと思います。

ITエンジニアにとっての本当の「経験」とは、問題のぶち当たった時の「しつこさ」を獲得すること、粘リ方を覚えることなんじゃないかとさえ思えるんですよね。

※この記事について指摘・意見・提案・感想などありましたら下のコメント欄にどうそ。

ドキュメント管理のためSphinxを導入してGitで管理

ソフトウェア開発においてはドキュメントの変更は頻繁に起こるものです。といいますか、「起きるようにすべき」ってことなんですがね。

ドキュメントの更新は得てして（非常に高い確率で）放置されがちなタスクです。古くなってカビとキノコが生えたドキュメントは役に立たず、誰からも参照されなくなります。そして、リリース直前になって慌てて開発チームが更新作業に追われるのですね。

昨今ではすっかり市民権を得た（と少なくとも見える）アジャイル開発においても、「ドキュメントよりも動くソフトウェアを重視する」という方針のおかげか、ドキュメントは開発中は手を付けず、最後にまとめて作るやりかたも実際に行われてるという話も聞いたことがあります。

僕自身、アジャイル開発を本格的に行った以前のプロジェクトにおいては、開発中にドキュメントは作りませんでした。しかし考えてみれば、そのプロジェクトはWebサービスの開発であって、誰かに仕様を1つにまとめて伝える必要性がそこまで高くないものだったのです。しかし今取り組んでいるプロジェクトは製品として外部に出荷することを想定しており、その意味では仕様をまとめる必要性があります。

しかし、最後にまとめて変更するやり方ではそもそも大変ですし、ミスも生まれやすくなります。何より、ひたすらドキュメントの更新をするのはあまり楽しい作業ではありません。やはり、ドキュメントを開発にともなって随時変更していきたいところです。しかし、それは放置されがちになることは既に述べました。

プログラムのソースコードがなぜアジャイル開発のような頻繁な変更にも耐えられるのかといえば、SubversionやGitのようなバージョン管理システムの貢献が大きいです。コードのどの部分がいつ誰によってどう変更されたのか明確に把握できてこそ、一度書き上げたコードの一部をかいつまんで変更し続けることが容易になるのですね。そうでなければチームは大混乱に陥ります。その意味で、バージョン管理システムが発達していなかった時代、ウォーターフォールしか選択肢がなかったのも頷ける話です。

つまり、ドキュメントの変更を開発に伴って頻繁に行うには、どの部分がいつ誰によってどう変更されたのか把握できるようにしなければなりません。残念ながらExcelやPowerPointではこのことは実現が非常に困難です。

だったら、もしバージョン管理システムによってドキュメントを管理できれば、開発しながらドキュメントも書くということが実現できそうです。そのためには、ソースコード管理システムによって変更を把握できる形式、すなわち「プレーンテキスト」である必要があります。

そこでプレーンテキストからドキュメントを生成する仕組みを導入すればいいと気づくわけですね。有名なものに科学論文向けのTeXがありますが、ソフトウェアのドキュメント向けに開発されたツールの1つとしてSphinxがあります。SphinxはPythonの公式ドキュメントに使われている他、多くのマニュアルやサイトに使われています。

なんか前振りだけで長くなりましたが、まあこういったツールの導入には考え方が重要ですからよしとしましょう。手順自体は大したこと無いんで、簡潔にまとめます。環境はDebian Linuxです。

まず、Sphinxをインストールします。Pythonは既にインストールされているものとします。Debianのパッケージは古いので、公式リポジトリからソースをダウンロードして使います。

$ wget https://bitbucket.org/birkenfeld/sphinx/get/1.2.1.tar.bz2
$ tar jxvf 1.2.1.tar.bz2
$ cd birkenfeld-sphinx-3238dc3d4528/
$ python setup.py build
$ su -
# python setup.py install
# exit

これで/usr/local/bin以下に実行ファイルがインストールされます。次に、ドキュメント管理用のGitリポジトリを用意し、その中でsphinxプロジェクトを初期化します。

$ mkdir foo-doc
$ cd foo-doc
$ git init
$ sphinx-quickstart

sphinx-quickstartを実行すると、幾つか質問されます。その際、プロジェクトの名前と著者名（複数可）だけ答えてあとはデフォルトでいいという説明をよく見かけますが、こんかいはGitで管理する都合上、ソースと生成したドキュメントを分離することにします。以下の質問をされた時に y と答えればいいです。

You have two options for placing the build directory for Sphinx output.
Either, you use a directory "_build" within the root path, or you separate
"source" and "build" directories within the root path.
> Separate source and build directories (y/n) [n]: y

これでSphinxでドキュメントを作成するための基本のファイルが生成されます。 .gitignoreでbuildディレクトリを除外しておきましょう。ドキュメントのソースコードはsource ディレクトリ内にあります。ドキュメントを生成するには、Makefileのあるディレクトリで

make html

などと打てば生成されます。html以外にもpdfなど様々な形式を指定できます。具体的なドキュメントの書き方の詳細については日本ユーザ会のマニュアルなどを参照ください。

※この記事について指摘・意見・提案・感想などありましたら下のコメント欄にどうそ。