つまり前回は0.0.1だったんだｗ
http://d.hatena.ne.jp/gallu/20090326/p2
http://d.hatena.ne.jp/gallu/20081022/p1
http://d.hatena.ne.jp/gallu/20081201/p2
軽く追記などしつつ。
前提確認の１
問：
ドキュメントは何をどの程度頂戴できますか？
回答：
もちろん「ドキュメントもちゃんと見越したお支払い」が前提ではありますが。
どんなドキュメントかはともかくとして、なにがしか資料を貰えるか貰えないか、では色々と雲泥の差が出てきます。
ちなみに尤もよいのは「ドキュメントはプログラムソースからの自動生成がメインになりますがよろしいですか？」という発言。
ドキュメントが常に生き生きしている(可能性がある)ので、もっともよい回答であると言えます。
基本機能確認の１
問：
「性能」「使いやすさ」「セキュリティ」についてどの程度考慮されてますか？
回答：
規模拡張性確認の０に微妙にかぶるのですが。そも「拡張する前から性能値に問題がある」と色々論外なので。
まず初手でちゃんと確認をしておきましょう。
どんな内容であれ、とりあえずそれなりに答えが返ってくればよし。
「具体例を出せ」に対していきなり口調が濁ったらアウト。
万が一「まってました」とばかりに立て板に水で語られ始めたら…あきらめて、満足いくまで騙り終わるまで聞いてあげてください(苦笑
基本機能確認の２
問：
ソースコード内にどれくらいのコメントが書いてありますか？
回答：
厳密には「コメントの質」をチェックすべきですが。とりあえず「ある程度の量」はそうは言っても不可欠なので。
えと…行数基準で、全体の1/5よりもコメントが少なかったら。とりあえず警戒したほうがいいです。
行数基準で全体の1/10を下回ると非常に危険。無量大数*1に一つ「コメントなんて不要です」的発言があった場合。「コメントよりもあなたが不要です」とはっきり言ってさしげてください。
＜修正＞
「有益なコメントというものをその目に見せてあげます」にしたほうがよりよいですね。
＜/修正＞
機能拡張性確認の１
問：
(適当に１つチョイスして)この入力画面に１つ項目を追加するとどれくらいの時間と費用がかかりますか？ またプログラムは何カ所ほど修正をされますか？
回答：
一番いいのは、ユーザさんの情報を一つ増やすような項目ですね。今まで取得していなかった、例えば「一言」とか「あだ名」とかなんとか。
美しく組まれたプログラムの場合、DBテーブルのレイアウト変更でちょろり、プログラム修正を一箇所、程度で片付きます。
これが美しくないプログラムの場合、DBテーブルでなぜか複数箇所のレイアウト変更が伴い、プログラムの修正に至っては十数カ所とか二十数カ所とか。
後者の場合、得てして「ちょっとしたケアレスミス」が高確率で発生し、故に良い感じにトラブルが減りません。
機能拡張性確認の２
問：
新しい機能を付け足すのに、新しい機能「以外」の既存部分にはどこまでの修正が入りますか？
回答：
プログラムの基本はレゴブロックがごとき「ほかとの非依存性」にあります。
美しいプログラムの場合、大抵「設定ファイルをちょろりんと付け足して以上」程度。
美しくないと、既存プログラムに妙な修正が入り込みます。
で。これはバグの有無から費用の増減まであちこち関連したりします。
横断的関心事項への確認の１
問：
例えば、急遽「このサイトのアクセス全体に対して」「この機能全体に対して」「発行しているSQLを、Webサーバ側で一式」ログを取りたい、などの時に、どれくらいの工数、費用で対応ができますか？
回答：
正しく機能分割された、且つ、いわゆるMVCな作りの場合(つまり美しい設計の場合)。必要な「一箇所」が大抵あるので(或いは作るのが比較的容易なので)。ログの場合(ログの量とHDD容量との関係に考察は必要ですが)、比較的容易に仕込む事が出来ます。
美しくない設計の場合、この手の要素は「散らかるだけ散らかり倒す」ために、当然ながら網羅する事は容易な事ではなく、っつかぶっちゃけ作業漏れが、かなりの高確率で発生します。
うちではこれを「随所に関所」と呼称しますが。
これが完全に出来ている場合、例えば一般的なSQL-Injection脆弱性、XSS脆弱性などが「万が一」あったとしても、簡単に潰す事ができます(潰すべきロジックが一箇所にまとまってるわけですから)。
規模拡張性確認の０
問：
規模が拡張した時などにそなえて。システムリソース、プログラムの最適化などに対してきちんと意識を払っていますか？
また、それはどのあたりにどんな風に意識を払われてますか？
回答：
とりあえず、軽くジャブを(笑
どんな内容であれ、とりあえずそれなりに答えが返ってくればよし。
「具体例を出せ」に対していきなり口調が濁ったらアウト。
万が一「まってました」とばかりに立て板に水で語られ始めたら…あきらめて、満足いくまで騙り終わるまで聞いてあげてください(苦笑
規模拡張性確認の１
問：
Webサーバを横に広げたい時に、レイヤー７スイッチではなくてレイヤー４スイッチでロードバランシングが可能ですか？
回答：
これはMustではないのですが。とはいえ、レイヤ７スイッチとレイヤ４スイッチでは色々と、お値段から性能まで、楽しいくらいに開くのはまた当然のことでございます。っつかSSLを組み合わせた時点でもう一つ面倒なハードルが出ますしね。
ちゃんと「レイヤ４スイッチ」でも問題ない作りだと、ある程度までは「iptables」でお手軽なロードバランシングが可能なので、ぶっちゃけ「もの凄く廉価」にいけます。
人数が「ある程度」増える事が予想される状況であれば、重要な一考かと。
規模拡張性確認の２
問：
DBサーバが厳しくなった時に、クラスタリングなどをせずに負荷分散が可能ですか？
回答：
これもMustではないのですが。どうしても、クラスタリングの場合「ストレージを共有する」ために、わりと簡単に上限が見えてしまいます。
そうではなくて何らか別の方法で、もっとコストパフォーマンスのよい負荷分散ができるか否か、は、ある程度以上大規模なサイトを想定する場合、考慮してまったく損のないものになります。
規模拡張性確認の３
問：
人数が増えると何が増加して、それはO記法でどんな感じのオーダーで増えて、上限がどのあたりで、その上限に対してどんな対策が出来て、その上で「本当の上限」はどこまでですか？
回答：
少々突っ込んだ質問ではあるのですが。ここちゃんとしておかないと、時々とんでもなく手前でえらいこっちゃになります orz
O記法は、少々専門用語(数学用語？)ではあるのですが。簡単だしでも重要なので御理解下さいませ。
http://ja.wikipedia.org/wiki/%E3%83%A9%E3%83%B3%E3%83%80%E3%82%A6%E3%81%AE%E8%A8%98%E5%8F%B7
の
一般的なオーダー
をご覧あれ。
酷いとねぇ…会員数が４桁になった初手(つまり千と数百人)くらいで平気でシステムがパンクしたりするので orz
ついでに、この辺を聞いておくと色々と面倒が少なかったりします。
具体的には「お役所のごときたらい回し」がある程度避けられます。
運用メンテ確認の１
問：
基本的なdaemon、ソフトウェアなどのバージョンが上がった際、必要に応じてinstall作業やその後の確認作業はしていただけますか？
回答：
まぁ…出来ないとか言われると色々と困りますよねぇ(苦笑
運用メンテ確認の２
問：
サーバが「落ちた」というタイミングではなくて、もう少し手前の状態で「そろそろ危なそうだ」みたいなサーバの状態を監視していただく事はできますか？
回答：
落ちてから「じゃぁ」とかされても困りますし。
とりあえず、uptimeとかロードアベレージとかnetstatとかvmstatとかその他の見方くらいは知ってる事が望ましいっていうか知らんでどうするよ？ って気がします。
…そのうちここに読み方とか書こうかなぁ？
あと。
監視の基本は「落ちたら知らせる」じゃなくて「生きている事を知らせる」ほうが確実です。
運用メンテ確認の３
問：
サーバの追加が必要になる場合の作業手順や必要なものなどは概ね把握されていますか？
回答：
とりあえず「用意しといてね(にっこり)」くらいのジャブを打っておくと、後々幸せになれますっていうか不幸にならずにすみます(笑
運用メンテ確認の４
問：
使っている全てのものは、ある程度認知されているものか、或いは「平均的な技術者で理解可能」な運用手順書を付けていただけますか？
回答：
そも「平均的な技術者」という存在が怪しいのですが(苦笑
得てして「特殊な手法」は、他業者に乗り換える時にものごっつ苦労させられます。
なので。乗り換えを想定して「比較的資料が豊富」であるか、でなければ「特殊かもしれないけど難度は低い」ものをある程度前提にするとよいです。
或いは「逃げるなよ」と釘を刺しておきましょ。もちろん言葉だけじゃなく、態度で示す事を忘れちゃいけません。
さて…徐々に増えていくｗ
*1:10の68乗、または10の88乗という素敵な桁
