ビッグデータはお試し期間から成果を出すフェーズへ

今日は日本ITストラテジスト協会(JISTA)関東支部のオープンフォーラムが開催されました。テーマは「ビッグデータとITストラテジー」ということで興味を持っていたものの参加を躊躇していましたが、直接お誘いを受けたため思い切って参加することにしました。JISTAには実は2年ほど前に入会はしたものの予定が合わずにイベントには参加したことがありませんでした。

さて、テーマにもあるビッグデータですが、このブログでも2年ほど前に取り上げたことがあります。もう2年も経ったのかという感もあるのですが、2年でどのように変わったのかが気になっていました。

基調講演の1コマ目は、日本航空 Web販売部の渋谷さんによるWebログ分析の事例紹介で、私もかつてWeb分析をかじったことがあるため理解しやすかったです。基調講演の2コマ目は、トーマツの矢部さんによるこれから求められるシステム担当者像についてのお話でした。その後、パネルディスカッションへと続いたのですが、全体を通して共通していたのは試行錯誤(トライ&エラー)によって道を切り開いていくということ。企業が置かれている環境によって経営課題も違ってきますし、当然その問題に唯一の正解は無いわけです。

今回の基調講演での事例がWebログ分析であったので余計にそうなのかもしれませんが、ビッグデータ活用って結局Web分析とどこが違うのって感じる方もいるでしょう。正直なところWeb分析の経験を踏まえて言うと実はそれほど変わりません。ただ、ビッグデータとWeb分析の違いは2つあって、1つは規模が格段に大きいということ。Webサイト運営というミクロな観点から企業経営というマクロな観点にシフトしてきているように感じます。そしてもう1つは応用範囲がWebサイトだけにとどまらず、家電や医療機器などのデバイスにまで拡がってきているということです。それは必ずしも単語が指示しているものの差異というよりは、経年による変化に過ぎないのかもしれませんね。

講演の中でもありましたが、兎角分析者や技術者は分析手法やツールにこだわったり、今既に蓄積されているデータを前提に考えたりするものですが、そうではなく、やはり戦略ありきで取り組んでいかないと役立つ分析結果は得られません。ITのスキルよりもビジネスが分かる人がデータ分析を牽引した方が、結果的にうまく行くようです。また、データ分析も一つの手段に過ぎないので、あくまでも経営課題が何であって何を戦略目標にするか、KGI/KPIを何にするかを明確にするというところがまずやらなければならないところであると理解しました。


ICとして生き抜く知恵とは

昨日27日(月)はIC協会の月例セミナーがあり、参加してきました。なかなかまとまった時間が取れなかったためフル参加としては約1年ぶりでした。4年続いた理事の体制が今年の8月に新しくなってから、私自身は初参加となります。今回のテーマは「共有したいICとして生き抜く10年の知恵~守り続ける5つのルール、3年ごとの節目、オンリーワンのブランディング」というタイトル&サブタイトルで新理事長の齊藤さんのご講演がありました。これまでにも何度か齊藤さんのお話は伺っていていつも影響を受けるのですが、今回もなるほどなと思わされたことがいくつかありますので、まだあまり整理できていないですがメモしておきたいと思います。

一三の法則を知ること

組織の構成員や店舗などの数に1とか3とかが付く時がオペレーション、つまり管理方式や仕組みを切り替えるタイミングたということ。1人が3人になった時、3人が10人になった時、というようなタイミングで現状の仕組みの限界が来るため、新しいサイズに適した仕組みを導入しなければならないということ。例えば数人のチームでやっていた時の運営方法が10人を超えると通用しなくなるというのは良く聞く話です。

誰かに引き継ぐことを前提に仕事をすること

これは自戒を込めて取り組まなければ課題だと認識しました。兎角目の前の仕事に専念しがちですが、一歩引いて仕組み化することを考えることでそれが更なる価値を生むということもあります。すぐに全てに対してということは難しくても一つ一つ引継ぎ資料などを整備していきたいと思いました。

アウトプットを決めてインプットすること

もっと若いころは闇雲に情報をインプットしていた感がありますが、やはりアウトプットがないとただの情報のシャワーを浴びただけになってしまいます。アプトプットを意識することで必要な情報が明確になり、それがフィルタの役割をして膨大な量の情報から必要なものだけを抽出することを可能にするのだそうです。アンテナを張るという表現もありますね。かつて齊藤さんの真似をして取り組んでみたこともあるのですが、アウトプットの最終形態に練り上げるまでに時間がかかってしまい長続きしませんでしたが、再チャレンジしてみようと思います。

