騙されないようにする為に（適切な議論の方法）

素直さは如何に大切かという記事を書いたのですが、考えてみれば『それは私自身にも当てはまるのでは？』というツッコミがきそうですし、何よりこれはエンジニア向けに書いているので『判別つかない議論をどうすれば見極めれるのか？』とか『自身がどういう姿勢で臨めばよいのか？』という全うな質問もあるかと思います。
そこで、ITエンジニアが適切に議論（主張）を行う方法をメモしてみます。

１．自分の主張が正しことの裏を取る
もっとも大事なことは自分できちんと根拠を示すことです。では根拠となるのはどういったものでしょうか？
　(1) 実験する
　　例えば、『○○の方が速い』ということでしたら実際に実験してみればよいのです。実験というのは何より客観的ですのでその結果は事実として受け止める必要があるでしょう。ただ、実験では『たまたま自分のマシンでは速かった』ということもあるでしょう。したがってその実験が再現できるよう環境もあわせて提示しましょう。
SQLの実行パフォーマンスについて 2010ではこの方針にのっとって主張を行っています。

　(2) 論理的な考察
　　実験にプラスしてそれを補う理論的な考察も必要でしょう。ここで重要なことは、IT周りの議論が起こったとき理論的な考察というのに無理がある場合があることです。つまりITの世界は数学のように割り切れない面もあります。パフォーマンスという一見簡単な問題にしても純粋な数学からすれば充分に複雑です。いわゆる複雑系というやつです。それ以外でも例えば、工数が少なくなるというのはそもそも主観が入るでしょう。そのような場合は出来るだけ問題を簡単にして説明可能な実験に分割してそれぞれ実験を行えばよいでしょう。
[ADP開発日誌]SQL（JOIN）の実行パフォーマンスについて２０１１ではこの方針にのっとって主張を行っています。

　(3) 他のソースの引用
　　確からしい他のソースから引用するのももちろん良いでしょう。その場合引用元を開示すれば他の人が検証可能となります。この場合注意したいのはインターネットの情報はウソもあるということです。騙されないようにする必要があるでしょう。

２．騙されない為のテクニック
ITエンジニアたるもの技術的な論争についてはきちんと処理をしたいところです。口頭での議論だとついつい煙に巻かれることもありますが、ネット上ですと文章として残っていますので冷静に対応すればよろしいかと思います。
　(1) 発言者の過去の発言を検索し矛盾がないか検証する
　　残念ながら論理的に筋道が通った話ができない人がいます。また人というのは時間と共に考え方が変わります。相手の発言はそのようなことを考慮しているかどうかを検証する必要があります。その際にあらかじめ公開の場で質問をしておくと後々それが助けになります。

件の社長は、炎上したのでまとめ で、
　『SQLはオブジェクト指向言語の数十倍の効率』
という発言し、その根拠にコメント欄で、JOINの例を挙げたが、その一年後にツイッターで、
『JOINをなくすならAPサーバでキャッシュする。 集計関数をなくすなら、ORDER BYを禁止する。 SQLがイヤならRDBMSは使わないこと。 何度も書いているけれど、SQLで出来ることをAPサーバでやっても、【絶対に】DBサーバの負荷は減らない。 ただし、下手糞を除く。』
と発言しています。そしてそれを指摘すると今度は、シビアな設計で、
『JOINするしないでは、トレードオフの関係は、すべてのリソースに対して技術者の技量しかありません。』
といっています。発言に矛盾があることはもうお分かりでしょう。

　(2) 質問に答えない
　　少なくとも明らかな素人を除いて、質問に答えない（そして中傷してくる）相手はその質問自体に答えたくないのでしょう。
SQLの実行パフォーマンスについて 2010で私は件の社長本人に『SQLはオブジェクト指向言語の数十倍の効率』の考えは変わったのか質問しましたが、件の社長はそれには直接答えていません。逆に質問してきたり、独自の認定を行い、議論を終わらせたりします。少なくとも自己の主張が正しいとするならば質問には答えられるはずです。

　(3) 綺麗な図に惑わされない
　　これは一部の方に行われているが綺麗な図や表を用いてさも正しいという風に見せ付けることがあります。いくら綺麗にまとまっていても真のＩＴエンジニアたる者だまされてはいけません。よーく検証しましょう。

