2011年05月23日

システムの再構築について

大企業のシステム開発において、これまではよく、システムの再構築案件が多くありました。
これからはクラウドを企業が取り入れていくことも多いでしょう。その場合、これまでの基幹業務システムの再構築とは一風変わったシステム開発になるかもしれません。
これからお話しするのは新しいことではなく、むしろ古いシステムの再構築についてです。

システムの再構築においては、現行システムをホストからオープン系に変えることが多いと思います。個人的にはオープン系という言葉はあまり好きではありませんが、ここではオープン系と表現します。

その変更において、オープン系にするのは色々と理由がありますが、多くは運用保守費用の低減があると思います。ホストよりもハードウェアやミドルウェアの制約が少なく、階層型DBのようなシステムの改変がややしにくいものよりも、仕様変更に強いという魅力をSIerは提案しているはずです。
また、その際にSIerは出来る限りの仕様変更を取り入れることも提案していることでしょう。
つまり、この再構築は、現行運用を踏襲しながらもオープン系に切り替えることと、オープン系にした際に合わせて仕様変更を行う2つの目的が含まれています。

話はそれますが、要件定義では要件を決めること以上に大切な事があります。
それは顧客のその案件の目的を明確にし、顧客がそれを理解するということが大切です。
目的が決まっていない案件は、話が収束しません。もし現行の再構築であれば、まずはそれを優先していかなければ、そもそもの目的すら遂行できないことが多いと思います。そして、それがプロジェクトの失敗につながります。
要件定義では顧客からの要求分析結果を元に、顧客の抱える問題からシステム開発を行う目的を明確にすべきなのです。その上で、顧客のビジネス上の効果が表現されます。ただし、このビジネス上の効果は私たちSIerが提案や可能性を考えることはできますが、実現するのはSIerではなく、顧客自身であることも明確に顧客に理解させる必要があります。
1億円で開発したシステムだから1億円以上の利益が出るかどうかは、使う人と使い方次第です。
これは私たちSIerが無責任にシステムを作ることとは無関係で、要は顧客もシステムを作っているという責任があることを示しています。
よって、顧客もシステムを作る上で利益や効率性を考えるのであれば、つまり目的や狙いを達成していくのであれば、顧客自身もシステムを開発する立場に立ち、運用要件や業務用件、性能要件を積極的にSIerに提示し、要件の達成を求めたり、交渉する必要があります。

もう1つ異なる話をします。
目的は2つ以上あると、よく失敗します。それが結果的に同じになる目的であれば1つと見なせるでしょう。2つある目的は必ず方向性の違いや、さらに運が悪いとプロジェクトの方向性を見失わせます。
よって、目的が2つ以上あるのであれば、どちらを優先するのかを1つに絞らなければなりません。
2つあっても必ず優先度を立て、最優先の目的を1つだけに絞らなくてはいけません。
これは出来る限りSIerがあるべき姿を提案できると、素晴らしい提案になることでしょう。業界をよく調査し、その企業をよく勉強し、その企業のためになることを提案しているのでしょうから。。。
ですが、そんなことは大概は難しいどころか、その企業の人間が決めるべきことです。
要件定義フェーズで顧客は、必ず目的を1つに絞ることが求められるべきです。

話の脱線を簡単にまとめると、要は目的をしっかり1つに決めなさいということです。
さてここで、この脱線も踏まえて話に戻ります。


もしシステムの再構築を行いたい場合は、私は2フェーズにプロジェクトを完全に分けるべきだと考えます。
第1フェーズではオープン系に現行を完全に切り替えるという目的を立てます。その切替が運用に乗ったあとに第2フェーズで仕様の変更を取り入れる修正を施すべきです。
これは顧客にとってはビジネスチャンスの喪失も意味することは分かっています。
ですが、多くの場合はこのために顧客は通常よりも暗に多くのリスクを受容させられています。
SIerは必ず現行と新仕様との齟齬を簡単に吸収できないリスクを金額に載せています。そしてその金額は高いものです。
もしオープン系にしているならば、仕様変更は簡単だと言いながらも同時に行うと実は高いケースがほとんどです。
逆に言えば、仕様変更や保守費用が安くなるはずなのに第2フェーズでの開発費用が高いのであれば、そもそもおかしくありませんか?
よって、フェーズを分けた場合と分けない場合のそれぞれについて、顧客はRFPのタイミングでSIerに見積もりを出させるべきです。
おそらくSIerはより多くの条件と縛りを提案書に載せてくるでしょう。
でも、フェーズを分けたならば、最初は現行通りになり、後は運用保守費用が下がる方法なのですから、顧客から見れば縛りも金額も必ず下がらなければ、おかしいと思います。

