2016年11月29日

Excelで同じ数同士の引き算をしても、結果が0にならない不思議

【1−0.1×10は? 人工知能に怯える前に知ってほしいこと】
http://itpro.nikkeibp.co.jp/atcl/watcher/14/334361/112100725/

この記事では、Excelで1−0.1×10を計算すると0にならない、ことを紹介しています。
※厳密には(1−0.1−0.1・・・)と0.1を10回引き算するのですが。

小学校で算数を勉強した人からすれば意外に思う点ですが、これはコンピュータ計算の特性でもあります。
記事中でも次のように書かれていますが


これは、コンピュータのすごさとダメさの両面を、その仕組みとともに体験したうえで、コンピュータとの付き合い方を考えて身に付けるきっかけになればという思いからである

人工知能の脅威に怯える前に、コンピュータおよびプログラミングについて理解を深め、それらとの付き合い方を考えてみてはいかがだろうか。


人間が考えるようにコンピュータを動作させることの難しさを表現した記事でもあります。

実は、人間が学校で学んだ計算処理方式と、コンピュータが採用している計算処理方式が同じでないため、こういうことが起こるのです。
この記事では、なぜ1−0.1×10が0にならないかについては、丁寧に説明をしていません。
この記事を読んだ一般の人は、納得いかない妙な気分だけが残ってしまったかもしれませんね。私はその理由を知っていますが、これを説明するにはある程度の文章量でいくつかの前提を説明する必要があるので、私もここは割愛します。
怒らないでください(笑)


さて、この「同じ数を引き算すると0にならない事象」ですが、金融の現場では無視できないこともあります。
例えば、ライフプランシミュレーションなどシミュレーション系のシステムなら適当に四捨五入しちゃって問題ありません。
でも、例えば次のような場合、

・住宅ローン返済で、最後の月の返済をしたときに、住宅ローンの残高が1円未満の微量数になる
・預金の全額払い戻しの時、口座残高が1円未満の微量数になる

というケースでは、この微量数をうやむやにすることはできません。

この1円未満の微量数も、取引件数が増えて積みあがればその合計は1円を超え、時には万円の単位を超えることもあります。
これは金融取引会計上には現れないお金ともなるので、このお金をこっそり自分の口座に送金・・・なんてことがあってはいけないわけです。
なので、きっちりと小数点以下の端数処理を規定したり、そもそも同じ数の引き算をして0にならない仕組みを採用してプログラムを作っています。

システム屋さんの教育でも使われる話であり、久しぶりに思い出させてくれた記事でした。
でも、本文は人工知能とは一切関係ないのに、「人工知能に怯える前に」なんてタイトルをつけているので、これは釣りタイトルだなあとも思ったのでした。
posted by キヨ at 08:04| Comment(0) | TrackBack(0) | システム開発

2016年10月21日

バグ発見の報奨金の仕組みも、万能ではない

【田嶋陽子氏、システムのバグ発見で1000万円単位の報奨金を…銀行員11億円着服容疑で提言】
http://headlines.yahoo.co.jp/hl?a=20161014-00000088-sph-soci


田島氏が述べたような方法を採用することで、不正がなくなる、という気持ちはわからなくはないですが、残念ながら万能な方法でもありません。

メディアは、この報奨金の仕組みを素晴らしいと伝える傾向がありますが、現実には運用上の問題もあります。
思うような成果を上げられなかったり、報奨金の仕組みが別の問題を引き起こすこともあります。
例えば、次のような問題点が指摘されています。

■1
脆弱性を発見して報告しても、「問題ではあるが脆弱性ではない」と言われて報奨金をもらえないことがあります。
また、「その脆弱性は他の人からすでに発見しており、今回は報奨金の支払いにはならない」と言われることもあります。
実際、報奨金の支払いは、脆弱性報告全体の1割にも満たないともいわれています。
あるハッカーがこういう経験を積んでしまうと、以後見つけた脆弱性を素直に報告せず、自ら悪用してみる、または悪用する組織に情報提供して利益を受ける、というモチベーションに変わることがあります。
善意の心が、恨みに変わってしまうということです。

■2
外部からはどうやってもアクセスできないシステムに対しては、この報奨金制度は事実上役に立ちません。
今回の銀行員の不正が、原理的に組織内部の人間にしかできない操作だったのであれば、いくら外部の力を借りても発見することはできません。

■3
脆弱性を発見したがる方が、必要以上にシステムに負荷をかけていしまい、正規の利用者がそのシステムを利用できなくなることがあります。
脆弱性報奨金制度を採用する場合、それに備えてシステム増強のコストを積まなくてはならない場合もあります。

■4
報奨金を得る目的で、次のように開発者が悪事を働くこともあり得ます。
・ある開発者がわざと脆弱性を仕込む
・その開発者が脆弱性の報告をするわけにもいかないので、別の人に脆弱性を伝え、報告してもらう
・得た報奨金を、裏でこっそり、開発者と山分けする

