Ognacの雑感

手順が簡単になると、平均レベルは下がるのか....?

Ｏｇｎａｃ — Tue, 02 Dec 2008 00:10:00 GMT

業務アプリの入力欄は、妥当性のチェックが不可欠です。
そのとき、警告の通知方法をどうするかは、設計者の意識で変わります。
Webアプリだと、PostBackを伴うのは避けたほうが良いので、 Submit時に行うことを推奨してます。
クラサバアプリだと、LostFocus時にCheckしたり、TextChange時にチェックしたりするのが多いようです。
項目単位のチェックだけでは完璧にはなりません。複数の項目で統合的にチェックする必要があるからです。
たとえば、年、月、日の欄が３つのTextBoxで実装していたり、受注日　< 納品日などの条件チェックがあるからです。
画面単位のチェックは不可避です。ことのとき、複数項目にエラーがあるときの通知方法を、えらへ項目を赤反転させた上でDialogで表示させて、OK釦を押させるか、通知欄に文言をラベルで表示するか。
何が効果的かは、顧客の過去の経験則にもよるので、サーベイしてから、決めるのが良いようです。
TextChange時にチェックして、都度、MessageBoxをだすのは、頻発すると、都度OKを押すのが鬱陶しくなったりします。
また、複数箇所にエラーが有っても、1件目のエラー内容だけを表示する、システムもあります。
私は、これは手抜き感を抱きます。n件までのエラーは、反転した上で、列挙するのが良いと思います。
クラサバでTextChangeやLostFocus時の項目単位のチェックすることに慣れた人が、Webアプリを担当したとき、この仕組みを踏襲して、PostBack多発の画面を作ってしまう人がいたりします。
　「AutoPostBackはトラフィック増加するし、画面がちらつくから止めた方がよい」と指摘すると、「各項目をAJAXで作ったからちらつかなくなった。」.....うーん。違うんだけどなぁ。
　IDEで Webもクラサバもお手軽に同様に作れるようになった反面、両者の特性を認識しない開発者が出てくるのは、皮肉なものです。
手順が簡単になると、技術力の平均値が下がるのは、避けられない道です。裾野が広がると、広がった分だけ下がります。
しかし、トップレベルも上がるので、善し悪しでいうと、善いこととされます。(これは以前にも書きました。)
工業製品に限らず、農業も、機械化、農薬化が進んで、「こつこつ手作りの技術が下がった」と言う人もいます。
病院では、測定器具が発達して、医者は人に向かずに機械の数値で処方しているとも聞きます。
洗濯板で洗濯できない人に対して「洗濯技術が欠けている」と言えないでしょう。
竈で始めチョロチョロ中パッパの火力調整して、米を炊けない人に対して「飯が炊けない人」と非難できないでしょう。
四サイクル／２サイクルエンジンの違いを知らなくても、運転は出来ます。「無知な人」と非難できるでしょうか。
　こういった現象を「進歩」とみるか「嘆かわしい」とみるかは、難しいです。メンタル的に「退化」とするほうが、迎合的ですが、発展過程には不可欠な現象な気がします。

クラサバと同じ流れをWebに持ち込むと、問題多発なので、学習事項は残るので、上記の事象と同等ではない....と指摘されるかも知れません。しかし、Webアプリが SilverLighteなど他の形態に変われば、類似した作りが可能になるかも知れません。
そう考えると、断定できる事柄って無いのかも知れませんね。

使いやすさの定義・業務システムは簡単か?

Ｏｇｎａｃ — Mon, 01 Dec 2008 01:34:00 GMT