期間が延長されることはあるでしょうが、運用保守フェーズという位置づけである程度の新機能を吸収できないのであれば、そのオープン系の効果は嘘でしょう。
また、人が必要というのであれば、再構築によりシステムの最適化がおかしくなっているはずです。
さらには、同時に2つの目的を達成するということで、できないと言われる仕様や最初から要件に話が出てきていないじゃないかと言うSIerはおかしいことを言っていると分かります。

私たちSIerはすでに、今までのシステム開発のやり方ではこれからは顧客からは選択されなくなると思います。
それこそクラウド上で簡単にシステム開発できる環境まであります。そうなれば、顧客は時間をかけるよりも内製で済ませるでしょう。

私たちはWin-Winの関係と大きなことを言います。私の会社でも大きく言っています。
でも、もうその関係性のいくつかの嘘を、是正すべき時期に、見直すべき時期になっています。むしろ、これからではもう遅いでしょう。。。



さて、私の会社は生き残れるのでしょうか。。。

2011年05月15日

なんとなく

ちょっと必要になるかもしれませんので、なんとなく作りました。
まだテストも作成していませんし、コメントも記述していませんが、
興味がある方はどうぞ

単純に、Value型に文字列やら日付やら、数値やらを自由に入れられるコンテナです。
あんまり役にはたちませんが。。。
ライセンスは、MITライセンスです。
もしかしたらもっとゆるいのがあれば、そちらに変えるかもしれません。
posted by Kiruahさん at 23:44| Comment(0) | TrackBack(0) | 日記

2011年05月05日

今日は紙婚式

結婚して今日で1年目になりました。紙婚式です。
とても幸せです。これも奥様のおかげです。いつもありがとうございます。

短いようでいろいろとあった1年でした。
とても楽しかったです。それも奥様がいたからです。
これからも幸せにできるよう、ちゃんとしていきたいと思います。

これからもどうぞ、末永くよろしくお願いします。
posted by Kiruahさん at 22:42| Comment(0) | TrackBack(0) | 日記

2011年05月04日

JavaでWebアプリのフレームワークも作ってます

今やWebアプリ向けのフレームワークと言えば、Javaも含めてたくさん出ています。
それはもうたくさん出ており、どれが一番いいかは難しいところです。
結局のところ、一番簡単か、一番最初に使った物がだいたい手に馴染みます。

Javaでもいろいろと出ております。でもJavaの場合はたいがい、
HTMLに対して何かしらの特別なタグを入れたり、HTMLから受け取った情報を格納するためのBeanを作成することが多いのが現状です。
Javascriptも何かしら組み込むことが多いです。たとえ、Javascriptが不要と言われていてもです。

最近の私は、出来る限りHTMLとCSS、JQueryとJQuery経由でAjaxをメインにしてブラウザ上で画面を動的に構築し、Java Webアプリサーバ上ではDBから取得した情報をJSONに変換してブラウザに送るだけみたいな役割分担で、簡単にアプリケーションを作っています。みなさんもだいたい近しい作り方になってきたと思います。もしくは、node.jsやRhinoでサーバでもJavascriptもありでしょう。

これでも個人的にはだいぶ簡単になってきたなぁとか思っていましたが、やっぱり面倒になってきました。
逆にJava Webアプリサーバ上で、Javascriptをブラウザに実行させちゃえというのが、今つくっているものです。
.NET Framework 4にもController.JavaScriptがありますが、これをさらにひどくしたやつだと考えていただければと思います。

