業務で『パッケージやライブラリそのもののバグ』に直面してしまった場合の対処法

Question

システム開発では様々なパッケージ品やライブラリを組み合わせて開発することが多いと思うのですが、
パッケージやライブラリそのものにバグがあり、本来実現できるはずのことが実現できない、
またはバグを解消できない、みたいな場面に直面した場合ってどうするべきなのでしょうか？
『これはパッケージ品のバグなんで直すのムリですねー』とはやっぱりエンジニアとしてはできるだけ言いたくない……

例えばOSSの場合はソースレベルで不具合の原因特定してGithubにIssueやらプルリクやら投げる、っていうのが理想ですかね？
難しければ、公式サポートに問い合わせて修正版を貰うか、ライブラリを使わない代替案を考えるという感じでしょうか？

• OSSでも商用でもあまり活発に保守/サポートされてないような変なパッケージは選定の時点で利用しない
• 基本はOSSでも商用でも公式にて対応してもらう
• ライブラリ部分のソースは公式を通さずいじるのは原則やらない

って感じで考えているのですが、どうでしょうか？

Comments

[m.ts10806]

つけられているタグの意図が分かりかねます。適切なタグが見つからないのであればとりあえず思いついたものを付けるのではなくタグの追加依頼を出されてはどうでしょうか

[退会済みユーザー]

そもそも「業務」でってことは「OSSの修正」待ちは許されませんが

Answer 1

質問がふわっとしているのでふわっとした回答ですが「業務で」ある以上はまず「なんらかの対処を試みる」（じゃないとおカネ貰えない）のが大前提で

『これはパッケージ品のバグなんで直すのムリですねー』とはやっぱりエンジニアとしてはできるだけ言いたくない……

心配されなくても、これを言う状況があんまり想像つきません。
お客さんはできた製品に対しておカネを払う契約をしているわけですから、こんなこと言われても知ったことではないでしょう。

なので、そういう状況に至らないために最善を尽くすのが先です。
商用の製品なら保守やサポートの契約を結んでおくとか。
OSSであれば「最悪でも」自分たちでメンテする覚悟でパッチを作るとか。
（開発元がプルリクをマージしてくれるのが理想ですが）

あと「使えないと判断できた段階で使わない（別のライブラリ等を探す・該当の機能を内製する）」のも当然選択肢に入ることもあるでしょう。
スケジュールへの影響や後々までのコストを考え、最善手を選ぶだけです。
逆に言えば、「常に正解」といえる選択肢なんてたぶん無いです。

そもそも、一度きりの使い捨てプログラムを作っているのか、長期に渡ってメンテナンスする契約で作っているのかで全然話は変わってくるとは思いますが。

Comments

[pepperleaf]

> 心配されなくても、これを言う状況があんまり想像つきません。
お客さん指定のライブラリ + 指定の機能で、見事、バグってのありですね。
ちょっと前に、数日悩んで、メーカー問合せでバグ判明。 どうしたか覚えてないけど、最初はまさかと思った。

[gentaro]

ライブラリが指定される状況でバグがある場合、オープンソースじゃなかったり権利関係の問題でなおせない、という場合はあると思いますが、それはエンジニアとして当然言うべき事（言いたくないと悩む方がダメ）なので、話の趣旨から外れますね。

[pepperleaf]

話の趣旨からは外れるかも知れませんが、最初から、バグって明確に分かるのは少ないですね。その場合の対応は結構、面倒。 (まず、こちらのミスを疑われる)

[gentaro]

海外の（Linuxをカスタマイズした）独自OSの載ったストレージ製品のバグに当たったことがあって、まぁ調べてみたら単純に２バイト文字の扱いの問題で、別のファイルシステム上で作成された特定の文字が含まれるディレクトリをまるごとコピーしたらエラーになる、というのを踏んだ事がありますが、確かに困りますね。修正依頼かけてもアメリカの開発部隊が直すまで数ヶ月かかりましたし。
さすがにどうしようもないので、一時的に名前変えてもらうように依頼しましたが、原因が判明するまではそりゃ慌てますし、めちゃくちゃ面倒です。でもそれで金貰ってるん以上、「できません。仕方ないです。」じゃなく「なんとかする方向で調査しますから、とりあえずしばらくの間こうして下さい」としか言えませんよね。それでも最終的にどうしようもなければ謝るしかありませんが、やっぱりお客さんにとっては知ったことじゃないので、最後まで誠意を持って対処するのがプロだと思います。

Answer 2

OSSでも商用でもあまり活発に保守/サポートされてないような変なパッケージは選定の時点で利用しない

安全と言えば、安全ですが、なぜか、落とし穴が待っている事があります。

基本はOSSでも商用でも公式にて対応してもらう

どちらにしても今、使いたいときには間に合わない。それも大半が完成した頃に発覚。
まずは、オフィシャルに投げる、あるいは公式掲示板などに質問を投げる。
大半は、自分のミスだったりします。
なお、商用でもOSSでも対応には、保守契約が必要でしょう。

ライブラリ部分のソースは公式を通さずいじるのは原則やらない

公開されているならば、ソースを修正するのは良いですが、開発元に戻さないと、次のバージョンアップに反映しません。要注意です。

肝心なことを忘れてました。
自分の場合、依頼元に報告と共に、回避策を考えるです。
バグだからと言って、すぐに直してもらえる訳でもないし、修正版に入れ替えると、他の箇所にバグが無いかの確認が必要となります。

Comments

[退会済みユーザー]

そういえばいつまでたっても治らない Struts2 のリモートでコードを実行可能な不具合

Answer 3

個人的な意見ですので参考にならないかもわかりませんが
工数的に問題無ければ私ならバグは直します。そして報告します。

Answer 4

小規模なパッケージの場合。

一時的ならフォークして使う。
公式が対応したら戻す。

対応しないまま長く使ってきたら自分の管理下に置く。ライセンス的に問題ない場合のみ。