novtan別館スマートフォン用の表示で見るnovtan別館この広告は、90日以上更新していないブログに表示しています。技術ネタデータベーススペシャリストの午後の問題を見ていると、わりと業務システムなんて簡単にできる気がしてくるんだけど、実際に問題にぶち当たるのは、日本のシステムには厄介なオーダーメイド部分が沢山あって、一般論が通用しないことが多いせいかなあ。問題になる在庫管理システムにしたって原理は簡単なんだけど、実際にはあの取引先には専用の帳票があってとか、この得意先は1営業日すべてのプロセスが早いとか、そういう仕様がたくさんあったりするんですよね。それをもって「顧客の業務」と言ってしまえばその通りなんだけど、それって本当に必要なんだろうか。いう顧客に張り付いているエンジニアは、一般論を知らないことがよくあるんですよね。ここではこうやっている、というのは大事なんだけど、それが、普通はこうやるんだけど、ここではこういう理由があってこうしている、という理解にならないと、よそにいった時に何もわからなくなる。してある業務のスペシャリストとみなされていた人が蓋を開けて見たら使い物にならないのはそんなところに理由があります。それは一般論を身につける、に尽きます。現場から学べることなんてすべてそこ固有の特殊なものだって思っておいた方が良いです。そこで得たものは一般論を理解するために必要なものがたくさんあって、無駄にはなりません。プロセスが特殊であっても業務の目的自体は変わりませんから、理解は早くなるはず。一般論を身につけることで新しい別の現場だけではなく、今の現場にも応用が利くかもしれません。得意先だけ早くするってのは実は全体が早くできるんじゃないか。対応が大変だから取引先には提案してなかったけど実はそんなことないのでは、とか。システム更改のときにプロセスを改善するチャンスですが、個社の事情にこだわっていることでその機会を逸しかねません。僕はずっと金融やってますけど、金融業務は多岐に渡っていて難しい。大まかな業務の概要は金融業務検定で勘所を押さえてみたり、外為みたいなものは入門書を読んだりとかする事で誰が何をどのようにする必要があるのかは大体理解しています。現場で業務知識と言われているのは「Aファイルが第何営業日の何時に送られてきてそれとなんとかマスタを突合して出来たファイルを何営までにBシステムに送る」みたいなの。それって基本設計/詳細設計ですよと。業務プロセスだから、といわれるとはいそうですね。これを業務知識だってほんとうに思っている人はシステムの改善に伴う業務の改善なんて絶対にできないし、多分新しい設計書を書けって言われてもろくなものが書けない。それは業務ではなく手続きなんですよと。手段であって目的そのものではないんですよと。そこを勘違いしている人が「俺は業務を知っている」って威張っているのがレガシーなSIの現場で、そこから脱却できないシステムは10年以内に大変な目に合うことでしょう。おっといけない、エンジニアの話でした。業務を本当に知っているエンジニアってのはシステムと業務をイコールとはみません。システムの都合でプロセスができているところは必ずしも真の業務要件を体現していません。リソースの制約がなければこのシステムはどう改良すべきか、という問いに常に答えられるだけの知識とデザインセンスを持っていること。それが業務プログラマーから業務システムエンジニアへの転換点なんではないでしょうか。品質の定量的評価についてOracleのライセンスコスト問題となぜOracleなのかみずほ銀行システム刷新の再延期に思う大規模システムの難しさ「処罰」が物事を好転させることってあんまないのでは?名寄せって難しいのよね月別アーカイブはてなブログをはじめよう!NOV1975さんは、はてなブログを使っています。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。