前回のエントリーが尾を引いているのですが. ここ
何事も10人10色で、全員が納得する仕組みや使い勝手は存在しません。国や制度なら尚更です。
システム作りも政治も、その面では同じです。20%が不満でも80%が満足するか、90%の人が少しの不満をもつか、どちらが良いかなどは、判断できるものではありません。人の価値観で異なるし、時代背景にもよるでしょう。
幸福度の高い人を多く作るか、適度な不幸を皆で共有するかも、意見の分かれるところです。
私は、どちらの世界も有って良いと思いますし、住民が自分の意思で選択か引っ越しができる仕組みがあれば良いなと考えるのです。
　システムも、経営者にとっての使い勝手と、実務担当者にとっての使い勝手とは違います。
実務担当者にとっての必要項目も、経営的には不要な項目もあります。近視眼的に必要と思われている項目も実は不要だったということも多くあります。その判断は、システム屋が出来るものでは有りません。上意下達なら、直訴できるだろうし、相手担当者に実権があるときは、従うしかないでしょう。
　使い勝手は、使う人の慣れ具合も左右されるので、相手の経験にも依存されまます。
正論な論理だけでは構築できないのが業務システムの難しさです。OSやコンパイラは、実装技術的には高度なスキルを要しますが、理論がはっきりしていて、作る仕組みが固定化されるので、その面ではスッキリして、作り易いとも言えます。(作り易い/難しいの比較は無意味なんですが)
　一言で言ってしまえば、業務システムは、入力データの集計仕事に集約されてしまうので、答えが確定するだけに簡単そうに見えますが、多システムとの複合した仕組みだと、トランザクション管理すら自由になりません。 MS系で、Active_DirectoryとRDBを同期をとって動作させるのも、難しいものがあります。ましてや、他のOSと連携させるとなると尚更です。
他の仕組みとの連携保証を高めると、使い勝手が犠牲になりがちです。トレードオフになります。
経理システムとの連動は、金と物との流れと矛盾が付きもので、落とし処を見付けるのを要求されても困るだけです。
新人や知識不足の技術者だけて作れるものではありませんし、作れるとは誰も言わないでしょう。経験を積む必要があるので、自然と淘汰されます。
個々のプログラム開発は護送船団方式であっても、システム開発は押さえるところは押さえている筈です。
ただ、予算と期間という壁があるので、100%満足できるモノは作れないので、どこかで納得の上で妥協する必要が有ります。PMやリーダーの腕の見せ所です。
#ダメPMによる火災も起こりますけどね.www

落とした1円を拾うな　?

Ｏｇｎａｃ — Sat, 29 Nov 2008 01:39:00 GMT

１円落としても拾うなという話があります。
探して、屈んで拾うコストが1円以上かかるのが理由のようです。一理ありそうに見えたのですが、引っかかります。
昔話に,落とした10文を探すのに200文の松明を使って探す話がありすます。無くしたままだと10文は社会から消失するが、200文使っても探しても200文は社会に循環するので、消失はしないという考えですね。
　#この話を聞いたときに、夜が明けるまで待って、探したら、松明を買わずに済むと考えた私はセコイのかな。
両極端の話です。この問題は、通貨という社会リソースの損失と、リソース維持コストの費用対効果と見ることもできます。　紛失したままだと、リソースとしての価値がなくなるので無駄ですが、世界ベースで物質として考えると、何処かに存在するので、地球的損失ではありません。人とって利用価値がなくなる限定的な損失です。

損得勘定の判定は、「個人的且つ短期間」での判断と、「社会的、中期間」での判断と、「地球的、長期間」での判断では異なってきます。
大事なのは、判定基準がブレないことだと思います。基準がブレルと矛盾したことを言っていると受け取られます。
　経営判断の問題かもしれませんが、中期的な視点が大事だと思うのです。落とした1円は拾うべきだと思うし、夜が明けてから探せば、よいと思うのです。
夜が明けるまで待つ時間的ロスと　200文の松明とのトレードオフの問題は残りますが。
社会リソースは、金銭的損得だけで価値判断するのでなく、大局的に判断したいものです。

偶然は偶々なのか必然なのか

Ｏｇｎａｃ — Thu, 27 Nov 2008 01:47:00 GMT

元ネタ:επιστημηさんの記事ここ
厚生省幹部事件犯と学友(?) だったとか、住まいが近所だとか記事やコメントにあります。
メンバーやコメント投稿者数は100のオーダーでしょうから知り合いである確率は低そうに見えますが、友達を数代辿ると全世界をカバーできるという話もあるので、起こりえるのかなぁとも思えます。偶然といってよいのか否かはわかりません。
「偶然」を少し考えてみました。私の体験した最大の偶然は、社会人2年生の夏休みに、友人とフィリピンのマニラに行った時の事。バンブーダンスのディナーショーで食事をしていた時、見慣れた顔が数人、会場に入ってきました。よく見ると、会社の幹部4人組みでした。相手もびっくりした模様で、互いに「なんでここにいてるんだ。」と叫び合いました。
会社の幹部のインセンティブ旅行だったようです。もちろん私達二、三年生の知らない事です。こんなことってあるんですね。
日常生活でも、　何十年ぶりかの友人に、偶々乗った電車で出会ったという話は良く聞きます。
　繁華街で雑踏のなかで、滅多に会わない人に会ったりします。
私ごときがワンクマメンバーに加えて貰っていたり、Blogで発言させて頂いているのも「巡り合わせ」とも「成り行き」とも言えます。参加したいと思った時期と環境がずれていたら、入ってなかったでしょうし。
これらの事例も「偶然」はなく「巡り合わせ」といえそうです。

