Programming: A New Creative Focus

By Russ Finney

プログラミング：新しい創造性の対象

The process of designing the external and the internal workings of a new system are considered by many to be the fun part of system building. But to some, the upcoming task of actually constructing the designed system is considered to be somewhat of a grueling prospect. Yet, there are others to which computer programming is a genuine pleasure! To them, this is where the real technical creativity comes into play. Taking a design and implementing it as efficiently as possible, while at the same time creating clever program module/class components with high reusability, represents a gratifying intellectual challenge. These people are the true technical system construction "purests".
新システムの内部機能や外部機能の設計は、多くの人が、システム構築の面白い部分だと考えている。しかし、次の設計されたシステムを作り込む作業には、嫌な印象を持っている人がいる。他方で、コンピュータプログラミングを本当の楽しみ！にしている者もいる。彼らにとって、これこそ本物の技術的創造性の見せ場なのである。設計に従い実装を出来る限り効率的に進め、同時に、高い再利用性を持たせて巧みなプログラムモジュール/クラスコンポーネントを作り出す事は、格好の知的問題である。こう言った人々は、真のシステム構築技術の"純粋主義者"である。

Given these different personality types, one of the keys to a successful construction effort is to assemble a team of both business focused designers and technically focused programmers which will effectively join forces and see the programming or code generation effort through to completion. Luckily, many systems professionals find both the design and construction aspects and challenges equally gratifying, and it bodes well for a team to have a sprinkling of these "middle of the road" types in with the others to serve as communication bridges.
こういう異なった個性の人間がいると、構築成功の鍵の1つは、業務に焦点を置いている設計者と、技術中心に考えているプログラマーの両方を入れ、うまく協力してプログラミングやコード生成を進めるチームを編成する事である。幸い、多くのシステム専門家の好みは、設計も構築作業もその見方や内容において同じ程度である。この様な"中道"型が何人か入っていると、お互いのコミュニケーションの仲介役として機能し、チームに良い作用をもたらす。

During the programming or code generation part of the project, the team leader must also change his or her focus. Up to this point he or she has probably been heavily involved with the requirements definition, the system component design, and the issue management and resolution aspects of the earlier phases. Now that the programming effort is underway (and if the system is of a significant size), the team leader will no longer have the luxury of being as close to the details as he or she might have been in the earlier phases. But how involved with the effort and the details should the team leader be? Is there an appropriate level of participation?
プログラミングやコード生成の間にも、チームリーダーは、自分の注目点を変えていかなければならない。この時迄、彼（彼女）は、多分要件定義、システムコンポーネント設計、先行フェーズの懸案管理・処理などに深く関わって来ただろう。今、プログラミングが進行中だし (システム規模が大きければ尚更)、チームリーダーは、もはや、これ迄の様に詳細にまで関与する事は許されない。では、作業や詳細事項にどの様に関わったら良いのだろうか？適切な程度があるのだろうか?

The answer to these questions is: absolutely! Since the team leader is accountable for the final delivered product, this is no time to put them team on auto-pilot just because the design seems to be rock solid. Many design changes, issue resolutions, and communication misunderstandings still lurk in the shadows of this project stage. The team leader must be on the prowl constantly, keeping a sharp eye out for potential progress road blocks and diversions.
これに対する答えは、勿論!である。納品される製品への責任を考えると、チームリーダーは、設計がしっかりと出来ているという理由だけで、チームを一瞬たりともオートパイロットに任せてはならない。多くの設計変更、懸案解法、相互の誤解などは、この段階になってもまだ潜んでいる。チームリーダーは、絶えず歩き回り、進捗を妨げたり目的を逸れさせたりする潜在的な問題に鋭い目を向けておく必要がある。

One of the clear facts of systems programming is that when the team encounters an obstacle in the road, they will wait for the team leader to decide whether they should take another route, clear a path through it, or simply ignore the fact that it exists. The challenge for the team leader is to maintain an awareness of when these roadblocks are springing up, and to ensure the correct response is being taken. In order to fulfill this responsibility, the team leader must maintain:
システムプログラミングにおける明らかな事実の1つは、チームが途中で障害に遭遇した時、迂回するか、突破するか、単に無視するか、チームリーダーの判断を待っている事である。チームリーダーの仕事は、問題の発生に気付き、適切な処置が確実にとられる様にする事である。その為には、次の事を続けなければならない。

• Active participation in issue resolution sessions
• Active participation in selected code walk-thru meetings
• Active team "pulse checks" by regularly wandering around
• Active requirement, issue, and enhancement gathering
• Active contribution to the final delivered product.


• 懸案事項対策会議への積極的な参加
• 幾つかのコード・ウォークスルー・ミーティングへの積極的な参加
• 定期的に巡回し、積極的にチームの"状態チェック"
• 要件、懸案事項、改善の打ち合わせへの積極的な参加
• 最終納品への積極的な貢献

All of these will give the team leader the intelligence he or she needs to accurately assess the state of the phase, as well is ensuring that decision making and guidance is present in a timely and efficient manner. In addition, it minimizes the occurrence of unexpected surprises, which if found out too late, can cause unnecessary delays or frustrating rework for the team.
これにより、チームリーダはフェーズの状況を判断するのに必要な情報を得て、判断や指示がタイミング良く、的確に出せる様になる。さらに、発見が遅れると余計な遅れや詰まらないやり直しを引き起こす不測の事態の発生が最小に抑えられる。

Copyright © 1999, Russ Finney, All Rights Reserved