hidekatsu-izuno 日々の記録

プログラミング、経済政策など伊津野英克が興味あることについて適当に語ります(旧サイト:A.R.N [日記])

因果推論とは何なのか

最近、因果推論がはやっている。はやっているのだが、これがさっぱりよくわからない。いろいろな方が資料を公開してくれているので手がかりはたくさんあるものの、手法が中心になっているものが多く、統計学全体からみた位置づけのような理解に必要な情報が欠けている。

前回の記事で書いたように、因果性は科学哲学において難問とされており、いまだ定義できないものとされている。定義できないのに因果推論とはどういうことなのか。

過去、統計学の文献を開くと「重回帰分析で因果関係はわかる」「ベイズ推定で因果関係はわかる」といった記述をたびたび見かける。今までの「因果関係がわかる」と因果推論の「因果関係がわかる」は何が違うのだろうか。

今回は次の資料を元にどのように理解すべきか考えてみたい。例によってまったく専門家ではないので、間違った理解に基づいている可能性は極めて高いことをあらかじめ断っておく。

まず思ったのは「因果性の必要十分条件は○○である。因果推論手法Xは○○を満たしているから因果関係を明らかにしたと言える」という問題文に照らしてはどうか、ということだ。これについては政治哲学でも有名なジョン・スチュアート・ミルの「ミルの三条件」が知られている。

  1. XはYよりも時間的に先行していること
  2. XとYの間に関連があること
  3. 他の因果的説明が排除されていること

しかし、これは必要条件に過ぎない。前述のように、因果性の必要十分条件はいまだわかっていないのだから当然だ。とはいえ、スタートラインとしては良いのではなかろうか。

まずは、重回帰分析が3つの条件を兼ね備えているかみてみよう。2の関連性はわかりそうだ。だが、時間的先行や他の因果的説明の排除はできそうにない。ベイズ推定はどうだろうか。2 に加えて条件付き確率の存在によって 1 も解決できそうだ。しかし、3 の他の因果的説明の排除はできそうにない。

一方、因果推論は 3 の他の説明の排除という部分に重点がおかれているように見える。2 の時間的先行についても「介入」という概念により対応できている。

各種資料から私が理解した限り、「因果関係がある」というためには「A. 因果グラフを作る」⇒「B. 因果グラフを整理する」⇒「C. 統計手法を使い関連が実際にあるのか確認する」という3段階が必要となる。この整理に基づけば、バックドア基準、傾向スコア、ランダム化比較試験といった手法はいずれも「B. 因果グラフを整理する」ため手法だと言える(ランダム化比較試験では因果グラフが不要なようにも見えるが、実際には「その他の因果関係すべて」を列挙した上で、ランダム化により影響を排除するよう調整しているとも解釈できる)。

前述の「重回帰分析で因果関係がわかる」という記述も、A、B が満たされた因果グラフがある前提で C を実施した、と解釈すればおかしいとは言えない。勉強時間と成績のように因果グラフが明確でサンプルサイズが増えれば他の変数の影響も緩和されるような内容であれば問題ない。ようするに因果推論に足りない要素を人間が記述で補っているということだ。

これはベイズ推定でも同様だろう。「現代哲学のキーコンセプト 因果性」によれば確率論的アプローチには因果が重複したり過剰であったりする場合の解決ができない。外的な記述で補う必要が出てくる。

とはいえ、因果推論の使用もあらゆる意味で因果関係を解決しているわけではない。「A.因果グラフを作る」という点については人間の作業によっている。*1また、前述のサイトにも書かれているように「ミルの3条件」以外の条件、例えば「因果関係を想定することが妥当と考えらる理論的裏付け」、「データの収集が適切であること」はいかなる因果推論手法を用いても決して解決するとは思えない。

ようやく因果推論が何なのかわかった気がする(気がするだけかもしれないけど)。因果推論は、今まで統計手法を否定するものというより、人間の記述によってしか解決できなかった因果の条件と解決法を明確化するための補完的な手法と理解するのがよいのだろう。

*1:これには因果推論の役割ではなく、因果探索という別の手法が用意されている。

確率を解釈する

