メイン

間違いだらけの業務システム開発 アーカイブ

2010年8月 2日

間違いだらけの業務システム開発-はじめに

このブログを書き出したのが、2006年8月からなので4年間書いたことになる。その中でITについての記事がおおよそ3分の1を占める。いまこの間に書いたものを振り返ると現状で問題があることを繰り返し述べていて、それを変えていかなくてはいけないという主張に染まっている。

ということは、いま行われている業務システム開発と呼ばれるものは間違っていると言っているに等しい。いやちゃんとやっているという人もいると思うが、概して問題ありと感じている人の方が多いと思う。そこで、これまで書いてきたものが主で新しい指摘は少ないかもしれないが、「間違いだらけの業務システム開発」と題して、様々な角度から常識を疑う目をもって考えてみたいと思う。

はじめに指摘すべき最も重要かつ基本的な問題は、ビジネスありき、事業ありきというベースが欠如しているということを挙げておきたい。何も考えていないわけでもないだろうから、欠如というと言い過ぎかもしれないので、そういう意識が薄いとでもしておく。

ビジネスありき、事業ありきは当たり前でしょうとみなさん言うと思いますが、ほんとうにできていますかということです。頭の片隅においておくだけじゃ何もならなくて、開発プロジェクトの目的にしても、開発方法論にしても、この考え方を取りこんだものになっているかということである。少なくとも現実のビジネスの実相を反映したものにおちているとは言い難いと思う。

この根本的な立ち位置が間違っている可能性がある。「役に立たない正しいシステム」を作り続けてはいないだろうか。ビジネス上のメリットを生み出しているのだろうか、事業に貢献できているのだろうかが問われなければいけない。先進の技術を使うことで終わっていないだろうか、はやりのクラウドにすればやることはやったと思っていやしないだろうか。

ビジネス上のメリットを生み出す、あるいは事業に貢献するためにはどういう仕組みが必要なのかと考えたとき、最初に浮かぶものはITシステムではないということを肝に銘じなければいけません。極端な例でいえば、起業してすぐのベンチャーで商品がバカ売れしているような場合に、社長一人で全部やれているうちはそれが最良なシステムかもしれないのだ。

ということで、いちばん最初の間違いは、システム化の必要なあるいはシステム化を検討する場合の立ち位置である。ITだけの導入が前提ではなく、その会社の事情(規模や成熟度といってもいいかもしれない)によって、ビジネス上のメリットや事業に貢献できるにはどのようなシステムが必要なのかという思考アプローチが肝要なのに、何でもITシステムを入れればいいのだというスタンスのことである。

次回からは個別の局面における間違いについて考察していきます。

2010年8月 4日

間違いだらけの業務システム開発(プロジェクト編その1)

システム化プロジェクトは開発するもの

前回は、はなからITシステムを入れるということではなく、それぞれの会社の事情や成熟度に応じて、場合によってはITを使わないでシステム化をする方がいいケースもあるというようなことを書いた。ここでは、システム化プロジェクトで開発をしてしまうという間違いについての話です。

こう言うと、怪訝な顔をする人も多いと思います。だれしもが、普通に”システム開発“と言います。しかし、業務アプリケーションのことでいえば、業務の仕組みを開発するのですかとツッコミたくなる。ソフトウエアやツールであれば確かに開発ですが、業務の場合、開発するとはいったいどういうことなのだろうか。

そのまま字句通りに解釈すると、業務の仕組みあるいは業務プロセスをそうしたプロジェクトで開発すなわち新たに作り出すことを意味する。そんなことをシステム化プロジェクトでやるんですか。そもそも何とか管理システムの開発プロジェクトというような言い方がおかしい。いや、今までと違うプロセスや機能を盛り込んでいくからやはり開発でしょうと反論がくる。

しかし、よく考えてみてください。そんなことをITベンダーと一緒にやりますか。ここには二つの感違いがある。一つは、業務プロセスはITプロジェクトとは関係なしにビジネスサイドで開発しておくものであるということです。しかも、どこの会社にも業務プロセスはすでにあって(もちろん手作業でやっていたとしてもプロセスです)、それを事業という観点で変えていくわけです。新しいビジネスモデルの創出ということです。