3年周期を意識すること

何事も3年周期でとらえるようにすること。例えば一つのクライアントもそうで、ずっと同じことをやっていても当初の課題をやり尽くしてしまったり、お互いが慣れてマンネリ感も出てくるため、契約にもライフサイクルがあるのだということを認識しました。特に私のように外部の立場で組織の支援をする場合、長くいれば「外部の立場で」という部分がどうしても弱くなってくるので、新たな役割を担ったり別のテーマ設定をしない限りはやむを得ない事かなと思っています。

先輩プロワーカー方のお話しは実体験に基づいているだけに重みがあり、「自分も」と思わずにはいられませんでした。引き続き邁進していきたいと思います。

拙作ソフトが雑誌で紹介されました!

以前このブログでも書いた「クロスラボラトリー」ブランドのソフトウェアですが、本日10/24発売の日経PC21・2014年12月号にて紹介されましたのでお知らせいたします。

今回掲載されたソフトは、JPEG画像のExif情報に含まれる撮影年月日を利用して日付ごとのフォルダに振り分ける「JPEG Image Filer」というソフトです。最近のデジカメだとそのように撮影日ごとにフォルダわけしてくれるユーティリティが付属していると思いますが、古いデジカメに付属していたソフトではそのようなことが出来ず、カメラからPCに取り込んだ日付でしかフォルダを作ってくれなかったため、整理するのに困って作ったものです。普通のWindowsアプリではありますが、「クラウドで写真管理」という記事で紹介されています。

ところで、このソフトは特にこれといった宣伝活動はしていないのですが、気付いてみたら知らないうちにいくつかのフリーソフトの紹介サイトで取り上げられていて、しかも弊社で提示している説明よりも詳しく、かつ分かりやすく使い方や特徴を掲載していただいており、マイナーながら少しずつ利用者が増えてきているようです。それに伴い、サポートサイトやメールにて感想や要望を頂戴することが増え、徐々にではありますがリクエストに応える形で改良を重ねてきました。

必ずしも全てのリクエストにお答えできているわけではありませんが、
今後とも一層のご愛顧を賜りますようお願い申し上げます。


情報処理技術者試験の論文対策

毎年4月と10月の2回行われる情報処理技術者試験、IT分野の国家試験ということで業界では有名ですが、秋の試験まで残り2カ月を切ってそろそろ準備を始めようかなと思っておられる方も多いのではないでしょうか。特に論文試験のある区分を受けてみたいけれどどんな準備をしたら良いか分からないという方に向けて、参考になるか分かりませんが私なりの準備方法をお伝えしたいと思います。

参考書の選び方

論文試験の為に模試や講習を受けて対策する人は一定数いるでしょうが、そんなお金も時間も無いよという場合には対策本を買うことになると思います。どの参考書を買うか決めているという場合を除いて、駅ビルや百貨店に入っているような大型の書店に出かけましょう。選択肢が多ければ自分に合った参考書を見つけやすくなるからです。

参考書にはいくつか種類がありますが、個人的な分類はこんな感じです。
過去問…直近3年くらいの問題を掲載して解説しているものです。
教科書…試験範囲をテーマごとの単元に分けて詳しく解説しています。
問題集…過去問ではなく出題傾向に沿ったオリジナルの問題を掲載しています。
対策本…教科書タイプと過去問タイプの中間です。

時間とお金がたっぷりあってじっくり取り組みたいという場合には教科書タイプと過去問タイプを揃えるのが良いと思います。そもそも情報処理技術者試験をあまり受けておらず試験慣れしていない場合にはまずは過去問タイプで学習することをお奨めします。受験する区分の知識に乏しい場合には教科書タイプを使えば基本的な用語や知識を一通り習得できるでしょう。時間もあんまり無いのでてっとり早くやりたいという時には対策本がお奨めです。

それでもどれを買って良いか迷うとは思いますが、特に論文対策ということで言えば、私は経験上、著者の人数が少ない方を選んでいます。人には考え方のパターン(つまり癖)があり、同じ人が全ての解説を執筆していれば、その著者の思考パターンを身に着けることができます。すると、水戸黄門みたいに、どんな問題が出題されてもその思考パターンで論文を展開することができ、応用が利きます。ところが著者が多いと思考パターンにばらつきがあり、ある問題はある思考パターン、また別の問題は別の思考パターンで解説されているといったことが起こりやすく、試験対策どころか迷いが生じる可能性があります。