世間的には因果推論の話題ばかりだが、因果以前に確率の理解すら覚束ないので「現代哲学のキーコンセプト 確率」という本を読んでみた。

 以前、議論になったので、頻度確率と主観確率のふたつがある、ということは知っていたのだけど、科学哲学方面の理解は(予想していたものとは)かなり違っていて驚いた。

まず、確率には頻度論に代表される「世界ベース」の確率とベイズ推定でしばしば言及される主観確率に代表される「情報ベース」の確率がある。「世界ベース」というのは、サイコロを振ったら6分の1の確率で1が出る的な普遍性のある確率で、中高生が学ぶ確率といえばこちら側の概念だ。

しかしながら、その代表である頻度確率は科学哲学側ではあまり適切な解釈だとは思われていないようだ。なんと言っても、頻度は過去のデータであって、それが未来の予測にまで使える保証がない。統計の世界では IID(独立同一分布)を仮定することで予測に使うが、それ自体に根拠があるわけではない。単に便利で常識的だからに過ぎない。

統計の世界も科学の世界と同じく意外に実利的だ。確率は頻度です、という表現は科学哲学の議論を読む限り厳密には間違いというべきかもしれないが、そのように捉えても実用上特に困ることはない以上、(ベイズでない)統計学は(専門家が書いた専門書であっても)頻度をベースにしているという説明で良しとされている。

そう考えると、「重回帰分析を使って因果関係があると書いているが、因果関係を求めたいなら統計的因果推論を使うべき」、というような言論は適切ではないだろう。科学哲学では因果が定義はいまだ定まっていないということになっているし、逆に統計的因果推論を使ったからと言って確実に因果関係があることを示せるわけではない。重回帰分析であっても、条件を満たせば因果推論と同じことが言える場合もある。ようは「因果関係があるかもしれなさ」の根拠がどれだけあるかだけの話だ。実利に従って判断すればいい。

本書を読む限り、現代では「客観的ベイズ主義」と「傾向性解釈」が今風の確率解釈であるようだ。前者の「客観的ベイズ主義」は「主観的確率解釈」に対する「各人が勝手に確率を決められるなら比較できないじゃない」という問題提起に対し「主観確率は過去のデータからの合理的推論によって制約される」という制限を入れようという考え方のようだ。「情報ベース」でありながら「世界ベース」も包含できるので、たしかに良さそうにみえる。

もうひとつの「傾向性解釈」は、ものに「重さ」があるように、物事には特定の状況で「傾向性」があると考える解釈だそうだ。正直、言葉遊びのように思え、よく理解できなかった。

「客観的ベイズ主義」も、同書で指摘されるようにたしかに無理やり感はあり、それは本当に「確率の解釈」なのかと言われると微妙な顔になる気持ちはわかるけれども、あくまで統計ユーザーが使うには便利な解釈であるように思える。

 

「『アジャイル vs ウォーターフォール』からプロジェクト管理を考える」という記事を公開した

最近調べていたプロジェクト管理に関する論文を読んだ感想を Qiita に公開した。

このブログに書いてもよかったんだけど、広く読んでもらったほうがいいやと思って Qiita に投稿してみた。まぁ、結局あんまり読まれないんだけどorz たしかに今更感ある内容ではありますな。

今回、いろいろな論文を実際に読んでみて、こういう結論になるんだろうな、と思っていたことと違う方向に話が進むこともあり、何でも調べてみるもんだな、と。以前なら英語論文一本読むのに数日がかりだったけど、DeepL翻訳のおかげで多少の前処理さえすればサラサラ読めるのは本当にありがたい。

プロジェクト管理に関しては、この業界に 20 年近くいることもあり、これが重要、という勘所があるんだけど、論文では意外に重要視されていないようなので、代わりにこちらに書いておこうと思う。(そういうことなので、まったく学術的根拠はない)

プロジェクトを成功させるために最も重要なことは、適正な予算を確保すべく見積りすることだと思う。予算がない=工数がない、ということだし工数が下振れしているということは工期も不足していることになる。少ない工数・工期でなんとかしなければならないので、テストはおざなりになり品質も下がる。開発者は精神的にも体力的にも消耗するし、上司も顧客も怒らざるを得なくなるし、PMの評価も落ちる。関係者全員が不幸になる。解決方法は簡単で、妥当な予算が得られない、あるいは妥当な見積りが作れないくらい不確実性の高い案件は受注しないことだ。妥当な予算の元でプロジェクトを進める場合、多少トラブルがあってもプロジェクトが完全に破綻することはあまりないと思う。