もうひとつは、IT側で業務の仕組みを“開発”してしまうこともあるということです。これは最新の機能を盛り込んだ営業システムですからそれに変えた方がいいですよとなる。別に現状業務を分析してこうしたほうがいいという結果がでていなくても、カッコよくこれはベストプラクティスですからとか言って変えてしまうのです。

ですから、システム開発ではなくシステム構築の方がなじむように思います。家を建てるときでも、家を開発するとは言わないで建築するというのと同じです。このことは、そんなに厳密なことを言わなくてもいいじゃないか思うひともかなりいるかもしれませんが、思った以上に影響があると言いたいのである。

システム化のプロジェクトに入ったら開発してはいけないのだ。家を建てるのと同じように、ユーザの活動スタイルにあわせて設計されたものをそのとおりに組み上げるというのが望ましい姿である。へたに開発しようとするから、仕様変更が、そして手戻りがおきるのである。
  

2010年8月 9日

間違いだらけの業務システム開発(プロジェクト編その2)

開発プロジェクトではコードを書く

前回、開発プロジェクトではなく構築プロジェクトの方がなじむというような話をしましたが、ここではまだ開発プロジェクトという言い方にしますが、そうしたプロジェクトでは、ウォーターフォール型であろうが、アジャイルであろうが、みな一生懸命コードを書きます。前者のスタイルでは大勢のプログラマーを抱えて、せっせとコーディングをします。

おそらく、この瞬間でも世界中で言語は違えど同じコードをかきまくっていることでしょう。これはどう考えてもおかしいと思いませんか。なぜこんなことがおきているのだろうか。

ひとつには、ITベンダー側の事情がある。人月でこなすビジネスが染みついているため、そしてそのための多くのプログラマーを抱えてしまっていることがあって、それをプロジェクトではコードを書かないでいいですよとなったら大混乱になるからである。もしわかったとしてもできないのだ。

しかし、これはユーザからみたら困ったもので、本来なら短納期、低コストでできるシステム開発がベンダー側の事情でユーザに負担を強いている構図となっている。ユーザも薄々はわかっていると思うのだが、ITは専門的なものだからしかたないとあきらめている面がある。

前回も家を建てることを引合いに出したが(クルマの生産と比肩するより、家の建築の方が類似していると思う)、家の建築現場では普通そこで柱や窓枠を作っているわけでもないし、部屋の位置や大きさを変えることはしない。設計どおりなるように調整はするが、その程度である。

それと同じように、システム開発も設計ができたら、原則コードを書かない、もちろん多少のコーディングは要るが、それは例えば現場あわせのインターフェースのところだけとかにすべきである。そのために、モジュール化やコンポーネント化、各種フレームワークの活用などで対処できるようにすべきなのである。

そんなもの、ユーザによってシステムの中味が千差万別だから絶対無理だという人がいます。しかし、その千差をコードで書く必要がありますか、万別というがよくよく見ると共通的なものになってやしないですか。

ぜひ、開発プロジェクトではできるだけコードを書かないようにするためにはどうしたらいいのかをよく考えてもらいたいのです。コードを書くから開発に時間がかかるし、テストが大変だし、バグも出るし、変更に手間取るしというふうにいいことは何もないのである。
  

2010年8月10日

間違いだらけの業務システム開発(プロジェクト編その4)

正しいシステムを作ることがゴールである

この“正しい“という意味をちゃんと定義しなくてはいけないのだが、これも一見”正しい“ように思えます。ここには二つの間違いが潜んでいます。その正しいののは誰にとって正しいのかということと、作ることが目的なのかということである。

前者の誰のために正しいかについては、往々にして作り手側すなわち開発ベンダーや開発者にとってではないでしょうか。データベースの設計は技術基準にしたがってやりました、コードは社内のコード標準であり、プロジェクト管理はPMBOKに則りやりましたとなる。

そして、ユーザの要求からシステム要件に落としてその通りに開発をして、テストでも問題ないことを確認しましたである。ここには、そのシステムが役に立つものであるのか、ビジネス要求に応えるものであるのか、事業に貢献できるもにになっているのかという視点がないのである。だから、正しいではなく役に立つシステムを作らなくてはいけないということである。

次に、ゴールですが、今の話にもあったように、役に立たない正しいシステムを作ったって何もならないのはお分かりだと思います。それと何といってシステムというのは、それが動いてこそ効果を生み出すわけですから、作って終わりではないのです。