■5
思った以上に脆弱性を発見されてしまうと、報奨金支払いが多額になり、財務状況の悪化を招くこともあります。そうなると、そのコストはどこかに転嫁されていくことになります。
へっぽこエンジニアたちによって作られたシステム、仕組みがぐちゃぐちゃになって容易にメンテナンスできないシステムだと、このリスクがあります。

 
といろいろ書きましたが、そもそも不正を防ぐということはなかなか難しいものです。
犯罪者を擁護するつもりは全くありませんが、権限を持つ人がその気になれば、不正は行えてしまうことも多々あるのです。
そういう土壌をなくしていくことは、組織全体で永遠に取り組み続けなければならないことですが、根本的には、外部に頼って解決できるものではないのです。
posted by キヨ at 08:40| Comment(0) | TrackBack(0) | システム開発

2016年03月18日

HTMLのソースコードに改修履歴を書いている、国税庁の「確定申告書作成コーナー」

今年の確定申告書提出も無事終わりました。
現在は、国税庁のサイト「確定申告書作成コーナー」で確定申告書を簡単に作れるので便利になりましたね。

私もこれを使って申告書を作成していますが、このサイトがどういう仕組みになっているのか興味があったので、HTMLファイルのソースコードを見てみました。

 
すると、過去の改修記録(不具合改修を含む)が、HTMLのコメントとしてご丁寧にも書かれてあるではありませんか(笑)
確定申告書作成コーナーの開発部隊では、不具合が発生したときに起票する書面を「故障票」と呼んでいるようですね。(そう書いてある・・・)

この改修履歴とJavaScriptのプログラムを見ましたが、税務を理解していないITエンジニアが、一生懸命頑張って作ったんだな、ということもよく伝わってきました(笑)
この開発部隊を束ねるマネージャーも、いろいろ苦労したことでしょう。

 
開発履歴や不具合の管理は、開発者側ではしっかり把握しておくべきことではありますが、わざわざサイト利用者のブラウザにまで転送しなくてもいいのに・・・と個人的には思います。
それに、作るときにどれだけミスしたかってことがばれてしまうので、ちょっと恥ずかしい。

私だったらこんなことはせず、ちゃんとプログラム開発管理ツールで履歴を残しますけれどね。
15年前の仕事のやり方を採用している会社に、発注したんじゃないかなーと、個人的には推測しています。

 
と、いろいろ書きましたが、便利なサイトの裏には、不具合改修をたくさん積み上げながらも、作った人たちの苦労があるものなんですよ。
そんなことを思いながら、今年の確定申告書を作ったのでありました。
posted by キヨ at 22:06| Comment(0) | TrackBack(0) | システム開発

2016年03月09日

プログラマーは年収低いばかりじゃない、優秀に能力を発揮するプログラマーもいるのだ

私が日ごろ開発現場に対して思っていることを、ズバリ書いているブログです。
http://blogs.itmedia.co.jp/junmtd/2016/02/post_6.html

プログラマは一番下っ端で、設計する人がその上にいる人材で、いわゆるプロマネが開発業界の頂点。
このピラミッド構造をのぼっていくにつれて、人月単価も上がる。

こんな「士農工商」的な発想で、システム会社を成り立たせているところが多くあります。
こういう組織では、プログラマは大事にされず、名ばかりのプロマネが重宝されるようになっていきます。

こんな開発チームで下っ端的な働きしかできないプログラマもいれば、依頼者とコミュニケーションを取りながら(プロマネ的な動きをしながら)プログラムを書く人もいます。
後者の方が、仕事のスピードと正確さは、断然高くなります。言うまでもないことです。
これが、上記で紹介したブログで書かれている「圧倒的な生産性の違い」「スピーディーな問題解決」に当たるのでしょう。

他社で3人分の働きができるプログラマであれば、一般的なプログラマの年収の3倍の年収をもらうことも、悪くない話です。
海外で年収1000万円のプログラマがいるといいますが、プログラマを下っ端扱いしかできない組織では、考えられないことだと思います。

 
プログラムを書くエンジニアは、二極化しています。
そのプログラマが所属した組織によって、二極化してしまうと感じます。

自社でサービスを提供している会社にとっては、依頼者のニーズに沿って的確な動きができるプログラマが必要なはずです。
市場ニーズにも素早く対応できるようになり、自社のサービスを劇的に変えていけます。

プログラムを書く能力を会社の戦力とみなせるかどうか。そういう経営ができるかどうか。
こういう発想で考える人が、増えてほしいと思います。
posted by キヨ at 22:27| Comment(0) | TrackBack(0) | システム開発

2015年12月04日

ITによる自治体業務の効率化は、できそうでできない