あとは何だろうか。最近思うのは、PM が決断せずに曖昧に物事を進めるのはあんまり良くないな、とは思う。前述の記事でも「曖昧な要素を確定させていくのがプロジェクトマネージャーの役割」と書いたけれど、何事も落とし所らしきところで一旦決めてしまった方が良いと思う。決めると問題が見えてくるから、そこから各個撃破していけばいい。人間、不思議なもので決めないとまじめに考えないから問題がなかなか表に出てこない。

これでだいたいうまくいくと思うけど、もうひとつ言うなら頑張りすぎないということかも。例えば現行システムをリプレースするような案件でがんばって何でもかんでも変えると仕様が発散しがちになる。困っていることに注力して、誰も困ってないことはいじらない、という自制心が大切です。

続・アジャイルに根拠はあるのか? 「A Comparison of Software Cost, Duration, and Quality for Waterfall vs. Iterative and Incremental Development: A Systematic Review」を読む

前回に引き続きアジャイルの是非を調べるために論文を読んでいる*1

今回、紹介するのは 2009 年のウォーターフォールとスパイラル型開発を比較した「A Comparison of Software Cost, Duration, and Quality for Waterfall vs. Iterative and Incremental Development: A Systematic Review」という論文。先に断っておくと、この論文でも「ソフトウェア開発プロセスの比較に関する実証的な研究はほとんど行われていない」ことに触れられており、スクリーニングの結果残った5本の論文だけを元に論じられている。

とはいえ、それでもなかなか興味深い結果が得られている。ウォーターフォールとスパイラル型のモデルで「どちらが優れているかを裏付ける証拠はほとんどない」ものの、以下の命題については調査する価値があると述べている。

  1. XP型の方がウォーターフォール型よりも多くの工数を必要とする。
  2. XP型の方が、ウォーターフォール型よりも、要求に対する努力が少なく、テストに対する工数が多い。
  3. ウォーターフォール型よりもXP型の方が、プログラマーの生産性が高い。
  4. 連続的なプロセスよりも非連続的なプロセスの方が、工数見積りが正確になる可能性が高い。
  5. ウォーターフォール型よりもXPの方が高品質な製品になる。

1と3の結論は一見矛盾している。コードは多く生産されるが、総工数は多くなりがちでは生産性が高いのか低いのかよくわからない。しかし、XPの方が捨てるコードが多くなることを高いことを考えれば、さほど矛盾しているわけでもないのかもしれない。捨てるコードが多ければ、5のように高品質な製品になるのも頷ける。

4は単に見積りは遅延させた方が正確である以上の話ではないように見える。

一方、気になるのは2だろう。前回、アジャイル開発では設計が不十分になりがちという話があったが、やはりインクリメンタルな開発を主軸を置くと、品質は高まる反面、要件定義や設計が必要な場面でじっくり考えないという傾向は否めない。少なくとも目的やコンセプトやグランドデザインのようなものは、アジャイル開発をするのであっても、別途、落ち着いて考えるフェイズを設けた方がよさそうだ。

*1:いや、本当に Deepl翻訳はすばらしい。

アジャイルに根拠はあるのか? 「Empirical Studies of Agile Software Development: A Systematic Review」を読む

世間的にずいぶんアジャイルという言葉が市民権を得てきたものの、日本においてはいまだウォータフォール全盛で、例えば多くの企業が参加する IPAソフトウェア開発データ白書」によれば開発プロジェクトのうちウォーターフォールが全体の97.4%を占めており、アジャイル開発を含む反復型開発は 1.7% に過ぎない。

一方アメリカではかなり普及しているという話があるものの具体的なデータは見つけられなかった。多く見つかるのは「State of Agile Report」のアメリカ企業の95%がアジャイルを採用しているといった数字だが、会社で1回でもアジャイル開発を行えばカウントされることを考えればあまり意味はないだろう。すべてのプロジェクトでアジャイル開発をしているのは18%に過ぎない(十分多いとは思うけれども)。

