PMO,開発部マネージャの方への最近のブログ記事

仕事の線表は自分で決める

要するに自分が使われているのではない、自分が仕事をコントロールしているのだ、そういうことを私はコントロール感のある仕事の進め方といいます。ですから、仕事の線表は自分で決めます。といっても全体スケジュールに穴をあけるようなことは出来ませんので、全体最適の中での個別最適を行うということです。それでも、全てを決められたもの、与えられたものとして受け身で仕事をするよりは、積極的に仕事に励めます。

先を見通す力をつける

今の自分の仕事の3ヶ月先は大体見当がつくと思いますが、1年先をどう捉えるか。これは、今の時代ではけっこう厳しいものがあると思います。その中で、自分の仕事領域の外部条件の変化や技術の流れを読んで、先を見通す力をつけると、仕事に使われているのではなく仕事を自分でコントロールしている感覚になると思います。

今の立場より一つか二つ上の立場で判断する力を付ける

今現在、自分が置かれている立場より一つか二つ上の立場で判断する力をつける。これは、自分が係長なら、課長はこのことについてどう判断するかな、部長ならどう判断するかなということを予測した上で、自分の判断をすることを心がけるということです。課長や部長のキャラクターによっては、ものごとに対する判断がまるで逆になることもありえますので、自分がやりたいことを通すための作戦をよく考えて下さい。大体において二つ上の立場の人の判断が予測できるようになると、非常に楽です。 以上の三つのことが出来るようになると、自分の仕事を自分でコントロールできます。

動機付けを明確にする（情報の共有）

人の力を引き出すマネジメントを行う上で一番重要なことは、「何のためにこのシステムを作るのか？」あるいは「このプロジェクトの目的は何か？」といった動機づけを明確にすることです。これは情報の共有ということで、プロジェクトマネージャーだけが情報をにぎって、プロジェクトのメンバーには何も知らせないということでは部下は働く気になりません。

プロジェクトマネージャーが、プロジェクトの目的、現在の状況、今後起こりうるリスク等をきちんとメンバーに説明しないと、下から悪い情報は早く挙がって来ません。

コントロール感のある仕事をやらせる

部下にコントロール感のある仕事をやらせるということは、プロジェクト全体の進行は決められたスケジュールで行うわけですが、個々のメンバーが担当する仕事の進め方は、あたかもその個人が自分で決めて進めていくような感覚にすることです。これについては別の項目で述べたいと思います。

段階的に達成感を味あわせる

プロジェクトマネージャーは部下のメンバーに、段階的に達成感を味あわせることがメンバーの力を引出すことになります。大規模ソフトウェアの開発などでは２年ぐらいの長丁場になります。そうすると、３カ月ぐらいごとに、ああここまで出来たね、やったね、そういう達成感を味あわせることが必要になります。遠い目標に向かってひたすら馬車馬のごとく走れというだけではなかなかうまいマネジメントはできないので、この段階的にというマイルストーンをつくって、そこに達したならばよかったねという、そういう形です。

見えない物には意見は言えない

開発技術は、現場は急には変わらないことを認識しておいて欲しいと思います。技術者がいろいろな新しいものを考えて、その新しいものを現場に導入しても、使う側の立場の人間というのはそう簡単には変わりません。「こう言う新しいシステムを作ろうとしていて、今なら現場の皆さんの意見を反映できますが、何か意見はありませんか？」と、その新しいシステムが将来導入される現場の人々に問いかけても、出てくる意見は、今あるシステムのあそこが悪いから直して欲しい、次のシステムではこういうことが起きないようにして欲しいという既存のシステムへの意見だけです。新しいシステムはどうですかと言われても、そんなもの見たこともないから意見は言えないということです。

これは、一般的にシステムの運用をしている人からみれば、そもそもそのシステムがどういう思想でつくられているかなんていうことは関係なく、これちゃんと面倒見ろよと言われて、こうやれば動くのか、このボタンを押せば壊れたときもリセットがかかるのか、そういうことだけしかわからないわけです。

開発者の思いもしない使い方をする

