engineering

先程の記事「顧客と同じ意識に立つ」で書いた、

できるだけ、顧客と同じ意識に立つ。その上で、エンジニアとしての専門性を提供出来る。そういう仕事をしたいと思います。

という文章で、「エンジニアとしての専門性」という言葉を出したので、それって何だろうかと考えてみました。

全文を読む

「ソフトウェア開発プロフェッショナル」に、ACMとIEEE Computer Societyの両方で採択されたソフトウェア・エンジニアリングのための倫理規定と実務規定の翻訳が掲載されていました。
ソフトウェア技術者の皆さんには、ぜひ何度でも読んで欲しい文章です。私は読んでみて、身震いがするほどでした。

ソフトウェア技術者は、ソフトウェアの分析、仕様決定、設計、開発、テストおよびメンテナンスにおいて、有益で尊敬に値する専門職となるべく、最大限の努力を尽くさなければならない。社会の人々の健康、安全、福利に対する責務に従い、ソフトウェア技術者は以下の8原則を遵守せねばならない。

１．公共性 ソフトウェア技術者は、公共の利益と調和するように行動しなければならない。

２．顧客および雇用者 ソフトウェア技術者は、公共の利益と調和しながら、顧客と雇用者の最高の利益を実現するように行動しなければならない。

３．製品 ソフトウェア技術者は、その製品と、それに伴う変更が、専門家として可能な限り最高の水準に合致していることを請け負わなければならない。

４．判断 ソフトウェア技術者は、専門家としての判断において、誠実さと独立性を維持しなければならない。

５．管理 ソフトウェア・エンジニアリングの管理者とリーダーは、ソフトウェア開発の管理ならびにメンテナンスの管理に対する倫理的アプローチに賛同し、それを推し進めなければならない。

６．専門職 ソフトウェア技術者は、公共の利益と調和するよう、その専門職の誠実さと名声を高めていかなければならない。

７．職業上の同僚 ソフトウェア技術者は、他のソフトウェア技術者に対して、公正で協力的でなければならない。

８．自己の向上 ソフトウェア技術者は、自己の専門職の実務に関する、生涯続く学習に参加し、かつその専門職の実務に対する倫理的なアプローチを推し進めなければならない。

本書では、ソフトウェア技術者が、医師や弁護士、公認会計士と同様に、専門職としての領域と名声を確立するという方向性を提唱しています。免許制度の整備についても言及し、その暁にはソフトウェア技術者が個人として法律上の責任を負い、非現実的なスケジュールの強制や、目先に捕らわれた設計への妥協、ソフトウェアを無理に出荷するために品質を犠牲にせよという求めに対して、「私の職業倫理の基準では、この状況の品質のごまかしを認めるわけにはいきません。これを認めれば、私の免許は取り消されるか、訴えられるでしょう」と言うことになる－と言うのです。

これこそが、私が求めていたもの。プロフェッショナルなソフトウェア技術者としての誇りです。これだけの誇りのある職業であるということを、しっかり認識することが出来れば、その道を究めていこうというモチベーションにもなるものです。

とにかく、お勧めの1冊です。

ソフトウェア・エンジニアリングの倫理規定と実務規定の5.2版（日本語訳）が、こちらにありました。

この週末、自分が10年やってきたソフトウェアエンジニアリングの仕事を、本当の意味で好きになるために、勉強し直してみようと決意しました。
で、手始めに「ソフトウェア開発プロフェッショナル」という本を読み始めたのですが、いろいろと思うことがあって、盛んにつぶやいていたので、今日のつぶやきをまとめておこうと思います。

• ソフトウェア開発の市場は大変に大きい。しかし、多くのプロジェクトは必ずしも成功していない。成功させる確率を高める方法、スキルがあれば、ビジネスチャンスはある。
• あくまでソフトウェア開発。ただ、診断士の勉強も、新たな着想を得る方法として、一定の効果は期待できる。
• いま読んでいる本、「ソフトウェア開発プロフェッショナル」。もっと早く出会いたかったが、今ほどの感銘を受けるには今でないと駄目なのかもしれない。
• 職業としてのソフトウェア開発者と、プロフェッショナルとしてのソフトウェア開発者は異なる存在。少なくとも、自分はプロフェッショナルの側に立ちたい。
• SEが業務を分析して整合性をとってソフトウェアを設計する能力ってなんていうの？
• たぶん、それがSEの中核的能力で、自分がいちばん得意なことだと思うんだけど、それがキャリアシート上で設計経験年数程度のことにしかならないのが悔しいね。年数だけなら、誰でも同じだよ。
• たぶん、そういう能力はソフトウェアの設計以外でも役立つんだろう。なんか、そういうことを的確に示す言葉が欲しい。ソフトウェア工学とかかな？

私は昔から「プロフェッショナル」という言葉に弱いので、というかプロフェッショナルになりたいという気持ちが大変に強いので、「ソフトウェア開発プロフェッショナル」というタイトルがまず心の琴線に触れるわけです。
やれSEは3Kだとか、いや5Kだとか、自虐的な言葉が跋扈しているわけですが、もっと誇りに感じられるようなことが語られるべきだろうと思います。