ところが、プロジェクトの終わりはシステムが稼働してすぐに解散です。まあそれでもいいのですが、ビジネスにおける成果をみる、もっと言えば継続的に事業貢献ができることを確認していくことがシステムに要求されていることです。

まあ、現実的にはずっとプロジェクトを継続するわけにはいかないでしょうから、開発が終わって本番が稼働してという段階で終わらすのでしょうが、どうも今のやり方では非常に大がかりな開発プロジェクトを立ち上げるくせに、戦略やビジネスモデルの立案とか、稼働後のパフォーマンス確認、向上といったフェーズに対する傾斜が弱いということを指摘したいのである。

なぜそういうことが起きているかというとあまりにも開発に時間とリソースをかけ過ぎるという側面もあるように思う。これからは、システムの開発はごく簡単にすませ、もっと戦略的なところや、オペレーショナルなところの重要性を自覚してプロジェクトを運営していくことが大切なことではないでしょうか。
  
システム開発は、”正しいシステムを作ること”ではなく、”役に立つシステムを正しく作ること”でなくてはいけないのです。ここを間違ってはいけません。
  


  

2010年8月11日

間違いだらけの業務システム開発(プロジェクト編その3)

申し訳ありません、「プロジェクト編その3」を抜かしてしまいました。順序が逆になりましたが、掲載します。

ユーザが仕様を早く決めてくれないから開発期間が長くなる

これが間違いっておかしいでしょとみなさん言うと思います。たしかに、開発プロジェクトでは、ユーザがなかなか仕様を決めてくれないために仕方なしに見切りで進めていって、あとでひっくり返されるという痛い目にあっているからそう思われるのでしょう。

私の経験上でもよくあったことですが、まず最初にユーザの担当者を決めてもらうのですが、だいたいにおいてキーパーソンは出てきません。キーパーソンと言うのは文字通り軸になっている人ですから、本来の業務が忙しくて、そんなプロジェクトに関わっていられないというわけである。

これもよく考えるとおかしな話なのですが、日本の企業の開発プロジェクトでよくある話である。従って、担当者は新人であったり、ひまな人がアサインされたりします。そんな状態ですから、仕様なんて決まったようで決まっていません。最後の方の、さあもうすぐ本番だから運用のテストをしようなんて頃になって、キーパーソン登場です。

こんなんじゃダメだとなり、仕様変更です。そしてあわてて変更開発をして、それが原因で不具合発生です。ですから、タイトルの意味は正しいのです。しかし、よく考えてください。ユーザが早めに仕様を決めてくれば解決するのでしょうか。というか、ユーザはどんなシステムができ、どう動くかもわからない段階で仕様をびしっと決められるものなのでしょうか。

私はユーザの立場に長いこといましたから言えるのは、仕様はきちっと最初に確定はできません。何となくこうしたいでは決まらないし、これでやると決めても技術的に無理だなんてこともあるわけです。ということは、無理なことを言っているのです。つまり、ユーザは仕様をなかなか決めてくれないという前提でプロジェクトを進めるべきだと思うのです。

そのために必要なことは何でしょうか。早い段階で動くシステムを見せてやることではないでしょうか。この早いというのは2つ意味があって、ひとつは開発の初期段階でプロトタイプがあるということと、もうひとつはユーザから要求が出たらすぐに実現してあげることです。

現在の開発ではアジャイルが増えてきましたが、まだまだ、仕様を固めて、それから時間をかけてコードを書いて、できたころには最初の仕様は何だったっけみたいな話になる。これじゃあ、ユーザだって最初から真剣になりません。尻に火がついてからでいいやとなってしまうのです。ぜひ、ユーザのせいにしないでユーザが本気になるやり方を考えてもらいたいのです。

2010年8月15日

システム開発プロジェクトの成功とは

いま、「間違いだらけの業務システム開発」ということで連載しているが、開発プロジェクトがうまくいったのか、そうでなかったのかという実態がどうなっているのかを知ることも参考になると思う。

いささか古いので恐縮ですが、日経コンピュータの2008年に行われた「第2回プロジェクト実態調査」ではシステム開発プロジェクトの成功率が31.1%だったという報告がある。その5年前の第1回の結果が26.7%だから、さほど向上していない、まあ同じようなものだ。大方7割のプロジェクトが失敗だったという。