そうすると、現場の皆さんは開発者の思いもしない使い方をします。これはハードもそうですし、ソフトもそうです。これは非常におもしろくて、ソフトの場合に設計する人と試験する人とを分けてやると、設計する人は自分の頭で考えてテストのデータを作る。そうすると、そのときは自分が設計したのだから、自分で試験データを作る分にはちゃんと通る。ところが、作った人と全然違う人が試験をやると、とんでもないデータを入れる。そうすると、突然バグが出る。何で出たの、いやパラメータチェックが甘かったのだ、「まさかそんな値を入れるとは思わなかったと。」そういう言い方なのです。

これはハードウェアでもそういうことは当然ありますし、ソフトウェアでも起きてくるということで、そのときに開発する側としては弁解をしてはいけなくて、確かに我々の設計に漏れていたところがありましたということになります。

システムを使いこなせるようになると次の要求がでる

それから、急には変わらないのですが、システムを使いこなせるようになると次はこうして欲しいという話が出てきます。ですから、顧客の潜在ニーズというものをいかに早くつかんで、今のシステムに対して次の要求は、当然こういうものが出てくるであろうということが予測できるようになると大分違ってきます。

システム開発の専門家として

• 顧客の潜在ニーズを掴み
• 技術と業務の両面で顧客を説得し
• 自分のペースで仕事をする

ことが出来れば理想である。 システム開発に関わっている皆さんにぜひとも持っていただきたいもの、専門家としての自負を持っていただきたいと思います。これはシステム開発の専門家としてお客様の潜在ニーズをつかんで、最近はソフトウェア開発ということで業務まで入っていますが、技術と業務の両面で顧客を説得し、自分のペースで仕事をすることができれば理想であるということです。別項で述べたように、お客様は自分が本当に欲しいものを知っておられません。それから、よいものを作るためにはどこで妥協すれば良いかもお分かりになりません。お客様を説得する、教育するというと余りよい言い方ではないかもしれませんが、必要なことだと思います。

自分のペース、要するに開発線表では、無理のない線表というのはまず引けませんが、とにかくこちらのペースで仕事ができるように、専門家としての自負を持って、できない、やってはいけないことは、もうできませんとはっきり言い、それからお客様にはここから先は私たち専門家にどうぞお任せくださいと、任せ切ってもらうことをする。そういう意味での自負をぜひとも持っていただきたいということです。

初期システムは、開発完了が出発点

この話は、どちらかというとハードよりはソフトウェアの方のシステムです。システム開発は最後の仕上げが肝心ということです。初期システムと言っていますけれども、バージョン１と呼ばれるものは、開発完了が出発点です。どういうことかというと、お客様の要望に応じてシステムというものを作るわけです。大体お客様の要望は非常に多くのものがあって、当然のごとく色々な要求があります。それらを全部実現していたら所要時期にはシステムはできないということになります。初期システムというのは大体６０点から８０点ぐらいでご容赦くださいということで作るわけです。ということは、初期システムが開発完了しました、で終わりではなく、そこから今度はお客様と一緒にシステムを育てることになります。

導入支援はおまけではない

普通のシステムでは、システムの要となるデータベースが必要です。初期システムのものだけ作って、データベースのデータ投入はお客さんの仕事だといって知らん顔する。悪い例だと、そこでデータが入り切れなくてシステムは導入したのだけれども、結局使われないまま置いておかれる。そういうシステムは世の中にはかなりあります。

あらかじめこういうデータの精度を高めておかないとシステムはうまく動きませんということで、お客様の運用部門との間でデータの精度をどうやって向上させるか、そのためのツールはどうするかといった事前準備をきちんとやっておいて、そのうえでシステムを入れるのです。このように開発した側が導入支援をきちんとやる必要があります。

顧客と共にシステムを育てる

初期システムが導入されても、まだ生まれたばかりで、初期システムに盛り込めなかった機能の追加や運用を開始した後でのフィードバック開発などシステムの完成度を高めることは、開発側がお客様と一緒にシステムを育てるという心でやらないとなかなかうまくいきません。

いつどのような機能を追加するのかといった段取りを考えておかないといけません。これは社会インフラに関わるシステムでは特に重要で、そのシステムが使われなくなるまでずっと保守をやっていくことになりますから、顧客との良い関係を保ち愛情をもってシステムを育てて欲しいと思います。