例えば、以下の図ですが、

一見綺麗にまとまっているでしょう。しかし、データ転送量の欄を見てみましょう。
『データ転送量　 トラフィックに影響 　JOINした方が少ない 』
とあります。これが成立しないことは、[ADP開発日誌]SQL（JOIN）の実行パフォーマンスについて２０１１で指摘しています。一見すると綺麗な表でまとめられているので気がつかないかもしれませんが、きちんとみれば分かります。また他の項目についてもきちんと説明せずに結果だけが表になっていることが分かります。

３．議論をする上での心構え
本来議論というのは、炎上をねらったり、闇雲に自己主張をするのではく、自己の見聞を広めたり、起こった事象に対して深い考察を行ったりするものであると考えます。

　(1) 議論は勝ち負けではない
　　これがぜんぜん解っていない人がいます。議論で相手を言い負かすとか論破するとかは少なくともITの分野では意味がありません。

　(2) 相手の主張に耳を傾ける
　　自己の主張に反論してくる人は、ある意味ありがたい人です。相手の主張を受け入れ真摯に答えましょう。私は、SQLの実行パフォーマンスについて 2010で、「OO言語側の最適化が不十分である可能性がある」と結論付けていますが、これはつまり一見すると『SQLはオブジェクト指向言語の数十倍の効率』ということが正しいと思える場面が存在することを認めています（その上でそれは視野の狭い経験にしか基づかないという指摘を行っています）。

　(3) 相手に感謝する、発言を憎んで人を憎まず
　　議論を行った後は相手に感謝の意を表する必要があります。私自身、SQLの実行パフォーマンスについて 2010という記事を書くにあたって再度勉強になりました。そういう意味では件の社長には感謝したいですが、それを『文盲のサル』と言われてしまっては腹も立ちますがそのような感情は捨てて、この場で感謝の意を表明しておきましょう。

素直さは如何に大切か

ちょっとADPの記念記事からは外れますが思ったことがありますので記事にしてみます。

技術的な論争を行ったときにどうしても、ご自身の主張（例えば『SQLはオブジェクト指向言語の数十倍の効率』）が否定されたことを認めたくないばかりに、『サルに何を言っても意味がないので、次に来ても消します。』等と言って自説を強弁したり相手を中傷したりすることがあります。
ちなみに、ここで私を文盲のサル扱いしていますが、そういうこと自体が褒められたことではないし見る人がみれば議論から逃げているとして取られないかと思います。

私も含めて人間誰しもそういう面があります。ので、そんなことをいちいち追求しても仕方がないことだと思っていましたし、それを追求すること自体あまり程度のよいものではないと思っている面もありました。

要するに零細企業の一社長が何をいっても社会にはあまり影響がないので言わせておけと思っていましたが、私はこの『事実より自分の主張を優先する』という性が少なくとも日本人の特性として思った以上に根ざしており、零細企業の一社長だけでなくそれなりの企業や組織にもそういうことがあるのではないかと心配しております。

私はこの議論を行っているなかで、『仮にこれが今の原発事故の話ならどうだろう』と思って寒いものを感じました。

つまり、原発事故で某電力会社は事故から2ヶ月後にメルトダウンしたことを認めています。記事
最終的に某電力会社はメルトダウンを認めたから事故の重大さが周知され、我々国民も対応について選択が出来る（または覚悟が出来る)ようになったかと思います。当初はメルトダウンはないといっていたり、発表が2ヶ月後になったということを考えると充分ではないことも明白で、ここでも事実を素直に受け入れることの重要性がわかります。

また、他の電力会社のやらせメールもありましたが、これに関しても『技術的には取り扱いを慎重に行わなければならないのに一方の考え方を押し通す為に、一見技術的には正当とみえるような議論を行う。つまり煙に巻く。』ということで、そう多くないとしても私の回りでもしばしば見受けられる現象です。

ここで重要な点は、技術的な内容についての真偽は技術者しか分からないということで、もし議論する一方が事実をありのまま受け入れずにそれを隠したりねじ曲げたりすると場合によっては大変な過ちを生み出すことになるということです。つまり議論を見ている専門知識を持たない観衆は判断がつかないところで勝手に誤った方向に持っていかれるということです。

