Web Application FrameworkにBTS機能があればいいのになと妄想している話
TLDR
Web Application開発でよく感じる問題点
Web Application開発を進めているときによく感じる問題点がある。
問題点の前提になるので開発の体制など背景を先に述べておこう。 開発チームの人数は10人前後の小さなチームを念頭に置いている。 開発体制は案件の主幹の会社があり、その下に協力会社がいる。
このような体制で進める開発プロジェクトでよく感じる問題点、 それは何かの決定の過程が記録に残らないことだ。
何かの決定について例をあげる。
- 最も端的なところでは Web Application の仕様
- 仕様に盛り込まないと決めたこと
- アプリケーション動作としては問題だが、現実的な判断から放置することにした
などなどである。 例をあげれば、そういうことならプロジェクトの中で他にもこんな決定をしたことがあると、 思い浮かぶことが多々あるだろう。 そのような決定を下したときに、いろいろな形で議論があったはずだ。 それは1人でいろいろ思案した結果かも知れないし、 数人だったりチーム全員で議論した結果かも知れない。 議論ではなく、外的要因から自ずとその選択をすることもあるだろう。
問題点はその決定に至った背景が記録に残らないことだ。 もしくは記録はExcelやWordで議事録を残しているということもあるだろう。 それについて問題視したいのは検索性が低いことだ。 確かに Explorer を使えばファイル内まで検索できるが、 検索対象に含めるファイルがバラバラに置かれたり、 日にちが経つことで移動されたりなど問題が多い。 多くの人の感覚では何かの決定の経緯を調べるときに、 Explorer でファイルの内容を検索しようという風には連想しないかも知れない。
背景の記録がない、あるいは探し出すのが難しいと問題が起こる。
- 背景を理解していないと、やるべき試験が行えない。
- 本来やるべきでないと結論に至った作業を行ってしまい、 そう言えばやらなくていい作業だったと、以前に行った議論を繰り返してしまう。 無駄な作業の繰り返しが起こる。
- 積み残していた課題を喪失してしまう。
- 新たに加わったメンバーが経緯を知る由がない。
などなど。 自分が置かれている環境がその様な場合が多いだけの印象だろうが、 このような問題は小さいチームの開発でよく起きるのではないだろうか。
王道の回避策 は難しい
この問題を回避する方法の王道は、WikiやBTS(Bug tracking system)を使うことだろう。 だがWikiやBTSなしで進めている開発案件はまだまだ多いのではないだろうか。 それらを運用するとなると、案件の主幹の会社がもつことになるとおもうが、 主幹の会社で導入するのはかなり難しいだろう。 難しいと考える理由だ。
- WikiやBTSの有用性を理解している層が少ない、認知度が低い。
- WikiやBTSの構築を誰がするのか、運用を誰が行っていくか。
- 導入先サーバーはどう手配するのか。
- 実行環境の構築が必要になる。ウェブサーバーを導入し、スクリプト言語の実行環境、それにまつわるパッケージなどの導入がいる
- データベース(以降、DB)も構築、運用しなければならない。
- 導入できたとして、主幹会社でない人間のアクセスをどうするのか。
自ずと共有ディレクトリでルールを決めて、既定の書式でファイルを置きましょうとなる。
Web Application FrameworkにBTS機能があればいいのに
そんな困難を乗り越える解決策として妄想するのが、 開発で採用するWeb Application Frameworkに、 Out-of-the-boxで使えるBTS機能が組み込まれていることだ。 もしくは各プログラミング言語のパッケージマネージャーだけで、 開発している製品で利用するライブラリかのように導入できるBTS機能だ。 Frameworkの一部だったり、利用するライブラリかのようであれば、 BTSそのものを導入するための許可の難易度が下がるだろう。 導入先のサーバーだが、さすがに開発案件を進めているのであれば、 開発用のサーバーあるはずだ。 開発しているプロダクトの一部なのだから、 当然、開発しているサーバーにのせることになる。 実行環境も開発しているプロダクトを動かすわけだから、そこにあるはずだ。 データベースもしかりである。
そんなわけで、Web Application FrameworkにBTS機能があればいいのになと妄想している。