現状が悪いほど新しいシステムの付加価値は大

現場は開発の宝の山と書いたのですが、現状のシステムがいろいろ悪いと言われる、ということは、現状が悪いほど新しいシステムの付加価値は大きくなります。これは経営などでも言われることですが、今の状態が悪ければそれ以上悪くならないのだから、その悪いものを順番につぶしていけばよくなるのではないかと。

多分悪いというその程度の問題というのはいろいろな面で、例えばもともとは非常にたくさん人がいることを前提につくったシステムなのに、企業の合理化で人だけ減ったとなると、初めはよかったシステムが悪くなってしまうわけです。ですから、そこら辺の悪さかげんというのはどういうものなのか、それに対してどういうふうに新しいもので付加価値をつけていけばいいのかということを考えることが必要です。

システムの世代交代を考える

システムの世代交代を考える。これはコンピュータで言えばメインフレームからクライアントサーバ最近はクラウドコンピューティングということで、技術の進歩に伴いシステムの形態も変わってきます。未だにメインフレームが一部生き残っている分野もありますが、コンピュータのハードウェアとソフトウェアの進化に合わせてシステムの世代交代を考える必要があります。もっとも、ソフトウェアベンダーの商売に乗せられてころころシステム変更をすることは避けなければなりません。

過去との継続性は程々に

少し古い話で恐縮ですが、コンピュータがメインフレームからクライアントサーバに世代交代するときに、メインフレーム上で動いていたアプリケーションソフトをそのまま新しいサーバに載せ代えたいという話がありました。ここでの問題は、古いシステムのアプリケーションソフトは、コンピュータのプロセッサの速度が遅くメモリの容量にも制限があるので、顧客の要求を押さえつけて作ったものなので、顧客側から見れば新しいシステムにするのならあれもこれも出来るようにして欲しいということになります。

開発側のお金や時間の都合で、古いシステムのソフトを新しいシステムに移植したとしても、顧客からは次々に追加開発の要求が来て、結局、新しいシステムの上で新しいソフトを新規開発したほうが安くて使い勝手もよかったということになりかねません。そういう意味で、過去との継続性はほどほどにということを言っているわけです。ようは要求条件が違ってきているということを考えると、余り過去のものに引っ張られることはよくないだろうと思います。

ゼロベースの開発では最重要

システムですからコンセプトといいますか、ものの考え方が大事です。考えているだけではだめなのですけれども、システムコンセプトを作って、その上で全体を組み立てていくことが必要です。特にゼロベースの開発では非常に重要なことです。このコンセプトが間違ってしまうとなかなかよいものはできません。

わかりやすさ、考え方が見えるものを作る

コンセプトは、わかりやすさとか考え方が見えるものを作る必要があります。それと、決めたら全体を統一することが必要です。これは新しい通信システムを作るときに、装置を安くしようということだけでなく、その装置が使われる環境や運用方法まで含めてコンセプトを作ることが大切です。その原則は、構成のシンプル化と運用の簡易化の二つが大もとの考え方です。この考え方自体は、別に大したことというわけではありません。

決めたら全体を統一する

このベースの上に立って、新しい通信システムにやったことは何かというと、それまでは通信機械室に人が入って保守をしていた。通信機械室に人は入らなくても保守できるようにしましょう。それまでの装置は自然空冷でなければいけない。それにしばられたら装置全体が大きくなってしまうから強制空冷も使いましょうということです。そういう意味では、基本的な考え方に沿って先々の状況の変化というものを読んで、かなり大胆に前提条件を変えていく。そのときに、寄って立つ考え方はといったら、このコンセプトというところに端を発して、それからきちんとつながっているというのがわかりやすく見えていないとだめです。

時代、技術により分担は変わる

ハードとソフトの機能分担は、なかなか難しいもので、時代、技術により分担は変わりますが、今現在は相体的にソフトへ振り過ぎていると思います。