他に選ぶ基準としては、しっかりと出題傾向を分析できているものが良いです。あと、部分的に過去問を引用している場合は、昔の問題ばかりではなく最近の問題を積極的に取り上げている方が良いですね。参考書は毎年出版されますが、ちゃんと傾向に追いついて改訂しているかどうかが試されます。

論文の準備方法

参考書の中には、準備論文を書きましょうと奨めているものが結構あるのですが、私はいわゆる本番さながらの準備論文を作りません。何故なら労力の割に実りが少ないと考えるからです。準備論文を作ったからと言ってそのテーマが出題されるとは限りませんし、かといって忙しくてまとまった時間が取れない中で準備論文をいくつも書けないですよね。それよりも論文のネタになりそうなものをきちんと整理しておく方がよっぽど効果的です。ただ、章立て(アウトライン)を作る練習くらいは過去問で一通りやっておいてもよいでしょう。

私が論文対策としてやるのは実績(経歴)の棚卸です。試験区分にはそれぞれ人材像が設定されていますので、過去に関わった案件を該当する人材像の切り口で整理していきます。また出題のテーマも複数ありますので、どんなテーマだったらどの案件が使えるかという基準が変わってきます。ピックアップした案件をさらに掘り下げて、どんな案件なのかという概要を設問の(ア)に書けるレベルで説明できるようにします。実は設問(ア)だけはテーマに左右されにくいので論文として準備しても良いと思います。

未経験の区分でも合格することはできますが、だからといって全く関わったことのない架空の案件をこしらえるのはリアリティに欠けますしお奨めしません。実際に関わった案件の中で、受験区分に該当する役割を担った人がどのような動きをしていたかを想起すれば、自分の経験ではなくてもリアリティのある論文が書けます。この棚卸がしっかり準備できているかいないかで論文がスラスラと書けるかが決まってきます。ここはどんな参考書を使ったとしても関係ない部分ですし、短時間で出来るので忙しい人にもお奨めです。


プログラミングが得意な人、そうでない人

久しぶりにプログラミングの話を書いてみようと思います。プログラミングの割と初歩的な話なのですが、プログラムを作っていく工程には「デバッグ」というものがあります。

要はプログラミング作業のミスによって生じるエラーをバグ(=虫)に見立て、プログラムを修正することによってエラーを解消することをデバッグと表現するのですが、スキルがあるレベルに達するまではこれが非常にきつい。何故かというと修正しても修正してもなかなか自分が思ったとおりに動いてくれず、時間ばかりが過ぎていくということが起こり得るからです。それに加え、プログラムをコンパイルした時や実行した時のエラー表示が、まるで自分を否定されたような気持ちにさせるという側面もあるでしょう。(こんなのは慣れればどうということはありませんが)

そのデバッグ作業なのですが、そのエラーを早く直せる人となかなか直せない人がいます。もちろんその差は知識や経験の差ではあるのですが、具体的にどういうところに現れるのでしょうか。

私がデバッグ作業の進まない人の仕事を見ていて気付いたことがあります。その中の一つが「エラーメッセージを読まない」ということです。つまりコンパイラやインタプリタやミドルウェアが出すエラーメッセージから「エラーを解消するために手掛かりに成り得る情報」を取ろうとしないということです。

その人は「実行したらエラーになった」「直して実行してもまたエラーになった」という程度の情報しか取りませんでした。でも私が見ていたところ、2回目に実行した時にはエラーメッセージが変わっていたのです。そこで「今、エラーメッセージが変わったことに気付きましたか?」と質問したところ「え、そうでした?」というような返事が返ってきました。

もちろん某ミドルウェアのように、非常にわかりにくい不親切なメッセージしか表示されないということもあるでしょう。でも、たとえ分かりにくくても「ある個所を直したらエラーメッセージが変わった」というのはエラーには違いありませんがデバッグを行う上では重要な手がかりです。その上でメッセージの内容を読めば、比較的容易にエラー解消に近づいていくでしょう。

このように、プログラミングのスキルというのは一朝一夕に向上するものではなく、こういった緻密な心配りの積み重ねで伸びていくのかなと思っています。