正直なところ、実用性はありません。ぶっちゃけ実行させてみると、「うーーん、遅い」と思います。
当然セキュリティのところまでは実装にいたっておりませんので、ほいほいと攻撃できます。
そこら辺のチューンナップはおいおいやるとして、まだ基本実装を充実させているところです。
内部にJQueryを入れてあり、これ経由で実行させます。

サーバ上で、JQueryのSelector(JQueryのセレクタを生成してくれます)オブジェクトを生成してgetすると、ブラウザにJavascriptが送信されて、結果をブラウザ側にキャッシュしてくれます。
で、JQueryでgetした情報(JObjectに入ります)に色々とメソッドが用意されており、append("うさぎさん"); とメソッドを実行すれば、ブラウザに送られて、「うさぎさん」が画面に表示されます。
ついでにタグとか使うと、JQueryの$オブジェクトをキャッシュしてきてくれて、Java側でもそれを使えるJObjectがappendから返却されるので、さらにいろいろとできるようになっています。
(メソッドチェーンみたいな感じ)

ついでに言えば、JavaのクラスとHTMLが一対一で対応するようにしました。
よって、次の画面へ遷移する場合は、forward(new 次の画面のクラス()); みたいにします。
この時、次の画面クラスのコンストラクタとか、setterに色々と情報を前画面からセット出来ます。
HTMLは特別なタグも何も不要で、とりあえず操作したいタグにidを入れておくぐらいです。
別にJQueryなので、idでなくても良いのですけど。。。
SelectorにはJQueryのセレクタをひと通りいれたので、フィルタとかもメソッドがあります。
なので、HTMLには一切Javascriptを実装する必要はありません。

まぁ、こんな感じで作っております。だいたい簡単なチャットは作れるところまで来ました。
ログインしてないのにチャット画面に遷移するとログインにも移動してくれます。

企業のアプリ以前に研究用途にも使えませんが、VBの画面を作るような感じでアプリを作れる感じになってきました。
まぁ、妻は「なにこれ、超作るの簡単じゃん」と言ってくれました。嬉しい限りです。
そのうち公開するかもしれません。

まぁ、あまり興味ある人はいないとは思いますが。。。
posted by Kiruahさん at 14:38| Comment(0) | TrackBack(0) | 日記

2011年05月03日

設計書には業務理由を明記すべき

多くの設計書では、何をすべきかがシステム屋目線で記述されています。
例えば基本設計書、私のローカルな言葉では、「業務機能 機能処理フロー設計」、「業務機能 詳細設計」にあたりますが、これらは全て、なぜそれをしなければならないのか、顧客の業務の理由を明確に記述すべきだと考えます。

理由は主に下記4点です。
1. 顧客が機能の必要性を理解出来ないこともあります。
もしシステム開発に対して積極的な姿勢でない場合、レビューを実施しても疑問も感じずスルーしてしまいがちです。
その後、バグがあったとしても、お互いにレビューした/瑕疵だと強く主張することになります。
そういうリスクはなくなりませんが、多少は顧客にも機能の必要性を理解しやすくしたいと考えています。
2. テスト仕様書を作成する際に、業務上のあり得る/あり得ないも含めてシナリオを作成しやすくなります。
基本設計書フェーズでは結合テストやさらに上位のテストが実施されているはずです。
このタイミングではホワイトボックスやブラックボックスというよりはむしろ、より業務に近いシナリオベースでテストが記述されることも多いと思います。
よって、業務理由が記述されていれば、このシナリオの妥当性が分かりやすくなります。
3. 後任の担当者が理解しやすくなります
後から入ってきた担当者は業務も知らない、何も知らないケースが多く、それなのに担当に割り当てられます。
その際の教育負荷の軽減につながります。
4. 保守業務が多少楽になります。
あとから見たときに、なぜこのような実装になっているかがわかります。
よって、業務が変わっとしても実装の影響等が分かりやすくなります。

