The Bottom Line

By Russ Finney

プロジェクトの結末

But is it always this way? Another team is exhausted. The death march is finally over. They will never have to see each other again. Boxes and logon IDs can't be turned in quickly enough. All references to real names are removed from programs. "Don't call me when this thing blows up", is muttered now and then. No team gathering is held, just a slow disbanding as each team member disappears onto other projects or activities. The clients seem disenchanted. An air of uncertainty and impending difficulty surrounds the system and those associated with it...
しかし、何時もこんなに上手く行くだろうか？別のチームは、疲れ果ててしまっている。死の行進は、 やっと終わった。彼らは再び顔を会わせる必要は無い。使用した書類箱やログオンIDは、 速やかに返却されはしない。プログラムからは、製作者の実名に繋がる一切のものが削除された。 「これが滅茶苦茶になっても、私を呼び出さないで」と、そこここで呟かれている。チームの会合は開かれず。 ただ、メンバーが次々と他のプロジェクトや業務で去って行き、徐々に解散が進んでいく。 顧客は幻滅し、不透明感と迫りくる難局の気配が、システムとそれに纏わる諸々の物に漂う。

Or, the worst fate. A surprise meeting! The team has been progressing, but somewhat without direction. The budget is slipping, the client is unsure what is happening, and questions are raised about competence. No one team member can be identified who has a "vision" of the system or the system building process. The inevitable happens, the project is cancelled. The money spent to date was absolutely, totally wasted!
最悪の場合は、こうだ。突然の会議！チームは進行してはいるが、幾分方向性を失っている。 予算は底を尽き、顧客は何が起きるか不安になり、プロジェクトチームの能力に疑問が投げ掛けられる。 プロジェクトの中にシステムの構想や開発作業について答えらる者はいない。 避け難い問題が発生し、プロジェクトは中止される。 既に使った資金は、全て無駄になる。

Why do some teams seem to make to the end successfully, other teams just make it to the end, and others never get the chance? Why are some teams on a continual "high" throughout the project while the members of a team right across the hall seem to drag into work every morning? Why is it that some clients describe a team with words like:
成功を収め終了しそうなチームもあれば、やっと終了に漕ぎ着けるチームもある。 残りは、終了の見込みさえないというのは何故だろう？プロジェクトの期間中、 ずっと高い志気を保つチームがあるのに、廊下を隔てた別のチームのメンバーは、 毎朝嫌々ながら仕事についている様に見えるのは何故だろう？ ある顧客がプロジェクトチームを以下の様な表現で評するのは何故だろう？

• they understand my business
• they are right on target
• we are all a part of the same team
• we were glad to be a part of this process?
• 彼らは、私の業務を理解している。
• 彼らは、しっかりと目標に向かっている。
• 我々は、全員が同じチームの一員だ。
• 我々は、この作業に喜んで参加した。

Yet another team may be described with:
他方、別のチームはこの様に評されるだろう。

• we not sure what they are doing
• they don't understand how our business really works
• we are very worried about how this mess is really going to turn out.
• 彼らが、何をやっているか良く判らない。
• 彼らは、我々の業務がどの様に動くか良く判っていない。
• 我々は、この纏まりの無い状態が、どうゆう結末になるか非常に心配である。

Does some secret formula exist to insure success, or is it just a matter of luck?
成功を確保する為の秘密の処方箋が在るのだろうか？或いは、ただ運次第なのだろうか？

Recent observations which have been made by non-technical business people are striking in their implications. One comes from Robert Townsend, the author of Further up the Organization, in which he states that "most of the computer technicians that you're likely to meet or hire are complicators, not simplifiers. They're trying to make it look tough, not easy. They're building a mystic, a priesthood, their own mumbo-jumbo ritual to keep you from knowing what they - and you - are doing". This is disturbing commentary. It gives a clear voice to the concerns that many clients express when the computer professional's back is turned:
最近、非技術系実務者によって纏められた見方は、注目すべき意味を含んでいる。 その1つは、Further up the Organizationの筆者Robert Townsendのものである。 その中で彼はこう言っている。 「読者が出会ったり、雇ったりするコンピュータ技術者の殆どが、物事を複雑にしてしまう型の人間で、 簡単にする型ではない」。彼らは、しかめっ面をして、親しみ易そうに見せようとはしない。 彼らは、秘密主義を採り、聖職者を装い、訳の判らない儀式で、彼ら(と顧客)が何をしているのか 顧客に判らせようとしない。これは、憂慮すべき意見である。 それは、コンピュータ専門家のいない所で、多くの顧客が示す心配を如実に物語っている。

• Will I get the results I need?
• Will my business problem be comprehended?
• Will I understand both the solution as well as the process used to arrive at the solution?
• How will I be included in the process?
• How much control will I have?
• Will I really have anything at the end to show for the risk I am taking?
• 必要な結果が得られるか？
• 業務の問題は理解して貰えるのか？
• 解決策とそれに至る過程を理解出来るか？
• どの様に参画したら良いのか？
• プロジェクトの管理に(自分は)どの程度関与出来るのか？
• 最終的には、自分が取るリスクの大きさを知る手掛かりを得られるのか？

An even more disturbing observation comes from one of the acknowledged "thought leaders" in the systems field - Ed Yourdon. In his book, Managing the Structured Techniques, he writes:
更に心配な意見が、システム分野で著名な理論の大家Ed Yourdonから出されている。 著書Managing the Structured Techniquesの中で彼は次の様に述べている。