ハードとソフトの機能分担の例として、よくパソコンをとりあげるのですが、パソコンはハードの性能向上がすばらしいのに、それに伴ってパソコン用のＯＳ（オペレーティングシステム）が肥大して、結局、使う側からみるとログスケールぐらいでしか使いやすさは良くなっていない。どうもパソコンのハードとソフトの機能分担というのは余りうまくないと思います。

ハードのバグはとれるが、ソフトのバグはとりきれない

機能分担に関連する問題の一つは、ハードのバグはとれるけれども、ソフトのバグはとり切れないことです。この辺に私自身の経験からいっても非常に悔しい部分があるわけです。ＬＳＩとソフトという技術はほぼ同じような時期に非常に成長しました。ＬＳＩ側はＣＡＤが非常に発達して自動設計ができて、ＣＡＤ上でシミュレーションができます。そうすると、そこでほとんど回路設計上のバグというのはとれますし、最近はＬＳＩの中にセルフチェックするようなテスト回路を入れることもできます。 これに対してソフトの方は、はっきり言ってこの２０年、特に大規模システムソフトのつくりというものは、言語とかＯＳとかというものは変わってきていますけれども、基本的には変わっていません。

オブジェクト指向が救世主になったかというと、やはり大規模システムにおいてはなっていません。結局、それはもう人がひたすら設計をやって、こつこつ作って試験をやっています。ソフトの場合でも、設計ツールをそろえて、少しでも安くていいものを早く作ろうという努力をしているのですが、なぜか今度はツールに頼って人間が余り考えなくなってしまう。そうすると、根本的な部分まで戻って設計を直そうと思うと、人間の思考回路の中できちっとそういうものがフォローし切れなくなる。そういうこともあって、やはりソフトのバグというのは常に残ります。それも試験期間といいますか、試験中に全部取りきるわけにもいかないし、本当にバグなしになるまで試験をしていると、いつまでたってもサービスに供することができません。

使い方の決まるものはハードへ

ハードとソフトの機能分担を考えるときに以上のようなことを考えれば、とにかく使い方の決まるものはハードへということになります。私が経験した通信システムの開発の例で言うと、新世代の最初のシステムであったので、使い方がわからないからといっていろいろな機能をソフトに振ってしまいました。システムが現場に導入されて使いこなせるようになった時点で改良するとすれば、かなりの部分はハードに落とせると思います。

自らの退路を断つ

システム開発プロジェクトは、限られたお金や人のリソースと限られた時間の中で進めるものですから、開発リーダーとしてのマネージャーの態度に緩みがあってはいけません。自らの退路を断ち、絶対にやり抜くという強い信念と自信にあふれた態度でプロジェクトを引っ張って下さい。開発リーダーが自分に逃げ道を作ってしまうと、開発リーダーの交代というプロジェクト崩壊の第一歩が始まります。

人の和を作る

ハードであれソフトであれシステム開発プロジェクトは人間が行うものですから、そこに参画する人たちの心がひとつになっていないとうまくいきません。成果主義ということで個人個人の目標を立て、その達成度で成績をつけることが一時期もてはやされました。この成果主義は、非常に能力が高く一人でソフトウェアを開発できるような技術者には適用出来るかもしれませんが、日本人はグループで成果を出すことが得意なので日本には定着していません。プロジェクトのメンバーの人の和を作ることは、開発リーダーの役目です。

謝ることはリーダーの役目と自覚する

開発リーダーはプロジェクトを任された責任があるのですから、対外的な全ての折衝の責任があります。といっても、プロジェクトを推進する中で開発リーダーが褒められることは、あったとしてもうまく完成した時の1回だけで、あとは色々なトラブルに関して謝ることばかりです。プロジェクトのメンバーは、開発リーダーが責任を取って自らが顧客のところへ謝りに行く姿を見れば、この人にために頑張ろうという気持ちになります。反対に、開発リーダーが部下に謝りに行かせるようではそのプロジェクトはうまくいきません。

ある技術分野の専門家になる

マネージャーには、ある技術分野の専門家になって技術力で勝負ができるようになることが必要です。ひとつの技術分野で専門家になると不思議と技術的な勘が働くようになり、外の技術分野の事象に対しても正鵠を得た意見を言えるようになります。専門家になるにはひとつの技術分野で10年は仕事を続けないと難しいので、途中で仕事が変わっても、自分が専門とする分野の勉強を続けて下さい。不思議なもので、そういう努力をする人にはチャンスが回ってきます。