では、「巡り合わせ」は誰かが演出しているのでは? という疑問が沸くのです。
宗教家なら、神や仏の御導きというかも知れません。私は「俗にいう宗教上の神」は信じてません。しかし、「巡り合わせ」を演出している「大いなる主」の存在は信じてます。
それが、神なのか仏なのか、アッラーなのかキリストなのかは不問ですし、無関係だと思うのです。
「袖すれ違うのも他生の縁」を信じます。人との出会いも大切にしたいものです。
嫌な目にあうのも、栄養素の一つです。
一方で、運の良い人や悪い人は、います。同じことをしても、うまく行く人と行かない人がいます。その人の性格や人柄なども、巡り合い要因の一つでしょう。
地域と時代がずれて生まれたために、不遇の目に遭う悲運な人もいます。しかし、現世の価値判断から見るから運の無い人に評価されるのであって、大局的には有意義な役回りの人かもしれません。人は不完全だから、良き面が見えないだけかも知れません。
(現世の基準で)理不尽な酷い目に会う人や、理不尽に好待遇の人もいます。平等というのは永遠の課題で、到達しないものかも知れません。しかし、近づく努力は必要です。
現世の今の意識下で、行動しているのだから、今をベターに生きるのが、人の道だと考えます。
私の好きな言葉に
「神を信じなくてもよい。神に信じられる人になれ」「神は超えられる試練しか与えない。」
があります。実経験上、事実だと確信してます。

ギスギス度が加速し、不愉快な人や事件が多発する世を憂いて、不安になります。「巡り会い」を演出してくれる「主」に背いてなるものぞ.......... (*) 決して新興宗教を起こそうとはしてませんのでご安心を。

(*)追記
マーフィー則も、そう思えるだけで、有意差なしとされています。
血液型云々は意味が無いのは立証できるのでしょうが、納得できるマーフィ則はありそうな気がします。
私はのマーフィ則に「職場で１回目に行くトイレは、清掃中で入れない」があります。
複数の現場でそうでした。勤務階が変わってもそうでした。
この手の話は、UFOやネッシーのように白黒付けるより、未解決のまま放置するほうが楽しいですね。

無防備感がする政治家や私たち

Ｏｇｎａｃ — Tue, 25 Nov 2008 01:06:00 GMT

ニュース番組などで、政治家が携帯電話で話している光景を見ます。
無線を介しているので、盗聴の可能性はあります。
国家機密や党外秘の話はしていなとおものですが、そういう姿を映すのは、隙があるように感じます。意図的に流しているのかも知れませんが、マイナス効果の気がします。
無線Lanもかなり普及してますが、盗聴や成りすましの可能性は拭えません。隣人の無線Lanに便乗しているという噂は時々耳にします。
無防備といえば、タクシーの中では、運転手がいるのに、乗客しかいないと錯覚して、マル秘話をする人が多いそうです。
エレベータの中は個室ですが、マイクがはいっていたら、ヤバイラシイですね。トイレなどの立ち話や、酒場、喫茶店などでも、自分達以外の他人は居ないものとして、話している人も多いと聞きます。
こういう状態を心理学用語でなんとかというそうですね。<=オイ! 調べてからかけ!
ネット回線やノートパソコンのセキュリティ管理は、業務に支障がでるくらい厳しくなっているのですが、「壁に耳あり」のローテクのセキュリティは人のモラルに依存するだけに難しいです。自分が当事者のマル秘事項は、漏らさないでしょうが、偶然耳にした、他人の話を、秘密と解らないにせよ、漏らさない。と断言できるだろうか...自問。

顧客はコード品質を要求しているか

Ｏｇｎａｃ — Sun, 23 Nov 2008 00:57:00 GMT