ところで、ここでいうプロジェクトの成功率とは「Q(Quality)、C(Cost)、D(Delivery)」、すなわちシステムの「品質」「コスト」「納期」の3点について当初の計画を順守できたかどうかを尋ね、品質、コスト、納期の3基準すべてで「当初計画通りの成果」を収めたプロジェクトだけを「成功」と定義している。けっこうハードルが高い基準だ。

ただ、これも少々誤解がありそうだ。つまり、システムをつくることをゴールにしているからである。「品質」にどれだけビジネスへの貢献度を加味できているのかがよくわからないので軽々には言えないが、「当初計画通りの品質」というのが微妙である。それ以上に、品質の定義も問題である。

というのも、「当初計画通りの品質」が開発プロジェクトでできるかどうかで、おそらくそれは無理であろうと思う。実際にそのシステムでオペレーションしていくうちにブラッシュアップされて、「当初計画通りの品質」が達成できるではないだだろうか。

ただし、それで終わりではないはずで、求められる品質は日々変化しているわけで、そうなると「当初計画通りの品質」を達成することがゴールではない。その時々でビジネスの要求に応えられる最適な品質を継続的に実現していることが究極のゴールになるでしょう。

さらに、この調査で驚いたのは、5年間でほとんど成功率の向上がみられなかったことである。この間、失敗しないためのプロジェクト管理とかいって、様々な手法や技術が提示されたはずである。それがなにも生かされていないということを意味する。というより、すばらしい手法や技術が有効ではなかったことを意味している。

それはなぜだろうか。プロジェクト管理手法や技術は進歩し、人のスキルも向上したのになぜなのだろうか。答えは、変われていないものがあるからである。作っている業務システムの構造が旧来のものと同じだからである。これは、このブログでも再三指摘したことである。

作っているものが従前から、見てくれではなくて、中味が本質的に進化していなかったら、いくら先進的な技術や開発方法で作ったところで同じことを繰り返すだけなのだ。昔から作られている業務システムは構造的に開発に失敗する要素を素性として内在しているのだ。これが、根源的な問題である。

だから、この構造問題を解決しない限り、次の5年後の2013年に調査しても同じ結果になるのではないだろうか。
  

2010年8月17日

間違いだらけの業務システム開発(企画・設計編その2)

戦略立案からトップダウンで設計すべきだ

これは、間違いというより、それだけではないという意味です。システム開発の教科書には(ただし、あまり読んだことはないが)、内外部の環境の分析をして、強み弱みを抽出して、バランススコアカードで評価し、CSFやKPIを設定し、戦略、ビジネス要求を練ることが大事であるとなっているようだ。これを要求分析とか要求開発という。

そして、そこからどういう業務システムにしたらいいのかというアプローチで、それは全く正しいのですが、何でもかんでもそうしたアプローチなのかということと、これも何度も言っているのだが、その受け皿となる業務システムの構造がちゃんと対応できているのかという問題を指摘したい。

単なるデータ登録、帳票出力システムでしかなかったらどうなるでしょうか。一生懸命上流の分析、設計をやったとしても徒労に終わることってあるのではないでしょうか。その戦略やビジネスモデルをどうやってシステムに落としていくのかがわからないのです。

プロジェクトの初期で、うちのこの事業の戦略はこうで、そのためのビジネスモデルはこうして、管理するKPIやパフォーマンスはこれこれにしようと決めます。ところが、最初に決めたビジネスモデルがどう実現できているかが見えるような仕組みになっているでしょうか。一生懸命頭を絞って考えたKPIやパフォーマンスのデータがきちんと取れてそれが解析できるようになっているでしょうか。

よく考えてほしいのは、実際にオペレーションする仕組みが上流分析・設計と連動したものでないと意味ががないということです。どうも日本の業務システム開発の現場ではこのことの重要さを理解していないように思うのです。

ですから、もしちゃんと上流分析・設計の結果を表現できる一貫化された、連動性のあるプラットフォームができれば、何も上から下に降ろさなくても、下から上へ要求を出すボトムアップアプローチだってかまわないケースもでてきます。それもそうだし、例えば、顧客の要求に応えるようなサービスプロセスなんては、そんなに戦略的な要素が必要ではないので、すぐに設計に入ってもいいわけです。