鵜飼船の若手船頭に学ぶ

一昨日19日にJSDGの中部研修会が開催され、参加してきました。今回は例年開催している長良川の鵜飼いとセットになっている研修会で、石金という旅館の一室を借りて行われました。(もちろんその旅館に宿泊します。)今年で5回目とのことですが、私は去年が初参加で今回は2回目の参加でした。

研修会では鵜飼船の船頭である平工顕太郎(ひらく・けんたろう)さんを招いて、インタビュー形式で鵜飼の話やこの世界に入ったいきさつなどを伺いました。船頭というのは簡単な仕事に見えて細かい気遣いを求められ、最初は厳しい指導を受けたそうですが、自分の舟を持つようになった頃からそういうのは徐々に少なくなっていったそうです。何より船頭としてのスキルは教わって覚えるものではなく、実際にやって解ることが大事なのだとか。差し詰めITの世界で言ったら自分のサーバーを持つようなイメージでしょうか。また、地元を一旦離れて外から眺めて見た方がその良さを再認識しやすく、仕事に対するモチベーションもより高まるようです。川と共に生きる覚悟を決めた男の姿をまざまざと見せつけられました。

平工さんは来月から木製の漁船に観光客を乗せて「結の舟(ゆいのふね)」という体験型ツアーを始めるのですが、私も企画に携わっていて、翌日、他のスタッフと共に体験乗船してきました。最終チェックを行いたいとのことで駆り出されたのですが、情報システムで言うところのユーザーレビューあるいは受入テストに当たるでしょうか。例えば、流れの静かなところで手ほどきを受けながら操船の体験をしたり、平工さんが日頃から漁で使っている網を投げる体験をしたりといった内容です。操船も竿がなかなか川底に刺さらず(川底の石の表面を滑ってしまう)、投網もうまく網が広がらずに束のまま放り投げてしまったり、「なるほど覚えると分かるは違うんだな」ということを改めて学びました。

川には危険がいっぱいあり、先日も小学生が事故に遭ったりして怖いと思う方も多いと思いますが、危険だから近づかないという対処は却って対象をブラックボックス化してしまいます。それよりは具体的にどのような危険があり、どのように対処すればよいかということを学んだ上で遊ぶことが大切かなと思います。河原を歩く時に転倒事故が多いそうなのですが、転倒しないためには浮石を踏まないようにするとか、今回ライフジャケットを着用したのですが、流された時には立ち泳ぎしないでラッコのように浮いて頭を川上に向けて流れに任せるなど、話で聴いただけでは分かりづらいことを体験を通して学ぶことができます。

尚、この体験ツアーは対象を小学1年生以上をとしたいとおっしゃっており、この夏休みに岐阜方面に行かれる方はぜひ検討してみてはいかがでしょうか。この事業を通してより多くの人に川に親しんでもらいたいと思うのと同時に、平工さんの今後のご発展とご活躍を願って止みません。

石金
http://www.ishikin.co.jp/

結の舟
http://yuifune.wix.com/yuino-fune

 

フラットデザインには慣れなければならないのか

アップル社のiOS 7、そしてマイクロソフト社のWindows 8がリリースされてからというもの、あののっぺりとした味気ない画面(UI)に抵抗を感じています。おそらく私はコンピュータの画面が文字ベースからグラフィカルになった頃から今日に至るまでコンピュータに慣れ親しんできて、UIの変遷を見て来ていますので、そもそもUIはリアルでリッチな表現を目指して進化してきたんじゃなかったっけ?というのが素朴な疑問です。

なんていうんでしょう。iPhoneが登場したころ、様々なアナログ・オブジェクトがモデリングされてアプリにされました。そこではピンチやスワイプといった、タッチパネルならではの操作方法と共にそのデバイスの特徴が示されていたと思います。スマートフォンに限らずパソコンのOSでも、例えばボタンはあの立体的な描写だから指で押したくなるわけで(といっても従来のパソコンではマウスポインタを当ててクリックするだけなんですが)、それが急に平坦になるとどうして良いか分からなくなってしまうのです。

とはいえ、iPhone登場前後に、ある種のサイトがこぞってボタンの表現を立体的でガラス光沢のある描写に変えた時、それにも抵抗感を覚えたことも事実です。従前の描写ではなぜいけないのか、その理由が全く見えなかったからです。どうも最近のこの平坦な描写への方向転換は、UIにおける描写のリアルさ、リッチさが本来意図していなかった方向に加熱してしまったことに対する反省に基づいているということのようです。

