top / index / prev / next / target / source
日記形式でつづる いがぴょんコラム ウェブページです。
blanco Frameworkの仕様は継続的な改善に取り組んだ結果として今のような姿になっています。
blanco Frameworkのキャッチを考えていて、ふと気がつきました。blanco Frameworkは開発工程の継続的な改善に取り組んだ結果として、今のような姿になっています。当初から現状の姿を予想できていたものではありません。そしてそれはその当時としては不可能であったと現時点においても考えています。
そもそも当初は R/Oマッピングツールが欲しかっただけに過ぎません。
R/Oマッピングツールが出来上がって問題点がそこでは無くなると、次に別の問題点が最大の問題点へと成長します。
blanco Frameworkとして見てみると 仕様書からXMLファイルへの転記作業だったのです。だから次に取り組んだのは転記作業の自動化です。
R/Oマッピングが克服できたら、次に気になったのが Apache Strutsの生産性です。だから blancoStrutsに取り組みました。
プロパティファイルと その定義書の間の乖離についても、問題点として浮き彫りになったので そこに取り組みました。
さまざまな改善活動の取り組みの過程において、ツールに機能を追加する場合もありましたが、おのおののツールが完成系に至る過程では むしろツールの機能削減やソースコード規模削減に取り組んできました。これは私たちにとって非常に重要なポイントとなります。
ウォーターフォール的な開発モデルとはせずにアジャイル的に取り組んできたことも重要な判断ポイントであったと考えています。そもそも開発工程の改善についての正解となる観点は取り組み時点では不明だったのです。アジャイル的に取り組んだからこそ、個別のツールよりむしろツール間の転記作業こそがプロジェクト上のボトルネックであるという点に気がつくことが出来ましたし、そこに取り組んで改善を行うことが出来ました。まあ、今の時点ではかなり明確に (そしておそらく正確に) トータル生産性向上のための改善ポイントについて、適切な観点を持った改善を行うことが出来るようになっています。でも、それも外的要因により状況が変化する可能性は高いです。だからこそ手作りシステム開発なのでしょうけれども。(外的要因によるドラスティックな変化が無いのであれば、そもそも手作りでシステム開発を行う必要が無いのでしょうから)