モチベーションを鼓舞する意味合いでも、書いている内容そのものの意味でも、これからの自分のバイブルになり得る1冊だなと思っています。
読み終わったら、またきちんとまとめます。

「ソフトウェア開発基盤」は、便利な言葉であるが、言葉の定義がはっきりしない曖昧な言葉でもある。

主にSIerのソフトウェア開発事業を紹介する文脈で出てくることが多く、概ね、フレームワークと開発プロセスの組み合わせとして構成されている。

フレームワークの訳語として「ソフトウェア開発基盤」を使っている例も見受けられる。そもそも、「フレームワーク」自体も定義が曖昧な言葉である。

SIerにとってソフトウェア開発基盤とは、

• 自社の特定領域における技術力と、
• その領域における開発能力（技術者○○人の体制で・・・といった文脈）

を誇示するためのものである。（外面的には）
顧客に対する、実現力の証左といえる。

内面的に、ソフトウェア開発基盤を意味のあるものにする（外面的な能力誇示を真実足らしめる）ためには、

• 開発プロセスをPM層が完全に理解し、必要に応じて組み立てなおしができること。
• 開発プロセスをSE、PG層が理解し、自身の作業をプロセスにリンクさせられること。
• フレームワークを理解したアーキテクトが存在し、自身のプロジェクトにマッチするような対応が取れること。
• フレームワークをSE、PG層が理解し、自身の設計やコードを準拠させられること。
• フレームワークが必要十分な機能を備えているか、不足した機能を追加開発できる機能を備えていること。
• 開発プロセス、フレームワークを真に活用するためのツール群が整備されていること。

が重要と考える。

一方で、ソフトウェア開発基盤は、進化を続ける技術を、ソフトウェア開発基盤を採用する組織において固定させる結果をもたらす。技術の固定は、初心技術者にとっては学習目標の明確化につながるため望ましいことである。しかし、技術の固定は技術の進化から取り残される結果にもつながる。SIerにとって、技術の進化から取り残されることは、自身の存在意義を（少なくとも部分的に）否定するものである。

ソフトウェア開発基盤を推進するにあたっては、

• 将来性のある筋の良い技術の選定。
• ソフトウェア開発基盤を進化させていける体制の構築。
• ソフトウェア開発基盤を重視しつつ、そこに留まらず、乗り越えた発想を持てる技術者の育成。

が必要である。

やりやすいところから再利用を

システム開発において、「再利用」は使い古されたキーワードです。
例えば過去の構造化プログラムにおけるモジュール分割や機能による関数分割であったり、最近ではオブジェクト指向プログラムにおけるクラス分割は、手法は違うとしても目的は再利用可能部分を最大化することを目的としていると思います。

ただ、どうしても再利用が上手くいっているというケースは多いとはいえないのではないでしょうか？特にビジネスロジックの部分（これを機能用件といいます＝クライアントがシステム化を希望する理由であり、かつシステム化を希望する部分です）の再利用は困難がつきまといます。いわんや、機能用件はクライアントによって千差万別であり、クライアント企業のビジネスプロセスは同じモノはないと考えられます。

システムを受託で開発するようなケースで、ビジネスロジックの開発をヒアリングから始めて実施するようなことは多いと思いますが、そこで再利用を前提とした開発を行うとなると、そのクライアントにとって不要な機能や、オーバースペックな機能を「再利用を前提とする」という旗印の下に実装しなければならないことになります。そして、それは無理が付きまといます。そのコストは？それによる納期の遅れをクライアントは待ってくれるのか・・・？

そうであっても、今後、システム開発における再利用は進化すると考えます。おそらく、それは「コンポーネントビジネス」として成り立つことになると思います。あくまで「それをビジネスとする」というところがポイントでしょう。システム開発会社が自社用に「おまけ」的に取り組む再利用ではなく、コンポーネント会社のようなものが多くの企業のシステム開発において幅広く使われるコンポーネントを、そのために作り、ビジネスとする・・・。システム開発会社はそのコンポーネントをいかにクライアントの希望に沿うシステムと見比べてチョイスし、組み込んでいくという姿になるのではないでしょうか。それが実現可能な機能用件の再利用になるでしょう。

一方、機能用件の対義語として「非機能用件」というものがあります。システムをシステムとして成り立たせるためには機能用件だけでは十分ではなく、必ず非機能用件が必要となります。それは例えば、使用するデバイスであったり、ミドルウェアであったり、さらにはWebシステムなどのシステムの構成形態を指します。クライアントはWebシステムを作りたいのではありませんし、特定のミドルウェアを使って欲しいのでもありません。あくまで「自分の要求を満たす機能をコンピュータ・システムとして実現して欲しい」のです。（最近では、クライアント側が非機能要件を指定することもあります。例えば「Webシステムとして作って欲しい」であったり、「モバイルに対応して欲しい」など）

例えばWebシステムというシステム構成の非機能用件は、大抵の場合、構成が似通っています。モバイルに対応するために必要となる実装手段も、どんなシステムであっても似ています・・・。これこそが、再利用の対象になるに違いありません。（つづく）