設計書への記述としては記述する範囲が狭くなりますが、2段組がベストです。
左に設計、右に関係する業務やなぜこうするのか、業務的な理由、システム的な理由、資料へのリンクや説明や議事録のパスなどが記述されているのが良いと考えます。
こうすると設計に時間がかかると思われます。しかし、その方があとの工程や引き継ぎが楽になります。
posted by Kiruahさん at 09:17| Comment(0) | TrackBack(0) | ノウハウ

2011年04月29日

私が考えているシステム開発の工程

システム開発をしていると、常に運用のことが後回しになっており、
作ってみたけれど、結局使いにくい、運用がまわしにくいと言われてしまうことが多いと感じます。
言い訳ではありますが、私はあまり運用設計まで実施することがないので、
常に最初から案件に関わっていればと思うこともあります。

会社では常に現行システムがあるのであれば、運用がどうなっているのか、性能や環境はどうなのかを
先に調査するよう求めています。
ですが、システムを作る人間は、どうやったらできるのか、どうやって作るのか、システムとはどうあるべきか、
方法論、方式論、開発論、手法ばかりが先行してしまいます。
私たちは作る側ですので、美しく、安く、それなりに品質の高いものをはやく作りたい、
それができれば評価される世界にいます。
たしかにその世界にいるので、上記の論述は必要です。
でもその前に、ちゃんと作ったあとのことを先に考えていたいと思うのです。

私だったらこんなシステム、結局面倒になって使わなくなるだろうなということを感じるものでも、
システム開発側のルールやリスク、場合によってはスキルや作ってしまったから等の理由で
顧客にリリースしてしまいます。
それでも私の会社でも納品さえしてしまえば、Win-Winの関係を築くことができたと言ってしまっています。
これは何を先にやるべきか、あまり明確になっていなからではないかと考えています。

よくあるV字モデルは、
要件定義、基本設計、詳細設計、製造、単体テスト、結合テスト、システムテスト、ユーザー受入テストと
だいたいこのような形で記述されています。
より詳細に見ても、要件定義や基本設計で運用の詳細を見てきた案件が一度もありませんでした。
他の方はもしかしたらやっているのかもしれません。
これは自分の今後のために、反省のためにやるべきことを明確にしていきたいと思います。


まだまだ考え中ではありますが、私が考えているシステム開発の工程は以下の通りです。
一部は詳細に表現しています。
これから、さらに細かく内容を確定していきたいと思います。

第1フェーズ
顧客の現状分析と要求確定
目的定義・実現内容(業務機能・確定可能な非機能)の確定
第2フェーズのスケジューリング

第2フェーズ
現行の運用・環境分析(調査)
実現可能性の分析
実現内容(未確定部分の非機能)の確定
新規 運用内容・運用環境(想定)・保守内容の設計
第3フェーズ以降のスケジューリング

第3フェーズ
業務機能 機能分割
業務機能 機能処理フロー設計
業務機能 詳細設計
開発環境 テスト環境 構築(手順策定)
システム・運用テスト設計
性能テスト設計

第4フェーズ
業務機能 共通処理の抽出
業務機能 機能処理フローをイベントドリブンに変換
フレームワーク設計・実装
新規 移行設計
結合テスト設計

第5フェーズ
フレームワーク テスト
実装
単機能テスト(単体テスト)

第6フェーズ
結合・トランザクション・性能テスト

第7フェーズ
システム・運用確認

第8フェーズ
導入
ユーザ確認


posted by Kiruahさん at 22:17| Comment(0) | TrackBack(0) | ノウハウ

2011年04月25日

システム開発工程

いろんな案件でシステム開発をしています。
どこも似たような感じで工程を踏んでいます。
いろいろな表現があるとは思いますし、間にこまかくあるところもあるでしょうが、概ねこのような感じではないでしょうか。

1. 要件定義 : 顧客の要件を確認する
2. 基本設計 : システムの概略についての設計を顧客に分かる言葉で表現する
この間にフレームワークの選定や開発が始まる
3. 詳細設計 : プログラム内部の設計を行う
この間にフレームワークのテストが始まる
4. 製造 : プログラム開発
5. 単体テスト : 開発したプログラム単品のテスト。だいたい製造と一緒
6. 結合テスト : 複数の機能の連結テスト
機能単位を含める場合や、規模によっては2つに分かれる
7. システムテスト : システム全体を結合してみてテスト
8. 受入テスト : 運用も含めて顧客が要求通りにできているか確認するためのテスト