アジャイル開発の方法論を踏まえれば、サービス型の企業であればアジャイル型で開発するのが自然であるし、アメリカではエンジニアを自社で集めて内製開発する企業も多いと聞く。ウォータフォールよりアジャイルの方が優れているかどうかとは関係なく、単に業種業態や歴史的な経路に依存するだけの話なのではなかろうか。

私自身はシステム会社で企業の基幹システムを中心に開発していることもあり、正直アジャイル開発を肯定的には捉えていない。XP自体は素晴らしい発想だとは思うが、それはあくまでソフトウェア開発の理屈であり、プロジェクト管理とは異なる次元の話であるように思える。しばしば、ウォータフォールは問題点ばかりが挙げられるが、特に大規模システムでは明確な利点もある。

とはいえ、世の風潮としてはアジャイルの素晴らしさを喧伝する声で溢れているのも事実だ。それらの喧伝がもし本当であれば、私はただの老害ということになる。

やはりまずは事実関係を調べるべきだろう、ということで実証研究系のサーベイを探して出てきたのが、今回紹介する「Empirical Studies of Agile Software Development: A Systematic Review」だ。2008 年の論文であり、やや古いようにも感じるが、引用数もそれなりに多く、内容も網羅的である。*1

まずは結論

先に結論だけ言うと、アジャイル開発が優れているとする学術的根拠はない。ただし、主たる理由は「研究の示すエビデンスの質が低い」ことによる。例えば、ある研究では良い結果が得られたが、別の研究では逆の結果が報告されていたりする。量の問題もある。アジャイルに関する論文は多いが、報告の多くはアジャイルを推進者であり、対象プロジェクトのメンバーの一員であることも多く、成功を報告しやすいインセンティブがある。客観的な実験計画に従った信用に足る研究は少ない。

しかし、これは昔の話かもしれない。最近ではどうだろうか。例えば、2016年の「Challenges and success factors for large-scale agile transformations: A systematic literature review」という論文がある。しかしながら、Abstract を読むと「収録された論文のほぼ90%が経験談であり、このテーマに関する健全な学術研究が不足していることを示している」などと書かれており、状況はあまり変わってなさそうだ。

アジャイル開発の唱導者は、アジャイル開発の良さを喧伝するが、現実の社会で実際に行われるプロジェクトには多くのバイアスがある。まず、アジャイルに適合しやすいプロジェクトほど実際にアジャイル開発を採用しがちだろう。一方、ウォーターフォールは適合可否に関わらずデフォルトの選択肢として採用される。

アジャイルは新しい考えであるから、そのプロジェクトには積極的な顧客や能力のあるPM、開発者が集まりやすいという事情もあるだろう。

宣伝という面でも、アジャイルの成功は積極的に広報されるのに対し、いまさらウォーターフォール開発での成功は報告も喧伝されない。

アジャイルウォーターフォールのプロジェクトをその成功数で単純比較するというのは非常にまずいやり方だ。

というわけで、今回は前述の論文など数本読んだ感想として、4章に書かれた結論をベースをこの面では効果がありそう、ここら辺はそうでもないのでは? という伊津野の感覚値を書いていくことにする。特にアジャイル開発に対して否定的なコメントは研究のインセンティブから考えても一定の意味があると考えている。

アジャイルの採用について

アジャイルの導入に際し必要な労力を過小評価すべきでない、という見解が書かれている。導入がスムーズにいったケースでも「最初の1週間は大変」という報告がされており、「How Agile Impacts a Software Corporation: An Empirical Study」という2018年のアジャイルに肯定的な論文でも「ビジネスの一時的な停滞があった」と書かれている。

個人的見解としても、ウォーターフォール開発の利点のひとつは誰もが知っているということがある。現在、基本設計フェイズです、システムテストフェイズです、と言えば、だいたいプロジェクトがどれくらいの状況にあるのかわかるし、新たに参画するメンバにどのようなスキルが必要なのかも想像がつく。