つまり、業務プロセスの構造が、ビジネスモデルを実装できるようになっていれば、そこの必要機能を埋めていくことで、あたかも上流設計を行ったように実装できるはずです。似たようなものに、インタビューシートに従って質問していくと、自然とビジネスモデルができていくというようなことがあります。白紙のプロセスの構成要素を色づけていくといった作業で設計することです。

ですから、理想的には上からと下からの両方から攻めるハイブリッド型アプローチが一番かもしれませんね。ハイブリッドばやりなのでそんなアプローチをしてみたらいかがでしょうか。ただし、しつこいようですがボトムアップアプローチが確立していないとだめです。そこを抜きにしたトップダウンアプローチでは、間違いとまでは言いませんが有効性を失っていると言わざるをえないと言っているわけです。
  

2010年8月19日

間違いだらけの業務システム開発(企画・設計編その2)

目的を明確化することが重要だ

どんなことでも目的を明確化するということは大事なことです。だが、あえてここでそれは間違いであると言っているのは、システム開発における、もうすこし具体的なそこで作るシステムの目的の明確化について言っています。

陥りやすい過ちは、作ろうとしているシステムがどんなシステム機能をもって、どんなシステム構造にするかということをシステム開発の目的としてしまうことです。少々分かりずらいかもしれませんが、別な言い方をすると手段を目的化してしまうことです。何をつくるかのというWhatを目的にしていまい、Whyを忘れてしまうのです。

目的を明確化しましょうというと、ついこうした間違いを犯すことになりかねません。ですから、こうした場合は、目的合致性とか合目的性をチェックしましょうと言った方がいいと思います。つまり、このシステム開発は本来の目的に合致しているのかということを問うのです。

こうすることによって手段の目的化の過ちがなくなり、正しく目的を達成するための手段はどうしたらいいのかという思考回路になるというわけである。そうなるとお分かりのように、決してIT化するとか、ソフトを導入するとかが全面的な解決策ではないのです。

その会社や組織の能力や成熟度でやり方やシステム形態が変わってもいいのであって、身の丈にあったシステム化が重要であるということは何度も書いてきました。目的のすり替えがあると立派な仕組みを作ったはいいが使いこなせない“猫に小判”システムができあがるわけです。

ここであえて説明するほどではないかもしれませんが、システム開発の目的は、ビジネスあるいは事業に貢献できるかの一点です。どうもこの目的の設定の間違いが無意識のうちにあるような気がします。気をつけたいものです。

2010年8月24日

間違いだらけの業務システム開発(企画・設計篇その3)

設計は厳密な設計手法や手順で行わなければならない

普通設計というと、設計法とか設計手順というのだが、どうもそれだとやり方はこうしなくてはいけないという響きがあり、決まりきったものとしてあいまいさが許されないように思えます。ところが、業務プロセス設計の場合、こうでなくてはいけないという厳密なやり方は似合わないような気がします。

その理由は、設計の対象となるシステムは人間が行うものだからではないでしょうか。機械がするのならきちっと決めておかないとうまく動きませんが、逆に人間のやることはある程度の裁量の幅みたいなものを残ししておいたほうがよいように思うのです。

従来のシステム設計では、対象がコンピュータだったので、コンピュータにやらせることを厳密に定義することが大事でした。しかし、人間主体のシステムと考えると、もっと緩くこんな感じでやるといったものの方がなじむのではないでしょうか。IT主体から人間主体へシステムの形態が変化するということは、設計の考え方も変えていかなくてはいけないのです。

そこで言っているのが“作法”ということでです。では、作法っていったいどういうものなのでしょうか。茶道なんかでも作法といいますが、その作法は流派で違ってきます。裏千家、表千家、武者小路千家とあるそうですが、それぞれで作法が違うようです。作法とはそういうもので、ただし、それぞれ枝葉のところでは違っても、幹のところでは共通の“芯”を持っています。茶道でも、落ち着いた心でお茶を楽しもうという精神は各流派とも共通です。

さて、業務プロセス設計における作法のことです。先ほど言ったように人間主体の業務プロセスはきちんとし論理的なモデルにはなりません。だからといって、“なあなあ”のプロセスでも困ります。ある程度の約束事があるべきです。言い方を変えると、約束できるレベルでプロセスを書き出すということです。

業務プロセス設計のように何かを集団でやろうとしたときに、ばらばらにならないように秩序を維持する必要がありますが、そのとき作法が生きてきます。なぜ有効かというと、作法は「型」ですから、メンバーがその型を習得していれば、誰がやってもだいたい同じものができるということなのです。