私も過去に議論に巻き込まれて事実を受け入れることから逃げたくなったり逃げたこともありますし、やり込められると徹底的に逃げる人もみてきました。さらに裏で手を回して私を追い落とそうとした人もいます。
今回はただの議論なので『まぁいいか』ですみますがそれでも『SQLはオブジェクト指向言語の数十倍の効率』という間違った知識を若い人に伝えたくないのでがんばりましたが、私は今回のことは改めて如何に技術者として特に重要な技術的な内容については正直でなければならないと思い知らされました。

私も頭の体操ということで議論していまし今後も議論を行うでしょうが、こういうことを肝に銘じて技術的な事実関係は真摯に受け止めるように勤めたいですし、相手がそういう態度に出るのなら厳しく追求したいと思います。と同時に権力者が同じように国民を煙に巻いてこの国を誤った方向に持っていこうとしないようにしっかりと見ていきたいと思います（まぁこれには限界があるのですが・・・）。

e-Taxで個人の確定申告

　確定申告の時期ですが、今年はe-Taxで申告しました。という訳で今回はそのレポート。
いきなり結論ですが、個人の確定申告の場合、e-Taxは便利かと思います。特に良いところは、いちいち手で書かなくてもよく、ほとんど自動で転記してくれるので手間がかかりません。また今年（？）まで、初めてe-Taxで申告する方は、５,０００円の税額の控除があります。いくつか準備が必要ですし、こういう話もありますが、準備は１回ですみますし、それを補ってあまるぐらい便利でしたので、今からでも間に合いますのでよろしければご参考にしていただければと思います。
もっとも、今まで確定申告をご自身でやったことない方（税理士等にまかせっきりで内容を確認していないとか初めての確定申告とか）はちょっと厳しいかと思いますのでそのあたりは充分にご検討された方がよろしいかと思います。
　
※注意！ 私と当局の方とはまったく関係がございません。本ページの記載内容はあくまでも個人が試した結果であり、間違い等がありましても著者は一切責任を取りませんのであらかじめご了承ください。
　
■必要（使った）なもの
　・ICカードリーダー（私が使ったもの）
　・住民基本台帳カード
　・電子証明書（住民基本台帳カードにインストールする）
　
ICカードリーダーは３千円で購入しました。住民基本台帳カードと電子証明書は役所で入手できます。手数料は、それぞれ5百円（計千円）掛かりました。カードと証明書は、即日発行できるところや２週間程度かかるところ、住民基本台帳カードのみ取り扱うところとかありますので役所のホームページで確認した方がよろしいでしょう。今からでしたらぎりぎり間に合うかと思います。
　　

■環境の構築（事前セットアップ）
　詳しくはe-Taxのページを読んで頂くことになりますが、事前にソフトウェアをインストールする必要があります。ちなみに私はWindows7 64bit ulitimateで環境を構築しましたが正常に動作しました。
　
■私がはまったところ
　詳しい使い方は、e-Taxのページを見ていただければと思いますが、数年間に渡りいろいろバージョンアップを重ねたようで個人の確定申告に関してはだいぶ使いやすくなったかと思います。通常の給与所得者の申告もできますし、青色申告にも対応しています。
一応私はソフトウェア関係のプロですし、確定申告も何回かやっているので要領はわかっているつもりですが、それでもいくつかはまりました。以下、私がはまった点を紹介します。