大局的判断力を養う

システム開発プロジェクトを推進する上で、マネージャーは色々と判断しなければならないことがでてきます。とかく自分のプロジェクトの事情がこうだからああしたい、こうしたいと自己中心に考えがちですが、顧客の立場から見たときの物の考え方を身に付けることが大切です。大局的判断力を養うには、人の話を謙虚に聞くことや偉大な経営者に関する本を読むことが有効です。それと周りの人の行動や判断をよく観察すると、「人の振りみて我が振り直せ」ではありませんが、反面教師は結構います。

部下に仕事を任せる腹を持つ

マネージャーにはマネージャーのやるべき仕事があるので、開発プロジェクトの仕事の実体は部下に任せなければ全体としてうまくいきません。ついつい自分が技術的に強い分野の仕事だと色々口をはさみたくなるものですが、部下を育てるためには部下に仕事を任せなければなりません。部下に仕事を任せても最終的な責任はマネージャーにあるのですから、いかに太っ腹になれるか、どれだけ部下から信用されるあるいは尊敬されるかが問われるのです。マネージャーとして、きちんと技術的判断ができるだけの技術力をつけることが第一歩だと思います。

専門家になるには１０年かかる

ひとつの技術分野の専門家になるには１０年はかかります。ひとつの技術分野で専門家になれば、もうひとつ分野を広げることは５年でできるようになります。ひとりの人が色々な分野の専門家になれるわけではないので、いろいろな分野の専門家とお友達になって情報を交換したり専門家の判断を仰いだりすることが大切です。

ギブ・アンド・テイクの出来る仲間を作る

専門家のお友達を作るには、自分も専門家として情報提供ができなければなりません。ただ情報だけをとっていくだけの人とは、専門家でなくても付き合いたくないものです。お互いに専門家として尊敬しあい、情報のギブ・アンド・テイクが出来る仲間をたくさん作ることが大切です。

良き仲間とは誠実に付き合う

技術者も人間ですから、人間関係を大切にして良き仲間とは誠実に付き合うことが大切です。特に、技術の研究開発においてはその技術に勢いがあったときに一緒に仕事をした仲間とは長い付き合いができます。私の経験では、昭和40年代後半のこれからは画像の時代だといわれていたときにいた研究室の仲間、昭和50年代後半の電話の加入者系のデジタル化の研究を一緒に進めていた仲間そして昭和の最後から平成にかけて新しい伝送システムを共に開発した仲間とは今でも良い付き合いをしています。

手抜きはばれる（まあいいかはダメ）

システムの規模が大きくなり、かつ短期間での開発を要求されるとソフトウェアであれ組み込みソフトであれ、既存ソフトからの流用あるいは改造を行わざるを得なくなります。先輩が作って現用の装置で動いているソフトモジュールだから大丈夫だろうと思って流用して見ると、思わぬバグがでることがあります。これは、ソフトの動く環境が変わったために潜在していたバグが現れたということで、例え機能が同じでも、新たなソフトモジュールの設計はきちんとやって、流用するソフトのソーストレースをやって大丈夫なことを確認してから流用してください。マネージャーの仕事は、メンバーが手抜きをしないように指導することです。

出来ないことは出来ない

出来ることと出来ないことを見極める必要があります。特にソフトウェアの開発においては、無限の稼動を投入すれば出来ないことは無さそうに思われますが、現実には時間も人も限られているのですから、顧客からの過大な要求を仕切るマネージャーが必要になります。

ハードウェア開発においても限られた時間の中で行うわけですから、最先端のＬＳＩ技術に期待をかけて極めて高性能な装置にするのか、最先端のひとつ手前の枯れた技術を採用して高性能で安定した装置にするのかマネージャーに判断が求められます。

システムの性能は要素技術の中で一番低いもので決まる