"Something happened to the personality and mentality of the data processing profession as a whole as we moved to the ultra-sophisticated on-line, real-time, fourth-generation and fifth-generation machines of the 1980's and 1990's. The profession began to attract people who, regardless of their race, creed, color, or university degrees, are clerks. They think like clerks, talk like clerks, and they approach computer programming and systems analysis with all the enthusiasm of a sleepy civil service clerk who knows that he's just one year away from retirement.Having met some twenty-five thousand analysts, designers, and programmers throughout the world, I found a surprising number of them have never read any computer articles or even opened a copy of Datamation or Computerworld; have never heard of ACM, DPMA, IEEE, ASM, or any other professional organizations; can't spell Dijkstra's name and probably have never heard of him; aren't aware of the structured techniques and wouldn't be interested if somebody showed them."
社会が、非常に複雑なオンライン、リアルタイム、1980年代、1990年代の第4世代、第5世代コンピュータへと移行していくにつれ、 データ処理担当者全体の性格や心理に変化が起きた。人種、信条、肌の色、学歴を問わず、事務職の人々が、 その職業に魅力を感じ始めた。彼らの発想や話し振りは、事務員そのまま、プログラミングやシステム分析については、 定年を一年後に控えた眠たそうな市民サービス職員と同じ位の熱意しか持ち合わせていなかった。 世界各国の25,000余に上るアナリスト、設計者やプログラマに会って、私は、次の様な事実を発見した。 ”驚くほど多くの者が、全くコンピュータの記事を読まず、Datamation誌やComputerworld誌を 開けた事さえなく、ACM, DPMA, IEEE, ASMやその他の専門家組織を聞いた事もない。 Dijkstraの名前を書けないし、多分聞いた事もないだろう。構造化技法について認識も無いし、 誰かが教えてくれたとしても興味を示さない。”

What makes this even more distressing, is that fact that business executives are now turning to the IS professionals on an ever increasing rate in order to provide them with systems which give the business a strategic as well as a competitive advantage. The major problem here is that computer programming clerks who are enamored with the technology and who could care less about the business itself, will not make this happen. A new breed of computer professional is required who has a balance of people skills, technical skills, and business skills.
更に深刻なのは、経営に戦略と競争力をもたらすシステムを自ら構築する目的で、 これ迄以上の数の実務担当役員がIS専門家になっているという事実である。 ここでの大きな問題は、技術に夢中で経営には関心が薄いプログラミング職員が、 この動きを妨害しようとする事である。新種のコンピュータ専門家には、バランスの取れた対人能力、 技術能力、経営能力が必要である。

Some Required Thinking Shifts:
求められる発想の転換とは：

• Stop automating existing ways of doing business without assisting in improving the business processes first.
• Stop thinking in terms of departmental processing.
• Start thinking in terms of cross-organizational systems and business clients.
• Start adjusting to the fact that business processes are changing at an ever increasing rate, and the development team must be prepared to keep up - even as a system is being designed and constructed.
• Start embracing new forms of technology which show significant cost savings potential.
• Start recognizing that if the business client's demands can't be met by you, countless other service providers exist who will be willing to meet those needs.
• 先に業務改善の努力をしないで、現状をそのまま自動化しようとする事を止める。
• 業務を別々の部門の枠で考える事を止める。
• 組織横断的なシステムやエンドユーザーの視点で考える。
• 業務が益々速く変化しているという事実に適応する。 開発チームは、システムが設計中、構築中に関わらず、その変化に備えておく必要がある。
• 顕著な費用節減が期待出来る新しい技術は、採り入れる。
• 自分でエンドユーザーの要求を満たせない場合でも、 それらの要求に応えようとする業者が他に無数に存在する事を認識しておく。

In today's information based society, the system building professional is faced with even greater challenges than ever before. Exploding technological innovation, relentless complexity increases, faster paced business changes, and increasingly sophisticated business clients are placing greater demands on the talents on the business system professional. In addition, a true spirit of trust and teamwork must exist and perpetuate between the business clients and the business systems professionals. This is the first real quest. The next is even more critical. In the end, a business system must be delivered. A system provides no benefit to anyone unless it is in an accepted technical environment and actually being utilized by the business.
今日の情報依存型の社会では、システム構築専門家は、過去にも増して大きな試練に直面している。 爆発的に多くの技術的発明、止めを知らない複雑化、益々早くなる業務の変化、 多くの知識を身に付けてきているエンドユーザー、これらがの業務システムの専門家により多くの要求を突きつけてきている。 加えて、真の信頼関係とチームワークが、エンドユーザーとシステムの専門家との間に存在し、 かつ維持されていかなければならない。これが、最初の要請である。次は、もっと決定的である。 最終的に、業務システムは引き渡されなければならない。システムは、それが採用された技術環境にあって、 業務に利用されなければ誰にもその効用をもたらす事が出来ない。

That is the creed of this web site. All of the analysis and design, or the blood, sweat, and tears, won't amount to anything if a working system does not exist in the end as a result of the effort.
これがこのWebサイトの信条である。努力の結果として実働システムが存在しない限り、 分析・設計作業、血と汗と涙、それら全てが何の意味も無いのである。

Copyright © 1999, Russ Finney, All Rights Reserved