そこは、技法や手順も同じでしょうという指摘があるかと思いますが、作法は覚えることが少ないこと、それも頭ではなく身体で覚える感覚に近い感じでやれることではないでしょうか。知識として多くのことを学ばなければいけないという方法論は限界があるように思います。シンプルにシンプルにです。ということで何が何でも厳密にやる必要がないことを感じてほしいと思います。


2010年8月25日

間違いだらけの業務システム開発(構造・機能篇その1)

IT化とは機械化、自動化することである

コンピュータが登場した初期のころは、まさに計算機の導入という意味で機械化、自動化が図られた。人間のやっていることを機械にまかせ、大量の処理を早くやらせることで効果を出していた。

しかしながら、こうしたITは一部の計算とかルーティンの処理だけではなく、もっといろいろなことができるようになってきました。そうなると単純なものから人間が考えることだとか、感じること、意思といった領域に入り込むようになりました。

AI(人工知能)もそういったものであったわけです。ところが、そんなに人間は簡単なものではないので、機械化、自動化の延長では限界があることがわかってきました。つまり、人間の考えることややっていることは複雑で恣意的で臨機応変で、それはコンピュータでは無理なのです。

コンピュータ登場以前の仕事は全部人間がやっていたわけです。そのうちのそろばんや電卓でやっていたことや伝票を集めていたようなことをコンピュータが代替するまではよいのですが、机の上で会話しながらとか電話で段取りをするとか、誰かに問い合わせるとかしながら意思決定をすることまでは無理なのです。

当たり前のように、こうしたことは人間が主体となってやるような仕事です。この部分は機械化、自動化はできないと言っているのです。しかしながら、ここで誤解しないでほしいのは、IT化するなと言っているわけではないということです。おわかりでしょうか、むしろ複雑で恣意的で臨機応変の業務処理でも、機械化、自動化はできないが、別の意味でのIT化をしたらいいと思っています。

そこを取り違えると、どこやらの大きなベンダーが、ビジネスプロセスオートメーションなんて概念を提案するというばかなことを言ってしまう。ビジネスプロセスが自動的にぼんぼん進んでしまう世界はどんなに気持ち悪いか想像したことがあるのだろうか。

この辺はなかなか理解できないかもしれませんが、いまの若い人たちのITの使い方を見ていたらわかると思います。スイスイと友だちとの会話、あるいは協働作業やコミュニティ活動などを行っています。ITという道具を使いこなしている姿です。

ネット上のある空間に仲間が集まってきて、同じ目的のためにコミュケーションをとったり、コラボレーションを行ったりするソーシャルネットワークです。これは、ITがそうした“場”を提供しているのです。こうしたスタイルはなぜ企業のシステムの中に入ってこないのでしょうか。

このような“場”の提供だけでも立派なIT化だと思っています。昔は誰かの机のまわりに集まってワイワイやっていたことをもっとオープンにそしてもっと多くの有用情報を参照しながらやれたらいいなあと思うのです。今のITはそれができるはずです。
  

2010年8月30日

間違いだらけの業務システム開発(構造・機能篇その2)

業務は各社様々なのでパターン化、共通化、標準化できない

この表現も間違っているともいえるし正しいともいえる。業務の粒度、プロセスのレベルによって違うということである。どういうことかというと、業務プロセスの固有性はどんなところに現れるかということに関連している。つまり、固有性が出てくるようなところではパターン化、共通化、標準化は難しいが、そうでないところでは可能であるということです。

その辺をもう少し考えてみましょう。固有性というものはいったい何でしょうか。それはいい意味でも悪い意味でもあります。ただ、悪い意味での固有性はその会社にとって弊害になりますし、そんなものをパターン化しても始まらないわけで、これは除外しましょう。いい意味での固有性を考えます。

いい意味の固有性は、別の言い方をすると差別化要素であり競争優位の源泉であるわけです。そう考えると、各プロセスレベルでありそうですね。まずは、上流では戦略こそそれにあたります。この戦略はまだ文脈的ですから、それをもう少しロジカルなものに落とし込んだビジネスモデルが、差別化のための固有性を発現しています。