システムの主要部分については十分な検討を行い高性能なものにしたとしても、システム全体の性能はシステムを構成する要素技術の中で一番性能の低いもので決まります。ハードウェアでは、電源とアースまわりの設計には注意が必要です。装置の信頼性が電源まわりに使われていたコンデンサで決まってしまうことも起こります。システム全体に目配せをして要素技術のバランスをとることがマネージャーの仕事です。

ビジョンを示すこと

５年先に自分たちの仕事がどうなっているかを示す物がビジョンです。３年先までは事業計画で、近場は開発計画で仕事の将来像が見えますが、それだけでは開発メンバーのモチベーションを高めることは難しいと思います。５年先の姿を確定的に述べることは難しいことですが、社会の要請の変化と技術の流れを読んで、開発リーダーとしてのビジョンを示すことが大切です。

メンバーが仕事のやり易い環境を整えること

開発リーダーの重要な役割のひとつは、メンバーが仕事のやり易い環境を整えることです。ここで言う環境とは、物理的な職場環境のみならず人的リソースから予算を含めた広い意味の環境をいいます。言って見れば、開発メンバーに対する鞭と飴の飴に相当するものです。メンバーからみれば、このリーダーは自分たちを大切にしてくれている、そういうリーダーだからついていこうということになります。

顧客に謝ること

システム開発では、全てが順調にいってトラブル無く開発完了を迎えることは、まずありません。小さいトラブルが重なるようだと、そこには結構根の深い原因があります。それが顧客からの仕様変更によるものであることは多々ありえます。顧客側の担当者と開発メンバーの間では仕切りきれないような場合には、開発リーダーが顧客の責任者に話をする必要があります。この時、良いシステムを納期までに完成させるという顧客側と開発側の共通意識を醸成するために、開発リーダーは下手にでて謝りながら実をとることも大切です。　勿論、大きなバグをだして顧客に迷惑をかけるような場合には、開発リーダーが謝りにいくことは必須です。これを開発メンバーまかせにして、自分の責任を回避するようなリーダーには人はついていきません。

本流を見極める

システム開発において採用する技術は、そのシステムが社会インフラに関わる度合いが高い物ほど本流の技術である必要があります。本流の技術とは、過去の開発経緯を振り返れば分かるのですが、筋が良くてある程度枯れた技術をいいます。システムが長期に渡り安定して稼動するためには、開発時に技術の本流を見極めることが大切です。

先端技術がものになるまでには時間がかかる

システム開発時に、その時の先端技術が魅力的に見えても、その先端技術が本当に使いものになるまでにはいくつかのトラブルを経験することを覚悟しなければなりません。世の中で広く使われることにより、先端分野では見えていなかった技術上の問題点が見えてくるからです。

初物には注意（First Userにはなるな）

先端技術ではなくても、新製品ですと売り込まれる部品を安易に取り入れることは、自分たちがその新製品のデバグをすることを覚悟しなければなりません。"First Userにはなるな"というと、随分後ろ向きに思えるかもしれませんが、開発期間が短い場合には新製品の採用には注意しないと思わぬ開発遅延を招くことになります。

技術の世代交代を知る

技術の世代交代とは、アナログ技術からデジタル技術、メタリック技術から光ファイバー技術というような、技術の大きな変革をいいます。技術の変革期には必ず両世代の技術を組み合わせたハイブリッドシステムの提案がなされますが、世代交代が進むと消えていきます。新世代の技術の将来を見通して大胆に乗り換えていくことも必要です。

作業は必ずペアでやる

システムの移行作業やトラブル対策作業は必ず二人の人がペアで行って下さい。一人が実作業を行い、もう一人は手順書に従ってきちんと作業が進んでいるか冷静な目でチェックをしてください。作業中に異常が発生したときに、一人で作業していると頭の中が真っ白になってさらに余計なことをすることになります。二人ペアでやっていれば、異常が発生するまでの作業手順を振り返り、原因を冷静に分析することができます。

リハーサルを確実に実行する

システムの移行作業やトラブル対策作業は、検証設備でリハーサルを確実に実行して下さい。ちょっとした修正だから大丈夫だろうと思って、いきなり現用システムに入れることは、絶対に避けて下さい。実際問題としては、検証設備を現用システムと同じにすることはお金の面でほとんど無理で、検証設備ではOKだったのに現用システムではNGということもおきえます。それでも、手順書の検証を含めリハーサルを確実に実行して下さい。

