読者です 読者をやめる 読者になる 読者になる

secretbase.log

コードはすべてNYSLです

10年間ソフトウェア開発に携わってきて学んだひとつのこと。

2001年にメーカ系システム開発会社に転職しました。
約10年間、半導体製造装置のひとつの製品に携わってきました。
今年度から別の部署に異動することになりました。

そこでいろいろなことを学ばせていただいた中で
ひとつだけ記しておきたいと思います。
f:id:cointoss1973:20110402010009j:image
コンテキストはこんなかんじです。
・メーカ系ソフトウェアエンジニア
・開発システム半導体製造装置
・システム開発部署、仕様書作成部署、ハードウェア部署のセクションがある
・システム開発部署は20〜30名


システム部署の仕事とは

システム開発部署は、仕様書作成部署の設計仕様書とハードウェア部署の
ハードウェア仕様に沿ってプログラムを作成する部署と理解されている方が多いと思います。

また、きちんとした設計仕様書から正しい概要設計書、基本設計書を
作成すれば、よい品質のプログラムができると考える方も多いと思います。

しかし、概要設計書、基本設計書があれば誰でも同じ品質のプログラム
ができるかというとそうではありません。

それは、設計書からソースコードにする方法(実装)には
いくつか選択肢があり、その時点で必ずしも良い選択ができるとは限らないからです。
では設計書にもれなく記載すれば良いのでしょうか?


より良い設計を求めて

設計書は、書かれた時点の設計情報が記述されます。
それはその時点のものです。いわばスナップショットです。
もれなく詳細に記述すればするほど設計書の"賞味期限"は短くなっていきます。
また、設計初期の早い段階で詳細まで決定してしまうことは、良いアイデア
を制限してしまい改良の余地が少なくなります。
さらに要求自体が変化したり追加されたりといったことも発生します。

もし完全な(ここでいう完全とはプログラムをこうつくって欲しいという
設計情報がもれなく記載されたもの)設計書というものがあるとすれば
それは MS-WORD で日本語で書かれた文書ではなく、ソースコードそのものになります。

品質の良いプログラムにするためには

設計書はある程度の粒度を保った物をつくります。
ではそこから良いプログラムを作成するため、良い選択をするためにどうすればよいでしょうか?

重要なことの一つに、関連部署とのコミュニケーションになります。

  • 設計仕様のインプットとなる要求仕様部署
  • ハードウェア仕様書がインプットされるハードウェア部署
  • 装置を現場で保守するフィールドエンジニアからの要望

またわれわれの職場では難しいですが、エンドユーザから直接話を聞いたり
することで、システムに対する本質的な要求やハードウェアの仕様を理解し
より正しい選択ができるようにすることです。

設計仕様書や、ハードウェア仕様書になぜそのような記述があるかの情報を吸い上げるのです。
良い情報を得るためには関連部署と良い関係を築いておくことが大切です。

関係部署と良好な関係を築くために

私が心がけていることは、まず他の部署の担当者に自分の担当箇所を理解してもらうことです。
そして他部署の関係者の担当を知り、現場レベルでの生の意見(改善してほしいこと)
を聞くことでお互いの関係を深めるようにしています。

うれしいことに私のいた半導体製造装置部門では、ハードウェア部署、
仕様部署のほとんどの方は、要求の本質を理解しあるべき姿について
話し合いがしやすい風通しの良い職場でした。

最後に

今年度から、半導体製造装置部門だけではなく横断的な組織に異動しました。
少なくとも3年間は新製品開発およびソフトウェア開発インフラの導入推進や教育に
携わることになります。

3年後に状況とタイミングがあえば、その間に得た知識、スキルを
半導体製造装置にも反映できることを望んでいます。

ありがとうございました。