でも、いつも最後のフェーズでいつも、運用に無理がきたりしています。
そうです、だれも使う人間のことなんて考えていません。
どうやって作るか、実現するか、何をシステムで機能を実現するか考えていますが、
だれがどうやって使うかは最後に決まっていませんか?

だから方式論、方法論、べき論ばかりが先行しているような気がします。
それが悪いわけではありませんが、それは我々SIerの自己満足にしかなりません。
これらは我々が品質をどうやって担保するか、安く作るかです。
もちろん、これは最終的には顧客が支払うお金に関係するためあるにこしたことはありませんし、ないのも悪いとは思います。
でもでも、それよりも本当に顧客のことを考えていますか?

私の妻は運用保守をやっています。話を聞いていて、いつも反省します。
多くのハードウェアベンダー、ソフトウェアベンダーの勝手な方式論でできる/できないという言葉に翻弄されてしまっているように聞こえます。つまり、私たちが本当はできても面倒だとか、我々が楽になるからとかが最終的に見え隠れしています。

結局、使えない、数年後にはさらに保守費を安くしたくなる、結局保守費は変わらない、結局フレームワークや作りがSIer独自で他の企業に頼れなくて縁を切れない、顧客もスキルが育たない状況です。
要は、顧客の無知に付け込んでいるようにいつも私ははたから見えているのです。
食べ物とかで無知に付けこまれて高いものを買わされると文句をいうくせに、いつも顧客との打ち合わせでは「顧客は分からないのだから」と言って、資料を用意したり隠したり。。。。。
本当は作れたものも、こちらの予算が回らなければ平気で「技術的には難しいです」なんてことも言います。
一部上場している大手SIerの全ては同じだと思います。なぜそれがわかるかというと、私の会社もそのひとつでしかも、SI専業でも5本指には入る大手です。。。

今、本当のシステム開発手順はどうあるべきか考えています。
これも完璧ではないとは思います。でも、もっともっと良いものがあると信じています。
こんなことばかり言って私は勝手で無責任の極みだとは思います。
でも、こうあるべきだと多少はよくなるというものを紹介出来ればと思います。
posted by Kiruahさん at 21:00| Comment(0) | TrackBack(0) | ノウハウ

2011年04月24日

Win-Winの関係

私の会社でも要件定義から保守運用まで行っています。
でも、今関わっている案件を踏まえて、確かに我社は利益を出せている案件もあります、一般的に言われるWin-Winの関係を顧客と築くこともできているかもしれません。
ただ、少なくとも私が今まで関わった案件は本当の意味でWin-Winだったのかなと感じます。

システムを作る人間は、次の段階を踏んで成長しているように思います。
第1段階 : とりあえず動くものを作る
第2段階 : システムはどうやったら動くかを考える
第3段階 : システムとはどうあるべきかを考える
第4段階 : 顧客にとってシステム開発はどうあるべきか考える
第5段階 : 方式論、方法論までシステム開発を昇華する

自分もずっとこんな考え方で、システムを技術的にどうすればよいかとか、システムはこうだと使いやすいとか、それを先に考えたりしていました。

我々SIerが言うWin-Winってきっと、本当は納品時点でのことかなと思います。もしくは、SIerにとってもっとおいしいWin-Winの形態って、運用保守までをそのSIerが担当することなんだと思います。
それは当然ビジネスなので当たり前なのかと思います。要はビジネスはどうやってお金を稼いでいくかにつながっています。Win-Winでありながらも自社にお金が継続的に入るビジネスモデルはありがたく、かつ利益の計算もしやすいものですし、顧客もアウトソーシングとまでは行かなくても、保険と同じようなものです。