一方、下流に降りてくるとどうでしょうか。そうなると、業務を行っている個人的なレベルになってきます。すなわち、最終的な業務処理における従業員個々人のスキルや意欲であったり、組織の文化・風土であったり、取引先との関係性だったりが、その会社の固有性を発揮することになります。

ところで、この両者の間には何があるのでしょうか。それは業務プロセスです。正確に言うと、狭義の業務プロセス、すなわち比較的抽象度の高いレベルでのプロセスフロー構造とそのオペレーションではないでしょうか。ここの部分はおそらくどんな会社でも基本的には同じことをやっていると思うのです。

ここで、狭義の業務プロセスと言いましたが、では広義の業務プロセスは何が拡張要素何のでしょうか。それは、ルールマネジメント、リソース管理、ロール設定などです。いまあげたようなことは、重要な機能ですが、そうした機能があるのかどうかというより、具体的な値をどこに設定しているかといったところに差別化要素が入り込みます。ですから、狭義の意味にしたわけです。

ということで、狭義の業務プロセスは、会社や業種が違ってもパターン化、共通化、標準化できると考えています。ここがなかなか理解してもらえないところで、うちの業務プロセスは特殊だと言われたりします。こういう場合は、いったいどこが特殊なのかレベルを分けて吟味したほうがよさそうですね。

こういうところに業務プロセスを書いてもらうと、あっちへ行ったりこっちへ行ったりの複雑で冗長的なフローを書くものです。ぜひ、パターン化、共通化、標準化できるレベルがあって、それができると、このプロセスを核として、上流の差異、下流でのこだわりを付加するというアプローチがとれ、わかりやすい構造になるというのをわかってほしいと思うのです。
  

2010年9月 1日

間違いだらけの業務システム開発(開発篇その1)

自動プログラミングは有効である

通常、業務システムの開発というと最終的には、プログラマーを配置してプログラム仕様書に従ってせっせとコードを書くことが行われます。このシリーズ初めの方でも、「開発プロジェクトではコードを書く」というのが間違っていると指摘していて、コードを書かないようにすることが重要だと言いました。

ところが、一方でプログラミングを自動化すればコードを書いてもいいのではないかという議論があります。というか、コードを書くという前提でその生産性をあげるために何とか自動化したいという思いがあり、現にそういうツールも出てきています。

これは正しい方向でしょうか。それを考える時に、いつ、どこの部分でコードを書くのかをみてみましょう。今の開発プロジェクトだと要件定義して仕様におとして、最後にプログラミングをします。詳細な機能レベルも記述したりします。

こうした、細かな機能レベルのものは予めコードを書いてモジュール化、部品化しておいたらどうなるでしょうか。そして、プロジェクトに入ったらそれらの部品を組み上げることにしたら、そこではコードを書かないですむことになります。

もし、こうしたことができたら、プログラムの自動生成というのはどういうことになるのでしょうか。自動化の意味がなくなるのです。なぜなら、自動化をする必要性は同じようなコードを繰り返し書くからで、言い換えると、パターン化できるから自動化が可能になるわけです。だとしたら、パターン化できるのならそれらを部品化してしまえばいいことになる。

そうなると、その部品を作るのにコードを書くことになります。ここはプログラミングしなくてはいけません。ところが、このプログラミングは一回でいいのです。ですから、ここはじっくりとスーパープログラマーにきれいなコードを書いてもらおうじゃありませんか。

いまのアプリケーションのコードを覗いてみたらいいと思いますが、ほとんどが個人の癖の入ったきたない、あとで読めないしろものではないでしょうか。たとえ、自動化したところで、自動化のアルゴリズムは汎用性を持たすために質はそう高くないと思われるので、同じような話ではないかと思います。

結局、スキルの高いプログラマーにシンプルできれいなコードで部品を作ってもらい、それを要求に従って組み上げることでアプリケーションを構築するのが、開発効率、そして保守性も向上させることができるのです。ということでプログラミングの自動化を指向するのは間違っていると思うのですがいかがでしょうか。
  

2010年9月 7日

間違いだらけの業務システム開発(開発篇その2)

これからはアジャイル開発だ

エンタープライズ系のシステムもウォーターフォール型の開発からアジャイル型に転換していこうという風になっているようだ。たしかに、従来のウォーターフォール型の開発では、開発期間が長く、仕様の変更に弱かったりといった問題が指摘されてはいたが、それがすんなりとアジャイルに変わるのかというとなかなか難しいように思う。