前回のエントリでは、あちこちに波紋が広がってしまいました....www。
参考になるコメントを頂いてありがとうございます。(各Blog伴に)
「誰が何を要求しているのか」と「各行程の作業実務者の品質意識」と「行程管理者の管理意思」と「各担当の利益」を同一の土俵にするのは不可能に近いでしょう。どこかで妥協しなければなりません。その妥協点が合意出来れば最良なのでしょうが、不満総量が最小になる箇所で自然に落ち着く気がします。大同小異で各行程の人が同じ位の不満を持つ状態が、実務の姿かなぁ。　　と斜に構えて、発言してますが、開発者としては寂しいです。
テーマが大きくて、全体的には考えが纏まらないので、「顧客はコード品質を要求しているか」の点で考えて見ました。
一般的な業務アプリは、集計作業の固まりとみて良い思います。(統計分析・予測含む)
機能は、データの入力と抽出と加工と出力です。(単純化するため制御系や言語系やゲーム系は省きます。)
入力要件と出力要件と応答性が満たされれば、業務システムは合格点と見なされます。製品の品質は不問です。
品質云々は開発者の意識度と、納品監督部署がソースの品質を考慮するかしないかの人間性に依存します。
品質を定量的に測定するツールはないです。テストツールはテストパターンの自動化は厳しいので定量性とは言えないでしょう。
　問題を複雑にしているのは、汚いソースでも綺麗なソースでもエレガントなソースでも、要求通り動いてしまうことです。汚いソースでも、正常系処理では落ちない程度の品質は保っているでしょう。(楽観的期待ですが)
異常系操作で落ちても、「想定外のデータを入力した操作員が悪い」という言い分がまかり通る「未熟な実体」も時々目にします。
　ラジオやテレビが単純なIC構成であった時代は、回路を平面エッチングで結線していました。エッチングパターンも明らかに下手な配線というのもあって、ノイズの元になったりします。回避策として、回路切断して、ジャンパ配線で取り繕うこともあったようです。つまり、汚いソースのまま納品するのと同じです。でも、顧客は、テレビを見ることは可能なので、回路品質は不問です。

　あちこちで書かれているように、ハードに進歩が非効率なソースの冗長性を隠してしまうのが現実です。
5倍遅いソースでも10倍はやいCPUなら結果として早くなるので、困ったものです。

ソースが読める顧客は、要求する品質が可能な開発者に発注するので、この手の問題は起こり難いでしょう。
納品後の改変や仕様変更に対応すること踏まえて、変更の容易さはソース品質に比例します。
変更作業者にとって読みやすいソースが望ましいと考えています。
只、問題があり、新人や知識の少ない変更作業者が保守する会社があることです。その人たちに品質を合わせると、議論が振り出しに戻ってしまいます。
　私は「IT業界はまだまだ成長期で、あるべき姿になっていない。」と感じます。

1メソッドは 50行以内

Ｏｇｎａｃ — Fri, 21 Nov 2008 01:22:00 GMT

開発標準に1メソッドは50行以内という規約があったりします。
この基準の真意は、50行という数字には意味がなく、この制限を設けないと、べた書きをする開発者が続出するから、仕方なく、設定していると聞きマした。
センスのある開発者は、1メソッドか何百行になっても、読みやすいのでずか、センスがない人は、数十行でも読みにくいです。
1メソッドn行以内という制約を設けることで、べた書きする人が少ないなるそうです。
その趣旨の適用のために、センスのある開発者に「n行制約」で泣いて貰っていると聞きます。
　センスある開発者からみると、「なんで、彼らに足を引っ張られな、あかんねん」という言う分もあるのですが、比率的には、無センスの人が多いのだそうです。プロジェクト運営を円滑にするって難しいものです。
同様な規約に、ループのネストは二重まで、とか、再帰禁止とか継承は二重までとかあるそうです。
「無センスなプログラマの存在を排除せよ」は暴論で否定しますが、健全な開発体制に与える負の要素も感じます。
この矛盾感は解消されないのでしょうね。オフショアで特に感じました。

「Web アプリでレコードロックを使うな」?????

Ｏｇｎａｃ — Thu, 20 Nov 2008 00:51:00 GMT

前回エントリーの関連になりますが。
とあるプロジェクトで、「Web アプリでレコードロックを使うな」というガイドがあるとかないとか......
理由は、『プログラムとは別次元で画面遷移が発生するので、ロック状態に陥ると、回復処理が煩雑になる』
プログラムの知らぬ要因で、セッションや画面が制御されるので、クラサバに比べると、考慮事項が多くなります。
だからといって、ロック禁止にするのは、本末転倒でしょう。「方程式が難しいから微積分使わずに算数で解けとか、高等数学は不要だ」という理不尽な主張と被って聞こえます。
　排他処理とロックは対といっても良いくらい密接なものです。Webアプリでのアプリケーション変数を更新するときはロックしますし、Seq.ログの吐き出しなどは、排他的に使っている筈です。
「動作しているソースは触るな」という格言があるようですが、「たまたま動いているだけ」かも知れません。
面倒な処理で、内容を理解しないで、コピペして、済ませるのは悲しさを感じますし、品質悪化に繋がります。
確かに、コピペで積み木のように開発するのは、楽です。しかし、内容を理解しないで、楽をすると、災いは自分に跳ね返って来ます。
　火事になるプロジェクトは、前段で楽をした場合が、多いように感じます。不思議なもので、前段で詰めておくと、出火してもボヤで済みます。前段で楽をすると、それの数倍の大火になって逆襲されます。
　全く出火しないシステムは無理と思います。多少の出火は付きものだと思います。しかし、ボヤで済むように開発計画をたてるのも、我々の使命だとおもうのです。
　簡単に見えるものでも、考慮事項は山とあります。考慮事項(排他やロックやその他)を「不要だ」と一蹴するのは、短絡すぎませんか。

