2013年12月5日木曜日

Risoluto誕生物語 その4 | Risoluto@アドベント・ぼっち・カレンダー:4日目

ABC(*1)の4日目。共通テーマは私が開発している「Risouto」についてです。



選択肢は2つ

元々お客様だった会社に拾って貰うことなり、社内SEとして業務をこなす毎日。そんな日々を2〜3年ほど続けたある日、転機が訪れた。

前回のエントリの最後にも書いたがこのときいた会社の関連会社にシステム会社があった。合併問題の際にそちらには行かなかったのだが、そのシステム会社から相談を受けた。

その相談というのは、「FOOBARフレームワークを使って作られたシステムをどうにかしたい」という内容。そう、そのシステム会社では私がかつて開発していたFOOBARフレームワークを使ったWebシステムを未だに使い続けていたのだ。

詳細を聞いたところ、合併の話が出た際に「このまま合併先に持って行ってもだれもメンテできないから」ということで(*2)、使用料を支払う形でFOOBARフレームワークを使用し続けることにしたそうだ。

これは短期的には正しい選択だったと思う。というより、そうせざるを得なかったというのが適切か。しばらくはそれで支障なかったようだが、その契約期間満了を目前として選択を迫られることとなった。

選択肢は2つ。契約を更新してFOOBARフレームワークを使い続ける。あるいは、全く新しく作り直すか。

そのシステム会社のWebシステムはいくつかの問題を抱えており、どちらにせよそれを修正しなければならなかった。前者の選択肢をとるなら、また定められた契約期間の間使用料を支払い続けなければならない。その代わりに問題の修正だけ行えば良い。後者の場合は使用料を支払和なくていいかわりに、使用期限内に完全にFOOBARフレームワークを使わないものに全て置き換えなければならない。

どちらが適切か。様々な事情を考慮した上で、後者を選択することとなった。

FOOBARフレームワークを使わないという決定がなされたその場で、また別な相談をされた。「うちでその仕事をやってくれ」と。

FOOBARフレームワークとの再開、模索


結果だけを言えば、私はそれを受けることにした。社内SEをやっていた会社から、システム会社へ。それ以外の事情も後押しして、比較的スムーズに事は運んだ。私だけではなく、FOOBARフレームワークを知る人間が他に2人そのシステム会社に集まっていた。準備は万端だった。

始めにしたことはFOOBARフレームワークからの移植……ではなかった。時が経っていたこともあり、どういう動きだったかすっかり忘れてしまっていたため、まずはそれを調べるところからのスタート。そして、軽微な問題の修正。そうやって、FOOBARフレームワークに関する記憶を手繰り寄せた(*3)。

FOOBARフレームワークを再び目にしての正直な感想。それは「なんだこのゴミは」というものだった。作った奴の顔を見てみたい(*4)。経験値も少なく、古くさいフレームワークであったため、様々なムダと問題を内包していた。また、FOOBARフレームワークは一切のメジャーアップデートがなされていなかったこともその問題に拍車をかけた。そう、だれも育てていなかったのだ。

過去の自分からのプレゼントに悶絶しつつ、平行してFOOBARフレームワークの代わりとなるフレームワークを探す旅に出た。その作業をしていた頃には、FOOBARフレームワークが生まれた頃と違い「オレオレフレームワークを捨ててFLOSSなフレームワークを使うのが当たり前!」な空気が業界を支配していた(*5)。ので、第一の選択肢として、既存のFLOSSフレームワークへの移植を考えた。

結果、その選択肢は排除した。その理由として、

  1. 作業にアサインできるメンバーにFLOSSフレームワーク自体の知識が不足していたこと
  2. 移植に必要な作業が膨大であったこと
  3. 最も楽観的な見積もりでタイムリミットをオーバーしてしまうこと
が挙げられた。本来であれば、もっとも適切かつ推奨される選択ではあったのだが、採用するのは危険であるとの判断がなされた。

では、どうするか。

FOOBARフレームワークをベースに新しいフレームワークを作って移植する?……NO。ライセンスの問題がクリアできないし、FOOBARフレームワークに存在する問題が解決されない。

MEIDO/MOEをつかう?……NO。FOOBARフレームワークよりもゴミなんだ。

素のPHPでコードを組む?……NO。それはそれで大変だし、その後のことを考えると問題を増やすだけだ。

では、どうするか。

こんなこともあろうかと


実はこの時点で、私の手元にはオレオレフレームワークが存在した。プライベートタイムにちまちまフルスクラッチで作り上げた、私の人生において3つめのフレームワークである。社内SEだった頃、仕事では得られないものを得るために進めていたプロジェクトだ。

そもそも、このフレームワークは個人のサイトを作るためのベースとして制作したもので、MEIDO/MOEの反省を踏まえた作りになっていた。設計思想として、MEIDO/MOEを作るときに掲げたポリシーのうち「PHPさえ分かれば使えること」、「シンプルであること」、「拡張が容易であること」の3つの柱を念頭に設計されていた。一部、DB周りなどはPEARのライブラリ(*6)を使っていたり、テンプレートエンジンとしてSmartyを使っていたが、どちらも凝ったことをしなければ習得は容易だ。

そして、CMSライクにつかうために管理機能やニュース機能、ブログ機能を実現するコードが存在していた。これらの機能はシンプルではあるものの、最低限の機能は実装されていてすでに自分のサイトで稼働していた。別な言葉で言い換えれば、フレームワーク本体以外のよく使いそうなコードも存在していたのだ。

最後に重要な点。それらのコードはFLOSSとして公開していた(*7)。このフレームワークはRisolutoと名付けられていた。

FOOBARフレームワークからの移植作業に従事する以前にRisolutoは存在しており、必要と思われる部品の少なくともベースとなり得るものはそこにあった。ならばそれを使おう。そう決めた。それからは後は手を動かすだけだ。メンバーのスキル的にRisolutoがマッチしていたこともあり、それもRisolutoの採用を決定した理由の1つとなった。

Risoluto、大地に立つ


最終的にはFOOBARフレームワークからの切り替えはうまくいった。様々な問題は解消したし、それらは非常に良く動いていた。

そう、その決断によりRisolutoは商用サイトの構築にも使えるフレームワークとなった。もっとも、素のRisolutoにだいぶ手を加えているからRisolutoそのもの……というわけではないのだけれど、まあそれは目をつぶっておこう。

そのシステムからRisolutoへのフィードバックはしなかった。なぜなら汎用的ではない、特殊用途に特化した修正が主だったからだ。その代わりといってはなんだが、プライベートではRisolutoは育っていった。いいなと思った機能はRisolutoに取り込んでいったし。Risolutoはスピードは遅いものの、確かに育っていた。

さて、この後にRisoluto2が誕生するわけですが、そこまでのお話はまた明日。


*1:アドベント・ぼっち・カレンダーの意
*2:他にもいろいろ理由はあったが
*3:諸事情で「記録」は存在しないに等しい状況だった
*4:つ「鏡」
*5:言いすぎではないと思う
*6:PEAR::MDB2
*7:Sourceforge.jpSourceforge.net

0 件のコメント:

コメントを投稿