ただ、ウォーターフォールを続けるわけにもいかないので何らかの開発手法を持つ必要があるのは確かだと思う。それがいまのアジャイルかというと、そう詳しく知っているわけではないが違うような気がする。

少なくとも、ソフトウエアの開発にはアジャイルは向いていると思う。業務アプリではなくプロダクトを開発するような場合には、少ない人数で効率的なイテレーションで作り上げるというのが合っているし、実績的にも多くあると思う。

ところが、業務アプリケーションのような場合、従来型の要件仕様に従ってコードを書かなければいけない時、そんなことをやってられるのかという問題がある。おそらく、変化に対応できるのがアジャイルですよという謳い文句があだとなるのではないでしょうか。

いくらたっても決まらない、適当に切り上げるが、あとでどうしてこうなったかもわからないといった破目に陥りそうである。アジャイルは、作るものがある程度明確になっていて、メンバーが同じようなイメージを共有できてこそ有効なのではないかと思う。

ということは、今のような性格の業務アプリケーションを作る限りはアジャイルは無理だと思う。だから、この性格を変えなくてはいけない。何度も言っているように、How toはWhatに依存するということである。アジャイルの手法が使えるような構造のものにしなくては使えないということなのである。

コードを書かずに、部品あるいはモジュールをプラグインして組み上げる構造にしておいて、そこにアジャイル“的”な手法でシステム構築を行うというのがこれからのめざすところではないでしょうか。

ここで、アジャイル“的”と言ったのは、開発というイメージがあまりないやり方なのだが、ただし、精神はアジャイルだからという意味を込めてである。
  

2010年9月 9日

間違いだらけの業務システム開発(まとめ)

これまでの業務システム開発はいろいろな意味で限界が来ているように感じて、このようなタイトルで議論してきましたが、やはり重要なことは、技術だとかメソドロジーだとかもあるのですが、思想とかコンセプトだと思うのです。最後にそのあたりを考えてみます。

一番感じるのは、システムとは人間が使うものでありながら、それに使われている感じを変えたいということなのです。“仕事をやらされている感”を払しょくできないのかということです。ITを使って楽しく、気持ちよく仕事をしたいのです。

そうした思いから今のシステムを眺めるとどうも不十分であると思うのです。その理由は何かと、いろいろな角度からゼロベースで、どこが間違っているのか、どこを変革しなくていけないのか考えたのがこれまでのエントリーでもあったのです。

その主張のざっくりとした答えは、「重心をデータベースアプリケーションからプロセスアプリケーションへ」ということかもしれません。データベースへの出し入れが基本の仕組みももちろん大事ですが、そのデータベース間をつなぐプロセスがおろそかになっていると感じています。そこを中心に据えたらどうかという提案です。

それと、シンプルという意味も考えさせられました。シンプルにという概念は非常に重要ですが、それはへたするとすべてを単純化してしまうというワナにはまる可能性があるということです。実は、業務システムというのは非常に複雑でかつ重層的なものであるから、単純に括れないということであって、簡単にこんなものですとは言えません。

ですから、大事なのはちゃんと構造化をして、それぞれの部位での特徴や性格を見極めて、そこで定義することが大事なのです。この構造化というのは「抽象化」とういうことも含んでいます。抽象度を間違わないように設定して、それぞれの抽象度レベルで概念化することがとても重要です。

そうして、構造化、概念化された中で、それぞれの領域や要素では極力シンプルに考えることが要求されます。このシリーズでも、例えばプロセスのレベルによってその機能の性格が違うとか、ソフトウエアの開発とアプリケーションの構築は、手法も違うといったこと盛んに言ったのはこのことです。

どうもそういうことを一緒くたにして議論する人が多く、かみ合わないことがあります。こうした前提をきちんと共有して議論したいものです。いちおう。このシリーズはこれで終わりますが、またいろいろと勉強して、頭のなかが“整いました”らまた暫時エントリーしていきたいと思います。
  

About 間違いだらけの業務システム開発

ブログ「mark-wada blog」のカテゴリ「間違いだらけの業務システム開発」に投稿されたすべてのエントリーのアーカイブのページです。新しい順番に並んでいます。

前のカテゴリは業務プロセス設計作法です。

他にも多くのエントリーがあります。メインページアーカイブページも見てください。

Powered by
Movable Type