例えば、本がめくれるような描写は、紙の本を読んできた人でないとピンと来ません。リアルなマイクの図柄も、あのようなマイクを見たことが無いとこれがマイクだと理解できないかもしれません。そうなると、知っている人にとっては「説明しなくても扱い方が理解できる」というメリットがあっても、知らない人にとってはそういうメリットは享受できないことになります。芸人のモノマネが真似ている対象を知らないと面白くないように、パロディが元ネタを知らないと面白くないように、模倣というのは原典(オリジナル)を知らない人にとっては模倣の意味が無いものです。

リアルさ、リッチさとは少し異なりますが、パソコン向けの多くのアプリケーションが「保存」という操作をさせるためのアイコンの図柄にフロッピーディスクを採用しています。しかし、そもそも最近のパソコンにはフロッピーディスク装置が付いていることがほとんど無く、フロッピーなんて知らない人たちがいてもおかしくありません。そうなると、フロッピーディスクのアイコンが何をするものか想像できない人も出てくる可能性があります。

現在進行している方向性は、よく標識に喩えられています。標識は道路に限りませんが、日本の道路標識は非常にシンプルで分かりやすく、良く考えてデザインされていると思います。もし道路標識がリアルでリッチな描写を採用していたら、立ち止まって眺めるにはいいかもしれませんが、車を運転しているときに一瞬で判断しづらい(つまり目的を達成しにくい)のではないかと想像できます。

実は、iOS 7からiPhoneを使い始めたという人からは、このデザインに対して別に違和感はないという意見を伺っているので、そういうものだと思えば済む問題なのかもしれません。となると、今は過渡期なので全てのフラットデザインが使い易いわけではないとしても、流れとしてはシンプルな方向に向かっていくと思うので、やはり慣れていくしかないのではないか、と私の中では結論付けております。


10年後のワークスタイルを考える

昨日JSDGの東京ミニ研修会が開催され、参加してきました。今回は久しぶりに私が企画を担当させていただきまして、「これからの働き方を考える」というタイトルでグループディスカッションを行いました。

研修会の数日前に申込者のリストを見て、私は最年少は免れたもののほぼ最年少に近く、果たして目上の方ばかりを相手にこんな話をしていいのかと正直思いました。グループ分けも最初は単純に分ければ良いかなと思っていましたが、他の幹事の方からどういうグループ分けにしますかと問われて、せっかくだから世代別にしましょうということになり、事前にザックリとグループ分けしてもらいました。(グループ番号が記載された名札を用意してくださったので助かりました。その段取りに感謝。)

本編の構成は私がテーマについて話をして続いてそのテーマでディスカッションするという形で、それを2つのテーマで行いました。前半のテーマは過去から現在のワークスタイルを棚卸する狙いで、私自身のワークスタイルの話と職務特性モデルの話をしました。これは一昨年金沢で「雇われないシスアド」というタイトルでICの事をプレゼンした時の題材を借りてきて、職務特性モデルに照らして今の自分の仕事はどんな点で満足しているかあるいは不満かということをシェアしました。この日参加された方々は全体的に満足度が高かったのが印象的でしたが、グループによって(つまり世代によって)指標の捉え方が異なっていて興味深かったです。

後半のテーマは「ワークシフト」という書籍(丁度著者の方が来日しているそうです!)を紹介し、10年後の未来のワークスタイルについて議論していただきました。

10年後ってなかなか想像しにくいですが、それほど遠くない未来だと思いませんか。ただ、この話題は正解も無ければ結論を出さなければいけないようなものでなく、著者もあとがきで書いているように、みんなでこういったことを議論することが大事なんだと思います。

限られたリソースで最大の効果をもたらすトリアージ

もう随分前になりますが、このブログの中で「デスマーチ」そして「パーフェクトソフトウェア」という2つの著作をご紹介したことがあります。両者に共通するポイントはリソースは有限であるため全てのバグを取り除くことができないという点と、その有限のリソースの中でバグをどのように分類し優先順位を付けて対応するかという点であろうと思います。いずれもソフトウェア開発に関する著作ですので「バグ」が対象にはなっているのですが、もっと広くプロジェクトマネジメントという観点に引き上げてみると、バグだけではなくバグ対応を含めたToDoの捌き方のアドバイスということになります。