この項目に関して「XPチームはコミュニケーションが改善されたが、他のチームからは孤立していると認識されている」という記載はやや気になる。アジャイル関連の肯定的意見としてチームの一体感、ワクワクした雰囲気などが語られるが、一方で大規模プロジェクト全体としての一体感は損なわれているのかもしれない。ウォーターフォール開発では管理チームや他チームとの調整に多くの時間が割かれるが、逆に言えばプロジェクト全体のコミニュケーションは取りやすいとも言える。自身のチームの一体感を向上させることは得てして他のチームからの要求を拒否しがちな状況を生むことも考えられる。

組織文化、コミニュケーションについて

アジャイル開発では「顧客とのコミニュケーションが改善」され、「チーム内の会話が増え」、「欠陥に対するより迅速で徹底した対応」が得られるなど、組織文化、コミニュケーション改善に関する報告が多い。一方で「顧客はストレスを感じており、長時間労働を強いられてい」たり「フラストレーションが溜まり、生産性が低下した」人や「週に40時間もペアで作業するには集中力が必要であり、その結果、開発者は疲労困憊してしまった」人もいたようだ。

XPのプラクティスはたしかに顧客の積極的関与を生むが「持続性がないようにも見えるので、特に長期にわたるプロジェクトやプレッシャーの大きいプロジェクトでは大きなリスク」となる可能性も指摘されている。

アジャイル開発に関する議論全般に感じるのは、参加者に求められる意識が高すぎるのではなかろうか、ということだ。顧客にやる気があって、PMやメンバーにやる気があれば、ウォーターフォールであろうとなかろうと、そのプロジェクトはだいたい成功するだろう。実際の(特に業務システムの)プロジェクトでは、さほど改善を求めるでもなく、できるだけ安い金額で今まで通りのことができるようにリプレースしてほしい、ということも多々ある。大規模プロジェクトの実態を知っている人間としては、前提に違和感を覚える。

プロジェクト管理について

「小規模なリリースと迅速なフィードバックを伴う短いイテレーション、ユーザーの密接な参加、絶え間ないコミュニケーションと調整」によって知識が共有され、知識を創造し活用できるようになるという利点が挙げられている。一方で「ドメイン知識を持つ熟練したチームメンバー」は必須でありそれがなければうまくいかないこと、技術的問題がプロジェクトの早すぎるタイミングで上がってきてしまうこと、デザインやアーキテクチャに関する議論が十分に行われにくい、という問題が報告されている。

特に「技術的問題がプロジェクトの早すぎるタイミングで上がってきてしまう」というのは気づきにくい観点だと思う。プロジェクト失敗の理由の半分以上が要件定義フェイズにあると言われており、技術的な課題は必ずしも重要ではない。技術的な問題を解決するために労力が取られ、プロジェクトの本質的な課題解決がおそろかになってしまうのでは本末転倒だ。

品質と生産性

他にもいくつか関連する論文を読んで気づいたが、アジャイル開発を行うと品質が上がるという報告については一貫した傾向があるようだ。一方、生産性については良い報告もあれば逆に悪化したという報告もあり一貫していない。XPチームがV字型チームに比べ 3倍の生産性を発揮したが、調べてみると同じ機能を作るのに 3 倍の量のコードが存在していただけだった(むしろ生産性は下がっていた)という話が載っていて、ちょっと笑ってしまった。

「デザインやアーキテクチャに関する議論が十分に行われにくい」という話については「従来のチームの方がより優れた、より一貫性のあるユーザーインターフェースを開発した」という話も出ているので、やはり継続的開発とは別にアーキテクチャデザインの期間は必要なのだろう。

個人的な評価

アジャイル開発のウォーターフォールに対する利点ばかりに目が行き、アジャイル開発の利点がそのまま欠点にもつながっているという視点はなかったので、そこは面白かったです。とはいえ、思ったより実証研究が少なく、アジャイルとウォータフォールの成功率の実態を調べたかった身からすると残念な状況でした。同様のサーベイ論文で新しいのを知ってたら教えて下さい。

*1:研究の世界は日進月歩のように思われるが、意外に気の長い世界なのではないかと論文を読んでいると思ったりもする。日々、新しい知識で更新されていくのは機械学習分野くらいで、他の分野では近年=ここ20年くらいというイメージがある。

「A Theory of Team Coaching」を読んでみたら