日本全国にある自治体の業務(市区町村が行う業務、都道府県が行う業務、の意味)は、比較的に通っている部分があるものの、各自治体ごとでバラバラに業務コンピュータシステムが構築されています。
これを全国で統一したシステムを使うようにすれば、日本全体で開発費やシステム運営費用も削減でき、国家規模で税金を効率よく使えるので合理的です。

しかしこれだと、日本全国で公的サービスが一元化、一律化されるということもあり、自治体独自の取り組みができなくなってしまいます。
特徴ある自治体サービスを打ち出して差別化することも難しくなってしまいますね。

だから自治体のシステムは、自治体ごとに開発すればよいという現状に、話が戻ってしまいますが・・・
税金の使い道として、どちらがよいか。悩ましい問題です。
posted by キヨ at 19:29| Comment(0) | TrackBack(0) | システム開発

2015年09月20日

VB6→ユニバーサルアプリへコンバートするツールがあれば・・・

ふと思いましたが、いまだ動いているVB6のアプリを、タブレットアプリとかにコンバートできる製品があれば、喜ぶひとがある程度いるのではないでしょうか。
ユニバーサルアプリに変換してくれるツールなどが出てくると面白いなあと。

今日はちょっとしたつぶやきでした。
posted by キヨ at 11:23| Comment(0) | TrackBack(0) | システム開発

2015年07月12日

システム側の文字要件を、利用者に強制するのはよろしくないが、そんなサイトはまだまだ多い

私が開発するシステム/アプリにおいて、大多数の場合、次のようなUIルールにしています。

・全角と半角どちらでも入力可(特に数字やアルファベットの入力欄)
・ひらがなでもカタカナでもどちらでも入力可(例えばふりがな欄など)
・ハイフンは入れても入れなくてもよい(例えば電話番号など)

システム側の要件として、数字は半角じゃないとダメ、電話番号は数字だけで管理しているからハイフンを入れられると困る、という場合もそれなりにあります。
メールアドレスに全角文字を入れられてしまうと、実際の送信処理時でエラーになることもあります。
全角で数字を入れられてしまうと、DBのint型の列に値を入れるときにエラーになってしまう、ってこともあります。

 
ところで全角と半角って、システム屋さんからすればハッキリ別物と認識はしているのですが、一般のパソコンユーザーは、全角と半角を区別せずに使っている人も多いです。
数字やアルファベットが、標準で半角に変換されるのか、それとも全角に変換されるのか、これは各利用者ごとのマシン環境に依存するものです(Windowsならコントロールパネルで設定できる)

 
だからといって、私が作るシステムでは、システムに合わせた入力をユーザーに強制することはほとんどありません。
なぜなら、さまざまな入力を受け付けても、適切な変換をしてからDBに保存したり処理にかけるようにしているからです。

最初に3つの事例を挙げましたが、.NETであれば
・全角文字のうち、半角に変換できるものを、一括で半角変換する
・ひらがな文字を、カタカナ文字に変換
・ハイフンやアンダーバーを、文字列から一括で除去
といった処理を簡単に行うメソッドが、標準で存在するので、それを使っています。

 
半角と全角を入れ間違えたために、何度もエラーメッセージが出て、めんどくさくなったのでそのサイトの利用をやめた。
こんな理由で顧客を失うのはとてももったいないですね。

世間には、システムに合わせた入力要件を要求するサイトが、まだまだたくさんあります。
ぜひとも、変換ロジックを用意して、柔軟に入力を受け付ける体制を作ってほしいと思います。
そんなに難しいことではありませんからね。
posted by キヨ at 12:42| Comment(0) | TrackBack(0) | システム開発

2015年05月01日

システム開発を受注するときに大切なこと

ベンダーが、ユーザー企業からシステム開発を受注するときに必要なことを、メモしておきます。

・ユーザー企業の投資計画や評価方法を把握する。
ユーザー企業において、どのようなシステム開発プロジェクトが成功と見なされ、喜ばれるのかを知るべき。それと異なる観点でシステム開発の提案をしても、受け入れられない結果になる。

・ユーザー企業のシステム全体像を把握する。
これから着手しようとしている開発案件が、どのような位置づけであり、どのようなシステムと連携すべきなのかを見定める必要がある。

・ユーザー企業がどこまでを自分でやり、ベンダーに何を期待しているのかを把握する。
期待されている領域を誤って判断しても、ベンダーの提案は受け入れられない。

・ユーザー企業の開発標準、アーキテクチャ方針を把握する。
既存の標準やアーキテクチャから大きく外れた提案は、人的負担やコストの面でマイナス評価となる場合がある。

・発注権者、発注手順、発注のタイミングを把握しておく。
担当者が発注を予定しているなどと言っても、最終的に発注を決定する権限を持つ者が別の人であることもある。
posted by キヨ at 18:47| Comment(0) | TrackBack(0) | システム開発