ソフトウェア開発では、機能拡充と品質向上は両立しなくてはならない２大目標だ。
いずれにせよ時間的犠牲が欠かせないため、ある瞬間に機能と品質のどちらを優先するか折に触れて選択を迫られる。
最近は「品質確保を先行させた方が良いのだろう」という結論に至ることが多い。
これはおそらく、人件費が何よりも高い、とくにアウトプットあたりのコストに換算するとさらに割高になる、という経済的な制約条件による。
品質上の欠陥はそのままやり過ごすことはできず、サポートなど何らかの代替資源でカバーしなくてはならない。
ソフトウェアは機能に合わせて肥大化していくから、パーツごとの至らない品質ネックは組み合わせ爆発により大きなトラブルに成長し得る。
そして、組織はピーク業務に合わせて人海戦術をとりがちであるため、潜在ワーストケースの大きさの分だけビジネスは減速する。
これが機能優先で進行した場合のシナリオだ。
先進国でこの前提を変えるには生きることのコストを下げる必要があり、そしてそれを示唆する兆候はまったくない。
品質を優先する場合には、「世にリリースしなければ問題は起きない」という点も含めてトラブルのピークを制御できるため、行動あたりのロスを低減できる。
品質制御の実情
品質は良し悪しで捉えがちだが、ベストプラクティスによってシックス・シグマが適切だと思う。
つまり主役はバラつきの度合いだ。
バラつきはエントロピーや情報量の挙動と同じであり、好ましい状態を技術的に識別できる。
基本的な手法はシステムテストが適している。
実際の環境に近い条件を揃え、テストケースと頻度を増やすことでバラつきを効果的に追跡できる。
実際の環境は完全に一致させる手もあるが、それすら実環境のごく一例に過ぎないため、要するにパーツを網羅的に組み合わせることが第一と言える。
目標の達成度合いは簡単に言えば「１つの失敗も許容できない」水準になる。
そしてここのところテストが通過しないケースが増えていて、構造を掘り下げて追跡してきた。
パーツの調達に左右される
今どきのソフトウェアは無数のライブラリ、その多くがオープンソースを組み合わせて開発する。
その結果、品質のかなりのウエイトをオープンソースのフィッティングが占めていることを改めて確認した。
オープンソースの品質は一概に言えない。
各ソフトウェアで体系的に品質確保している例や、採用しているプロジェクトのフィードバックの蓄積によってバラつきを制御できているケースもあるし、中にはただただ自由なプロジェクトもある。
ただ、バラつきの大きいライブラリの影響を直接受けることは、状況を分析して理解できた。
品質の高いオープンソースを厳選したら気楽と言えるかもしれないが、人類史のなかでオープンソースの歴史は浅く、そこまでの蓄積はまだない。
自製、外注、オープンソース参画のいずれかの立場から選択することになる。
ソフトウェア開発は1960年代から広まっていったが、90年代までの多くは自製や外注で作られ、機器・システムの陳腐化に伴ってただ破棄されてきた。
オープンソースの場合は即座に社会資本の蓄積が進み、ここまでのコモディティ化の進展にも貢献してきたし、未来の社会機能として生き残って行くだろう。
また多用途で使われることじたいが品質にとってはプラスでもあり、手間はかかってもオープンソースには独特のメリットがある。
オープンソースの品質確保
オープンソースはバージョンアップごとに機能が変わることが多くあり、使い方の工夫で自分のプロダクトにフィットさせられることも多い。
ただ、バージョンごとにライブラリに合わせているといたちごっこになる展開があり、その場合、バラつきは制御できない。
各ライブラリは複数の目的に使えるように進められていることが多いが、そのうち特定の目的では自分のプロジェクトの方がより実態をつかんでいることがあり、同時にバラつきも起きやすい。
自分の用途を一般化した具体的な修正を提案できれば、安定的なインターフェースを確保できる。限定的な条件で起きるバグ修正の場合も同じだ。
提案は各ライブラリの発展性に沿っている必要があるため、対象についてよく理解することは当然の前提となる。
いずれにしても品質の再現性を確認する時点で、コード追跡や設計思想などは追跡することにはなる。
また、提案するのは自由だが、採用されるとしても時間がかかり、その形は変わることもある。
この点については別途対策が必要で、けっきょくのところ最小限の自作パッチを当てた独自バージョンを派生させた方が制御しやすいと考えている。
このように、自分のプロダクトから見たオープンソースの品質を能動的に制御するには相応の手間がかかる。
しかし、受け身で待っていても進展がない。
GitHubにはプロジェクトの議論経緯も公開されており、けっきょくのところ主な開発者の力量から今後起きることと起きないことは相当推測できる。
時おり著名プロダクトの開発体制の手薄さが話題になるが、相対的に手薄であることはいずれも大差ない。
のるかそるかは時の運ではあるが、何か建設的にものが言えるような状況であれば、それができるのは世界で自分しかいない、と考えた方が良い。
典型的には１人で孤独に頑張っているライブラリは本当に多い。
難しいケース
オープンソースは「受け入れてもらえれば」という前提があり、そうでない場合にはまったく違う手を考えなくてはならない。
広く使われているものでもたまにプロジェクトが分裂することがあり、その多くはパッチの拒否が続く場合だ。
GitHubの議論から、主な開発者がとんでもないヤツだと分かることが稀にある。
問題の原因は特定できるが、解決のしようがない、という類型になる。
こういうものの取り扱いはかなり困る。代替策があるなら採用していないだろう。
ある例では、動作確認のとれている旧バージョンに戻してバージョン固定とした。
先送りの対象については、一定の期間のうちに解決がなければ、その部分を丸ごと迂回して避けられるような根本的に別の設計を考える必要が出てくるだろう。