これは決してWin-Winではなかった案件だと思いますが、私はたった一度だけ、要件定義から保守フェーズまで一貫して案件に関係したことがあります。
B2Cの案件で、開発はそこまで運用までは考えていませんでしたが、システムを作る人間以外が新しく何か画面を作るとき、本当に何も考えなくても作れるようにしてしまいました。
画面上のあらゆるものが部品化され、その部品すらも複数が部品化され、さらにそれが画面レベルまできたとしても画面までも部品化されていました。似たような画面を作るとき、その画面を継承して、ちょっと文言の定義を変更して、入力欄が違っても、画面でちょっと部品を追加すると、バリデーションチェックまでできます。
業務ロジックもパラメータが可変で、入力数は可変でもしっかり関連チェックされ、DBのモデルも可変であることを考慮していました。性能面もセキュリティも考慮したりもしていますが、新規で作る人は考えなくてもよっぽど変なことを無理やりしない限りは問題が発生しないようになっていました。
当然、システム開発においてここまで作り込めたらなかなかな気がします。

そして、最終的にはかなりの利益になった案件です。かなりの成功になりました。しかも、カットオーバーも問題なく、運用もほぼ問題なく進みました。そして客観的に見て使いやすさや品質もよく、顧客は満足しておりました。おそらくここまではSIerで言うところのWin-Winだったのかもしれません。

その後、どうやって作ったのか顧客から教えてほしいという話題になりました。
うちの営業は「抗議してもいいですよ」と言ってましたので、事前に上司に講義内容を決め、資料もOKをもらったあと、私が顧客の技術部門に数回講義しました。
日本人ではありませんでしたが、たった数回の講義、1回1時間の講義で彼らはプログラムもできたので、新規に画面が顧客からの要望案件がありましたが、彼らが1日で作ってしまいました。テストも1日ちょっとでした。要は、私たちが作ると営業から「10日はかかりますね〜」と持ちかけたけれど、実際は2日で作れてしまいました。

その後、その案件に関しては彼らは「自分たちで運用でき、新規の開発もできますので、御社からのサポートは不要ですよ」、と通知が来ました。もし新規案件が他にあればということで、並行で動いていた新規案件がありましたが、以降は大きな案件は発生しませんでした。

でも、もし難しくつくっていれば、彼らは自分たちで運用保守できなかったかもしれません。そうすれば、私たちに依頼が来たかもしれません。そうしたら、彼らは自社で作るよりもお金がかかったかもしれません。
では、彼らは自社で作るよりも他社に依頼したほうが安かったのか、私たちは簡単に作れるようにすべきだったのか、難しく作るべきだったのか。それとも顧客にはどんなことがあっても講義しないほうがよかったのか、それとも講義すべきだったのか、それとも中途半端な内容がよかったのか。


いったい、どれがWin-Winの関係になったのでしょうか。。。

私はWin-Winなんか考えるんじゃなく、顧客が真に使うシステム、いやいやではなく使い続けてもらえるシステムを作りたいです。

2011年04月11日

MS-Access バージョン管理ツール Ver 0.1.4

今日は急遽バグを修正しました。が、
明日早いのであんまりテストできていないです。

一応人柱上げです。明日テストしてみます。
急遽必要でダウンロード出来るようにしています。

ダウンロードはこちらからです。

もし問題があればすぐに修正し、新しいバージョンをアップします。
※ とはいえ、明日夜から仕事で打ち合わせが。。。

すみませんが、よろしくお願いします。
posted by Kiruahさん at 23:15| Comment(0) | TrackBack(0) | アナウンス

2011年04月10日

MS-Access バージョン管理ツール Ver 0.1.3

今日はもう一件。

MS-Accessのバージョン管理ツールをバージョンアップしました。
ダウンロードはこちらからです。

まれに検索結果で古いページのみ見て、
古いバージョンをダウンロードしている方がおり、
最新が分かりにくいなぁと反省しております。

しっかりとしたページを作ります。
それまですみませんが、ブログにての通知でよろしくお願いします。
古いリンクも最新が落ちるように修正しました。
posted by Kiruahさん at 23:33| Comment(0) | TrackBack(0) | アナウンス