• 番号取得時（初回）のリンクと、作成再開のリンクが異なる　－　当たり前かもしれませんが、初回のリンクと作成再開のリンクが異なります。この画面の大きなボタンの『作成開始』というのが初回にクリックするボタンで、『作成再開』が２回目以降にクリックするボタンです。ちなみに、２回目以降に使用するというのは入力処理を中断して再開する場合を指し、その際にデータを保存しておく必要があります。
  　
• カードリーダー周りのトラブル　－　カードリーダー周りで２つ程、軽微なトラブルがありました。１つは事前セットアップ後に、プログラムグループの『公的個人認証サービス』から『ICカードリーダライタ設定』を実行しておく必要があるがその説明がFAQにしかないのでカード読み込み時にエラーになる点と、もう１つは、設定後でもカードリーダーが上手く読み込めないことがありその場合に一旦「戻る」をクリックし画面を戻し、もう一度進めると上手くいくことがありました。
  　
• ヘルプデスクの担当者について　－　２回程電話をしましてあくまでもその範囲内での意見ですが、ヘルプデスクの人に当り外れがあります。確定申告の規則がややこしいので全部を覚えきれないのでしょうが、いい加減と受け取れる回答をする方がいらっしゃいましたのでその場合は、１．『そんなはずはない』と言って上の人に調べてもらう（エスカレーションしてもうらう）か、２．かけ直して知っていそうな方に当たるまでがんばるか、しましょう。
  　
• 間違えて申告した場合 －　一旦送付した後に間違いに気づいたのですが、ヘルプデスクに確認しましたところ電子申告自体は何度でもでき、最後に申告したものが有効になるとのことで、そのままもう一度申告しました（データを保存していたので修正して電子申告しました）。
  　

　
とまぁ、こんなところで私と嫁の確定申告が２時間半で終わりました（去年は半日かけました）。
　

ITエンジニアにとっての円高のメリット

最近円高のニュースが続きますが、まぁ日本経済にとっては円高はよろしくないかと思いますが、あまり悪いことを考えてもなんなので、ITエンジニアにとっての円高のメリットを紹介します。
　
現在のPC関連のパーツですが、基本輸入品になりますので、円高のメリットを受けられます。
ちなみに、某価格比較サイトによりますと、1枚4GBのDDR3のDIMMが6千円を割り込むぐらいの値段になっていますし、6コアのCore i7 - 980Xが8万円台で買えます。これを軸にシステムを組みますと、
　
CPU：6コア、論理12スレッド（Core i7 - 980X）
メモリ：総合計 24GB（DDR3 4GB × 6 ）
　
ちょっと前のサーバーなんか目じゃない、なんていう夢のマシンが20万円までで組めるのですごい時代になったもんだと感心します。
私もどうしようかと悩んでいるところです。もっとも今はメモリ24GBを使って何をしようかと思案中なのですが・・・。

中小企業実態基本調査

ここのところ更新をさぼっていましたオオフジです。書くネタがないことはなかったのですが、今月、英検がありまして勉強で地味に急がしいので更新をさぼってました。といってもあまりにも更新しないとアクセス数が下がるので更新します。
　
10月に入りまして国勢調査の時期になりましたが、一般的でないと思われる調査に、中小企業実態基本調査というのがあります。
詳しくは、このページを参照頂ければよいのですが、平成16年から毎年行われているらしく今年はうちの会社にも調査がありました。
調査内容は、いわゆる決算の内容にプラスして、従業員の数やその他の質問があります。印象に残ったのは、『貸し渋りにあってますか？』とか『電子商取引の売上に占める割合は？』とかがありました。
　
調査結果もみることができまして、例えば、平成２１年確報で
・売上高の内訳、産業別・従業者規模別表をみますと、情報通信産業の一人当たりの売り上げ高が、
　法人企業　約1400万円
　個人企業　約 500万円
　
となっているようです。IT産業の場合、個人企業というのはほとんどフリーランスのエンジニアだと思われますので、フリーランスのエンジニアの収入が約500万円といったところになるようです（もちろんあくまでも平均になります）。また法人企業の場合では外注やハードウェアの仕入れ等も行っていると思いますので一人当たりの売上高を計算すると個人企業よりも高くなるかと思います。
　
また、先ほど出てきました、電子商取引についてですが、
・電子商取引　産業別・売上高階級別表をみますと、全体的には、概ね

実績が上がらなかった	10％
売上高に占める割合が10%未満	50%
売上高に占める割合が10%以上	25%
まだやっていない	15%

　
とのことで、ECサイトに関してはこれからは、新規開発というより、売上アップの為のコンサル的な仕事の需要が増えるかと思われます。
　
もちろん私もその手のご相談にのることができますので、相談毎などありましたらこちらにアクセス下さい（って最後の締めが宣伝か・・・）。