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) | アナウンス

再び小石川後楽園デート

今日は久しぶりに奥様と小石川後楽園へ花見に行きました。
枝垂れ桜はさすがにだいぶ散っておりましたが、
まだまだ他の桜はたくさん咲いてました。
久しぶりにデートできてとても楽しかったです。

ぜひともまた一緒に行きたいです。
六義園の枝垂れ桜はもう散ってしまったようですが、
六義園の桜もみたいです。

今年の中野の桜は、まだまだ元気です。
哲学堂まですごいと思いますので、そちらも観に行きたいです。
posted by Kiruahさん at 23:28| Comment(0) | TrackBack(0) | 日記