タダや簡単なモノの代償は大きい

Ｏｇｎａｃ — Tue, 18 Nov 2008 00:29:00 GMT

タダトモなどのMail無料サービスや、Google/Yahooの無料DISKサービスなど、利用料金無料の仕組が増えました。
利用料は無料ですが、リソースの運営費は発生しているはずなので、どこかが被っています。
安全と水は只という意識も依然としてあります。
サラリーマンは税金や社会保険料が天引きなので、納税意識が薄くなるのは周知の通りです。
面倒でも、自分の手を介したほうが、当事者意識が芽生えます。

WebServerのメモリーやリソースをあまり考慮していないWebアプリケーションを見かけます。
DBから取得したDataTableをViewStateやSession変数に格納して、画面間のやり取りに使っていたりします。
複数レコード(100から1000件単位)を扱い、変更、追加、削除を別のDataTableに保持して、n個のSession変数に格納してあったりします。
しかも1レコード長は1000byteだったりします。 100セッション確立したら、どれくらいリソースを喰うのか不安になります。
「感心しない作りだ」と述べたら、「動いているから、問題ない」。
サーバーでリソース問題が発生しても、アプリの問題ではないという意識が働くのかも知れません。
「目先の製造が楽ならそれでよし」との感じも見え隠れします。
無料サービスや、手軽につかえる機能は、機能に相当する負荷がどこかに掛かっています。
税金天引きと引き替えに納税意識を奪われました。手間や負担をなくすことと、無責任になることは諸刃の剣のように感じます。

VBA構文は不滅かもしれない

Ｏｇｎａｃ — Mon, 17 Nov 2008 00:14:00 GMT

久しぶりにExcel/VBAのソースを弄りました。旧VB系の言語は４、５年前までは、さんざん使っていたのに、.NET系に移行して馴染んでしまうと、綺麗さっぱり忘却するものです。便利機能に接すると不便な面は忘れるのが習性なのかもしれない。
不便な面は忘れて、綺麗な面だけが記憶に残るから、過去を美化する....(脱線しそうなので元に復帰)
Objectの扱いが、如何に不便だったか、改めて感じたしだい。
Excelの画面に TextBoxが貼り付けてあり、入力補助画面を開いて、そのTextBoxに値を戻すという、ありきたりなモノですが、入力画面にTextBox.Objectを渡す部分が、巧く動作しない。
　　入力画面.元CONTROL = 親.TextBox1 　ではコントロールobjectを引き渡しできないのは、朧気ながら覚えていました。
　 set 入力画面.元CONTROL = 親.TextBox1 　で可能だろうとやってみると、TextBox1.valueの内容値しか移らない。
Default propertが働くのだっけ? Setは objectの代入できた筈なのに....
よくよく、思い出すと,, Set Property を作り set 入力画面.元CONTROL = Find.Controls("TextBox1") のような事をした記憶がある。
過去ソースをあぶり出して、確認。そのように実装してました。
　Set構文が必要なのと、Default Proopertが余分な動作してたのですね。今からみると、不思議な記述をしていたものです。
　私の中では、旧VBや VBAは過去のモノと認識しているため、完璧に脳の非活性化領域に追いやられてます。
しかし、現実の現場では、VBAは現役で、ますます、VBAアプリも増産されています。それに伴って、VBAプログラマも育成されています。コンパイラ言語としての旧VBは過去遺物になりつつありますが、 VBAは Officeが残る限り、続きそうな感じ。
　VBAの不便さを感じた分、NET系言語の便利さが余計実感できます。 Framework1.1にも、戻れないのに。
VB6が出てきた当時は、VB4/5と「おさらば」できると喜んでいたのをふと思い出しました。人の思いは留まらないし戻れないと言うことかもしれません。
　当面は、VBAのお仕事にも対応できるようにしておかないといけないのかなぁ。