Twitter でリーダブルコードなどの翻訳を行っている角征典さんが「A Theory of Team Coaching」という論文を紹介していたのだが、内容が興味深かったので読んでみた。

この論文自体は既存研究の問題点を指摘し、どうすればコーチングがうまくいくのだろうか、という視点で研究されているため、いろいろ学びの多い内容となっている。

……と思って読み勧めていると、実はこの論文最後にとんでもないオチが書かれている。

One could conclude, therefore, that few scholarly resources should be expended on research on team coaching because it is of so little consequence. Moreover, one could view the reports from the field (cited in the introduction to this paper) that team leaders spend less time on team coaching than on any other category of leader behavior as a sign of team leaders’ wisdom. Rather than spend time on an activity that so rarely makes a difference, leaders might be better advised to focus on aspects of their leadership portfolio for which there is a greater return from effort expended.

DeepL翻訳を使いつつ訳すとこんな感じ

したがって、チームコーチングの研究はあまり重要でないため、学術的な資源を費やすべきではないと結論づけることができます。さらに、チームリーダーがチームコーチングに費やす時間は、リーダーの行動の他のカテゴリーに比べて少ないという現場からの報告(本稿の序文で引用)を、チームリーダーの賢明さの表れと見ることもできます。リーダーは、ほとんど変化をもたらさない活動に時間を費やすよりも、費やした努力からより大きなリターンが得られるリーダーシップポートフォリオの側面に集中することがより良い助言になるかもしれません。

 ようは、コーチングの効果は今の所あんまり重要ではないので、考え方を変えて、効果のあるコーチングの条件を探すことにシフトしようという主張のようだ。

では、その条件とは何か。

  1. 動機、進め方、知識・スキルなど、パフォーマンス発揮のキー項目がタスクや組織の要求によってそれほど制約されていない
  2. チームが活動する組織的背景がチームワークを妨げるのではなくサポートするものであること。
  3. コーチングがメンバーの対人関係ではなくタスクのパフォーマンス向上に焦点が当てられていること。
  4. コーチングがチームが受け入れ体制の整ったタイミングで行われること。努力や動機づけに関する介入は最初に、進め方に関する介入は中間に、知識やスキルに関する介入は最後に行う。

最初のふたつはある意味当たり前なので良いとして、後半のふたつは役に立つ助言かもしれない。

過去の経験を振り返っても、しばしば対人関係がプロジェクトの問題として出てくることがある。この論文に従えば、そういう場合でも対人関係に介入するのではなく、あくまでタスクのボトルネックを解消させるように動いた方がよさそうということのようだ。

また、タイミングについても早期発見と何でも早めに介入すべきと思われがちだが、少なくとも進め方については、プロジェクトの参加者がそのプロジェクトの全体像をきちんと把握した中盤に介入しなければならない、というのはその通りではないかと思える。

チームコーチング自体、効果が薄いようではあるが、特に対人関係に介入しても無駄、というあたりは実際のプロジェクトでも役立てられそうな知見ではなかろうか。

ソフトウェア・テストを再考する

私が SI という業務システム中心の受託開発業界にいることも多分に関係していると思うのだけど、ソフトウェア・テストに関する各種の方法論に対してどうしても懐疑的な考えを持ってしまう。端的に言ってしまうと「それは私(あるいはSI業界)がテストに関して抱えている問題を解決してくれる」ようには思えないからだ。

 

ここで言う一般的なソフトウェアテストの文脈での方法論というのは具体的には次のようなものを指している。

 

もちろん、これらの方法論は使っていないわけではなく、単体テストケースのケースを考えたり、網羅度を上げるために使うわけだけれど、ある意味テストをするなら誰しもが考えることをより確実に実施するためのものであって、それ以上のものではないように思える。

 

「私(あるいはSI業界)がテストで困っていること」と「ソフトウェアテストの専門家が解決したいと思っていること」の間には大きな開きがあるのではないか。最近話題となった COCOA の不具合や東証の障害にも関係する部分なので、まずはどういう問題に困っているのか具体的に書いてみようと思う。解決策も書きたいところだが、なかなか決定打がなく意見があれば Twitter などで聞かせてほしい。

1. 多様すぎる環境

