経験も資料もマニュアルに記載もないことを決めないといけない場合は？

質問

経験も資料もマニュアルに記載もないことを決めないといけない場合は？

例えば高速ソート機能のアプリケーションがあったとして、オプションにいろいろ設定できます。ここではその内のひとつであるバッファサイズを決める必要があるとします。デフォルト値は4MBになっています。この高速ソート機能は初めて使う製品であり、ビジネス向けでごく限られた市場なのでネットに共有されている情報はありません。またマニュアルには小さいファイルのソートの場合はファイルサイズぐらいあるとパフォーマンスが上がるとしか書いてなく、数十MBを対象としたい場合の目安が記載されていません。

デフォルト値があるのであれば理由がなければその値を利用すればいい。パフォーマンスに問題があるならその時に調整すればいいじゃないか。こういった場合にお客様によっては理由なくデフォルトはいかん、といわれることもあります（正論とは思いますが・・・）。

ただ正直な話をいえば件名のような状態なので、仮に調査しようとしても（した上で分からないのですが）時間ばかりが過ぎてしまいます。その結果は数日調べたけど無駄に終わった。どうしよう？　となってしまうことが多いのです。

また設計やコーディングの時点ではあくまで仮の値で、具体的な設定値はテストしながら調整していこうと思っています。という形で持っていこうとしたこともあります。これも設計時に決めておくものだ！　と一蹴されました。

似たようなものでDBのプール数やタイムアウト値、APサーバのキュー数やログのサイズなどがあります（自分にとっては現時点では手に負えないという意味で）。

このようなとき皆さんはどのように対応しているのでしょうか。ケースバイケースではあるでしょうがアドバイス頂けると嬉しいです。できることを増やそうと勉強してはいるのですが、振られる仕事の幅が広くておっつかない現状です。

回答No.2

BellBell · ベストアンサー

状況がよく判らないので、はずした結果を書くかも知れませんが。

＞高速ソート機能のアプリケーション
んなものをわざわざ導入しようというクライアントであれば、クライアントの要求はとにかく高速なソートをして欲しいのでしょう。
せっかく高いお金出して買ったものを、デフォルトでお茶を濁すような設定で『ちょっと早くなった』というよりも、『目いっぱいの高速化を目指して数十MBのファイルサイズと同じにしました、今後もっとファイルサイズが増加する場合その時点で増やしましょう!!』とする方が気分がいいかも知れません。
(※本当に高いのかどうかは知りませんが、情報がごろごろ転がっているわけでは無いようなソフトは概ね高価です)
あるいは、そのバッファサイズがメモリ上に常駐するような形であれば、『常にソートが必要なわけではないので、ファイルと同サイズではメモリに無駄が多いです。他のアプリのパフォーマンスに影響が出ます。ソートのパフォーマンスも考慮して、ひとまずファイルサイズの半分のバッファサイズで様子を見ましょう!!』とするのもありか？

元々一般的なものではないものに、『一般的にはどうか？』なんて情報を探しても時間の無駄です。
結局は適当に決めなきゃならないのですが、その適当の根拠を説明できるかどうかではないでしょうか。
テキトーに決めました、設計時の値は仮なのでテキトーです。
ではクライアントとしては、気分が良いものではないのでしょう。

適当の元々の意味は、適切と同義です。
※前記カタカナでのテキトーは、いい加減に決めたという意味の悪い意味で適当を表すためにカタカナで表記しました。
テキトーではなく、適切な値をその根拠と共に示されれば、クライアントの納得の度合いも違うのではないでしょうか。

端末数が現在100台の為、最大同時接続数は100台を想定してます、これは今後端末が少々増加したとしても本当に同時に接続するかという意味では充分すぎる数だと思います。
その為、この100台からの接続が・・・、DB設定をこのようにしておけば・・・
と、ユーザ環境を考慮した説明ができるかどうかかも知れません。

ま、私が関わったプロジェクトはそのような説明をしようとしても、「それで君がいいと思うのならそれでやって」と、良く言えば信頼され任されている、悪く言えば丸投げ状態でそのような説明を『しなければならない』状況は経験していませんが。
※運用環境、運用上の想定を細かく聞くうるさい開発者だと思われているぐらいですね、たぶん。

もし、テキトーにデフォルトでイイジャンで進めようとしていた際に、「デフォルトでいく理由を説明せよ」と言われた場合は、「発売元が少なくとも万人向けの設定として、最適設定をデフォルトとして指定していると考えます。一旦運用環境でデフォルト設定でのパフォーマンスをテストしたいと思います。そのうえでパフォーマンスが不足している場合にはメモリ使用量を増加する対処をしたいと思います」とでもいうかも知れません。
※ま、最初からツッコミを入れると判っている相手なら、テキトーでイイジャンはやりませんが。

お礼

お返事が遅れてごめんなさい。
とてもためになります。有難うございます。

「結局は適当に決めなきゃならないのですが、その適当の根拠を説明できるかどうかではないでしょうか。」

上記、その通りだと思います。合っているか（適切か）どうかはともかく、選考基準を提示しなければいけないと思うのですが、経験が浅くなかなかもっともらしい基準を見出せずに困ることが多いです。
初手を失敗すると、揉めるというか更に選考基準を説明するのが困難になることもあり頭を抱えています。

回答No.3

ToOrisugaru

はじめまして、通るすがるともうします。
マニュアルに書いてないのなら、問い合わせてみては如何でしょうか？
メモリ量の計算の仕方があるかと思います。
高いアプリケーション料を払っているのですから、そういったサポートがあっても
当たりまえと思います。
あと、後半の例にもありますが、「似たようなものでDBのプール数やタイムアウト
値、APサーバのキュー数やログのサイズなどがあります」この辺も計算式があるか
と思います。マニュアルに書いてないのであればそれは、開発者の記述ミスです。
とことん納得がいくまで、問い合わせるべきと思います。

お礼

お返事有難うございます。
問い合わせをお願いするというのもアリなのかもしれませんね。保守契約（でいいのでしょうか）がどのようになっているのか不明なのですが、今までの経験ですとどうもメーカに問い合わせをお客様に依頼しても渋られることが多かったのです。

別途お金が掛かってしまうのが、手続きが面倒なのかは不明なのですが・・・。またメーカ問い合わせというと、回答に2週間ぐらい掛かることもあって敬遠していました。ですがこういった情報はやはりメーカが一番知っているはずですので、お客様ともその辺りを交渉してみようかと思います。

メーカに問い合わせつつ、別途調べていくというのがよいのかもしれませんね。

回答No.1

junkUser

「マニュアルには小さいファイルのソートの場合はファイルサイズぐらいあるとパフォーマンスが上がるとしか書いてな」いそうなので。

数十MBは十分小さいと考えて、数十MBバッファをとったらいかがでしょうか。
仮にサーバーで運用するとして、いまどき数GBのメモリを積んでいるのが普通なので、数十MBは誤差の範囲です。
これ以上の情報は出てこないのでこれで決めてしまえば良いと思います。

こういうお客さんの場合は問題が出ようが出なかろうが関係ありません。
重要なのは問題が起こったあと、以下に素早く解決するかにかかっています。

お礼

お返事遅れてしまいごめんなさい。
ありがとうございます。アドバイス参考になります。