リリースファイルで試験をする

大規模なシステムでは、試験が済んだブロックごとのソフトウェアファイルを最後にマージしてリリースファイルを作ります。このリリースファイルを作る作業は極めて慎重にやる必要があります。全部試験が済んだファイルのつもりが１ファイルだけ前のバージョンだったということは結構な確率で発生します。

試験用ファイルではOKだったのにリリースファイルではNGということがおきるのです。ですからリリースファイルができたら、そのリリースファイルで試験をしてください。

人についたノウハウを組織に残す

システム開発を行うと、それに参画した人々は色々な技術やノウハウを身に付けることができます。システムの仕様書には基本的なことしか書かれていなくても、システム設計書には詳細なフローチャートやパラメータが記載されます。システムを作ることは設計書があればできます。

問題は、システムが完成すると設計書と試験成績書は残りますが、システムアーキテクチャをどう決めたのか？パラメータの範囲はどう決めたのか？といった設計根拠が開発に携わった人々の頭の中にしか残らないことです。人についたノウハウを組織に残すため、忙しく時間がないのは分かりますが、設計根拠資料を残しましょう！

システムの無理な拡張を回避するため

設計根拠が分からないと、後からシステムに手を入れて拡張する際に、どこまでが現行システムの延長で可能で、どこから以上は新システムに移行すべきかということが分かりません。よくあることは、システム拡張をした結果、思わぬバグがでて、そのバグを修正しようとしたら次々に修正が入ることになり二進も三進もいかなくなることです。システムの無理な拡張を回避するためにも設計根拠資料を残しましょう！

システムの性能問題の限界を明確化するため

システムの性能は、最初に開発したシステムに大きく依存します。単位時間当たりのジョブの処理量は最初のシステム設計時にはもちろんマージンを持って設計します。システムが使われだすと、当然のことながら処理量は増加し、ある負荷以上になると動作が不安定になる、システムが挙動不審な動きをすることがおきる場合があります。性能問題はその限界が見えにくいものなので、システムの性能問題の限界を明確化するためにも設計根拠資料を残しましょう！

導入部門に強い意志がないと駄目

企業が経営体質を強化するために業務改革を行う場合に、いくらトップが方針を出しても、業務改革の現場がその気にならなければ成功はありえません。業務改革を指向するシステム開発においては、導入部門に「改革をやるんだ！」という強い意志がないと駄目です。今までと仕事のやり方が変わる、業務に関わる人の数が減るといった現場の不安を掻き立てる要素が多いわけですから、経営トップが強い意志で現場を説得、指導して、現場の人々に業務改革をやることを自らの問題としてとらえるところまでいかないと、システム開発を請け負う側は、トップの要求と現場の要求の板ばさみになりよいシステムは作れません。

シンプルなワークフローを考える

業務をいかにシンプルにするか、あるインプットからあるアウトプットを得るための最もシンプルなワークフローをまず考えます。そのワークフローに含まれるプロセスの数をいかに減らすか、ループになるプロセスはないか、本来のフローでは必須ではないがデータだけ参照したいといった要求はデータベース検索メニューとして別枠にするといったことを考えて、シンプルが一番を実践します。

システム導入の準備、運用の定着には時間がかかる

業務改革を指向するシステムを現場に導入するときには、その準備に時間がかかります。それまでは各拠点ごとに小さいシステムがあり、その小さいシステムにばらばらに入力していたデータを新しく導入する全社システムに移行させるには、個々のデータの不整合やダブリを取り除いてデータをきれいする必要があります。この作業をさぼると新システムは使い物にならないと言われることになります。

新システムを使った現場の運用が定着するのにも時間がかかります。最初からうまく動く新システムはめずらしいもので、通常は現場に入れて初めてでてくるバグもあります。これはテスト環境でのコンピュータの擬似負荷が軽かったため実環境で重い負荷がかかって出てくるバグの類です。これ以外にも現場要望で細かいところに手を入れなければならなくなることもあります。他でも述べますが、新システムは開発側と導入側が協同で育てていかなければ良い物にはなりません。