覚えている人も多いだろうが、業務システムといえば Windows XP + IE6 という牧歌的な時代が長くあった。IE6 には様々な問題があったとはいえ、環境がひとつしかないというのはテストする立場からすれば大変ありがたいものだ。

 

スマホが一般的な時代となり、ビジネスにおいても iPadmacOS を兼用する会社も増えてきた。この流れを受け、業務システムと言えども動作環境を縛るということが難しくなってきた。OS だけでも Windows, macOS, iOS, Android の四種類、ブラウザも IE, Edge, Chrome, Safari, Firefox に対応が必要となる。バージョンやデバイスの違いも含めるとその組み合わせは膨大なものとなる。

 

業務システムで意外とハマるのが、IE や Edge の互換性表示(あるいはエンタープライズモード)問題だ。インストールされているのは IE11 や Edge なので利用者はそのつもりになっているのだが、旧システムのドメインを引き継いだ結果、IE7 や IE8 相当で表示され動作しないというクレームに繋がることがある。意外な盲点として RPA ツールもある。IE のCOMコンポーネントWebKit の古いバージョンを使っていたりするため、今までできていた業務ができなくなったというクレームが来ることがある。

 

また、ブラウザの自動更新も便利な一方で扱いが難しい。発注側がエンドユーザーに提供する際には、サポート環境として「各ブラウザの最新2バージョン」などと書くのが一般的だと思われるが、請負で開発する側には存在しないバージョンでの動作保証はできない。*1

 

請負側で動作保証できる最後のタイミングはシステムテストなのだが、システムテスト時点のバージョンで動作保証したところで、ユーザーテストからリリースまでの期間で動かなくなったり、状況が変わったらどう対応するのが正解なのだろうか。最終的には契約で決まるといはいえ、「良きに計らえ」を旨とする日本の SI 業界ではそう割り切れないのが現実だ。

2. 複雑すぎるライブラリの依存関係

Java にしろ Node.js にしろ、現代の業務システムはオープンソースソフトウェアなしには何もできない。たとえ外部のライブラリを使わなくとも、言語に含まれる標準 API には依存せざるを得ない。

 

数画面しかない業務システムであっても、数百~数千のライブラリが依存関係に含まれるのが当たり前の時代にあって、それらのライブラリにどのような不具合や脆弱性が含まれるか、利用者がすべてのソースコードを理解することは不可能だ。もはや祈りを捧げるしかない。

 

テストしてみたら動かない、のであれば一般的なテスト技法で事前に回避できるのだが、次のように特定の条件、状態でないと再現しないものは、原理的に解決は難しい。

  • レースコンディションに伴う不具合
  • まれにしか発生しないシステムエラーに伴う不具合
  • EXCELや画像など多様な可能性がありえるファイル形式の読み込みに伴う不具合
  • 言語ランタイムの細かいバージョン差異に伴う不具合

ライブラリのあるバージョンで見つかった不具合を解消するためにパッチバージョンを上げたら別の場所でエンバグしていたということもあり得る。実際にはそんなにないから大きな問題になっていないだけで、起こらないという保証はどこにもない。

3. 誰も知らない旧システム仕様

私がシステム開発の業界に入った20年前にはシステム化されていない業務をシステム化するという仕事も結構あったが、現在では多くの業務はすでにシステム化されており、さらにもはや3代目、4代目などということが当たり前になってきた。

 

動いているのだから変えなくてもいいのではないかと言う人もいるのだが、前述のように業務システムの利用環境は多様化しており、機能性が十分だから変えなくてもいいという状況にはない。モバイルだと一画面に表示できる項目数も限られるため、UI も大幅に見直しが求められる。

 

この時問題になるのは、もはや誰も旧システムの機能や細かい仕様をすべて把握していないということだ。発注側であっても、表面的な知識はあっても、夜間バッチジョブでどのような処理が行われているかや、離れた機能が実は関連しているなど、知らないことはたくさんある。

 

特に業務システムにおいてはひとつのシステムで完結することはめったになく、数十のシステムが有機的に紐付いている。そのシステムの仕様は知っていても、仕様を変更した結果、連携先システムのどこにどういう影響が及ぶかを確実に掴むことは至難の技だ。

 