前者の「デスマーチ」ではトリアージという戦争時における負傷者救護の優先順位づけのアイデア(これは今の災害時の救急医療現場でも活用されているようです!)を紹介していますが、後者の「パーフェクトソフトウェア」ではトリアージを実践するための具体的なバグの分類方法を提案しています。当時のブログ記事の中でも私なりにアレンジした分類方法をご紹介しましたが、今回はより進んだ分類方法をご紹介します。

システム開発では、開発中のシステムに対する仕様の変更や追加の要求が出されることが良くあります。要求を出す方としては当然のことながらすべてに対応してもらいたいと思うものですが、要求を受ける方としても当然のことながらプロジェクトとして実施している場合は納期も予算もありますので(これがリソースが有限であるということの意味ですが)出された要求の全てに応えることができないという状況に陥ることがあります。

そんな時、要求を一覧化して対応するかしないかを選別しても良いのですが、もっと明確な基準があると判断にも迷わないですし、なされた判断も客観的で納得感が出てくると思いませんか。例えば、次のような分類を考えてみましょう。

レベル0:そもそも技術的に不可能であり、対応できない要求
レベル1:対応できなければリリース延期またはプロジェクトを中止する要求
レベル2:リリース時に無くても良いが、対応しないと業務に支障のある要求
レベル3:可能なら対応したいが、対応しなくても止むを得ない要求

これらの分類をするだけでも客観的な評価となり得ますが、次のような設問フローを作るとより客観的で論理的な判断を下すことが可能になり説得力が増します。

トリアージの判定フロー

(1) 要求が技術的に不可能であるか。
[Yes⇒レベル0/No⇒(2)へ]
(2) 対応されなければリリース延期するか。
[Yes⇒レベル1/No⇒(3)へ]
(3) 対応されなければ業務に支障があるか。
[Yes⇒レベル2/No⇒レベル3]

判断をするときには設問に答えていくだけで客観的な優先付けを行うことができ、レベル0は除外して優先度の高いものから残されたリソースの範囲で対応できるものを決定していくことになります。これも救急医療現場で使われるABCDEアプローチのようなもので、判断を急ぐときにはシンプルで強力なツールとなります。分類の数が多くなっても設問を増やすだけで良く、状況に応じてアレンジもしやすいです。


東京都福祉保健局によるトリアージの説明

データベースの索引がイケてない話

以前、とある業務システムで検索スピードが要件を満たさずにリリースが延期されたという話を耳にしたことがあります。それを聞いた時、かつて少し関わっていた現場で、検索するとCPU負荷が100%に張り付くシステムや、ちゃんと動いていたのにある日を境に検索がタイムアウトするようになったシステムの存在を思い出しました。

この手の話はデータベースの索引が適切でないことに原因があることが多いのですが、データベース設計の教科書でも索引は基本的な単元であるにもかかわらずわりと良く聞く話でもあったりします。プログラムはゴリゴリ書けるけど、DB設計をきちんと学んだことが無い人が作っているという可能性もあるのですが、もしかしたらある程度きちんと機能する索引を付けるにはそれなりに経験を積んでセンスを磨く必要があるということなのかもしれません。

索引は検索キーやソートキーに付与するというのが基本ですが、複数カラムを指定して検索する場合にその索引が使われなければ、別途使われるような索引を付与するといったことをします。ただ、あまり索引を付け過ぎると更新処理のパフォーマンスが落ちるので、検索スピードが欲しい場合はマスタとは別に検索用のテーブルを用意することもよくあります。最初は普通に結合して選択していたものが、段々パフォーマンスが落ちてきたために途中で検索用テーブルを追加するといったことは別におかしいことではありません。

適切な索引が無ければどんなにSQLを効率的に記述してもパフォーマンスは出ませんし、また、基本的な索引は理論だけで行けるとしても、RDBMSの実行計画は実際にテーブルに格納されているデータの件数だけでなく内容によっても変わってきます。なので、もし絶対に止めてはいけないようなシステムの場合は、テストの段階で本番さながらのテストデータを使って本番さながらの件数を格納した上で動作を確認しチューニングする必要があります。

チューニングの作業は私は結構楽しいと思っていますけれど(例えばチューニングして検索スピードが10分の1になったら楽しくないですか?)、面倒くさいと感じる人はなるべくやらずに済ませたいと思ってしまうのでしょうか。