仕様を誰も知らない以上、設計も実装もテストもすべて通り抜け、ユーザーテストやリリース後に発覚することになる。特に旧システムや連携先システムにテスト環境がない場合、本当に祈るしかないという状況になる。テストできないのに障害を起こすなとはこれ如何にという話だが、現実にはしばしば発生する。

 

これに関しては、ある程度解決策があると考えている。それは旧システムのソースコードをきちんと読むということだ。SI開発あるあるなのだが、業務システム開発の上流工程にはソースコードを読めない人が多く、設計書や発注元へのヒアリングだけで設計を進める人も多い。しかしながら、発注元も確実ではなく、設計書はしばしばメンテナンスが不十分である以上、ソースコードをきちんと読む以外に回避に繋がる道はないのではと思う。

4. 実施したことになっているテスト

前述のような状況なので、現在の業務システム開発は、仕様を整理して新システムを設計するだけでものすごく時間がかかる。日本のシステム開発はお金がかかる、人月商売の弊害だ、という意見を見聞きするが、一般論としてプロジェクト費用の60%ほどは実装以外の部分で発生しているし、システム開発失敗の原因の50%は要件定義フェーズにあるとされている。実際問題、要件定義がばっちりうまく言っているのに、ソフトウェアの製造で失敗する、というケースはめったに見ない(無いとは言わない)。

 

こんな状況なので、設計作業は遅れに遅れ、結果として製造が遅れ、単体テストは簡素化され、結合テストで単体レベルのバグつぶしをし、システムテストの終わりでなんとか間に合わせるということになりがちだ。しばしば、単体レベルの品質が低い、プログラマの能力がうんたらという話になりがちだが、個人的な経験から言えば、その前工程の失敗が尾を引いているだけのことが多いように思える。

 

単体テストをする時間がなくなったときに「実施したことになっているテスト」が発生する。単体テストをやったことにするのは簡単だ。単に結果報告書に○を付ければいい。JUnit が必要とされているなら、絶対に通過するテストをそれっぽく書き連ねておけばいい。実装者が追い詰められてそうすることもあれば、チームリーダーが進捗を誤魔化すためにそのように指示することもある。

 

なぜ、レビューで弾かないのか、と思われるかもしれないが、実装の完了すら危ぶまれる状況でレビューをして品質を上げることに何の意味があるというのだろうか。レビューをしている暇があるなら、まずは完成させる必要がある。「分岐網羅の組み合わせテストに基づくテストケースはすべて完成しています。いつでもテストできます。レビュー項目も完璧です。実装はできていませんが」では意味がないのだ。

 

実のところ、ここで問題としたいのは、テストが行われなかったことでも担当者を責めることでもない。スケジュールが押した以上、何かを捨てトリアージするしかない。問題は、未テストを検出して、リリース前にどうやって解消するのかということにある。予期できないトラブルすらたくさんあるのだから、予期できるトラブルは可能な限り解消しておきたい。

 

ただ、これに関しては工夫すれば解決できるのではないかと考えている。統計の検定やクロスバリデーションのように、違う観点を入れることで品質を改善できるのではないか。

 

例えば、各機能の単体テストにおいて、組み合わせパターンの偶数列、奇数列を違うチームで担当させてみてはどうだろうか。まったく単体テストが行われないというケースは減るだろうし、チームの進捗差によって発生するタスクの不均衡を平準化することもできるかもしれない。

 


 

今回、書いた内容について、アジャイルスクラムテスト駆動開発については特に触れなかった。理由としてはあまり詳しくないし実践したこともないため語る立場にないからだ。もし、それらの手法を使えば今回の問題(の一部)は解決するのであれば、その理由を公開してもらえるとありがたく思う。*2

*1:Edge をサポートしますと書いたら Android 版 Edge でアクセスしてきたり、Safari の最新2バージョンをサポートしますと書いたらすでに更新されていない WindowsSafari でアクセスしてきたりする可能性もあるので、環境の条件を考えるのもなかなかひと苦労する。

*2:私自身は、ウォーターフォールでしか開発経験はなく(ただし規模はそれなりに大きい)、少なくとも業務システム開発という領域においてそれらの手法が有効だろうと思ったことはなかったりしますが。