本来、ソフトウェア・エンジニアなどの“エンジニア”というのは「プロ」であるべきと思っています。少なくとも、「アマチュア」の状態で通用する職業ではありません。
一般職の「経理」という職業も、２１世紀には「プロ」化している可能性があります。かって就職氷河期に大勢の女性が職を求めて香港に殺到しました。即席の経理の知識を詰め込んで香港に渡ったわけです。日本では、それで十分通用するのでしょうが、昨年あたりから、現地の人で経理や会計学を勉強した人が、日本人を逐うように進出しています。報道によると、彼女達は監査一歩手前のレベルのようです（「香港で仕事を奪われる日本人労働者」）。この現象は、いずれ日本にも上陸するでしょう。そうでなければ、日本の企業だって「生産性」を確保することはできません。
一般企業に於ける経理職が「プロ」化しようとしているのに、ソフトウェアの“エンジニア”が「アマチュア」のままで済まされる訳はありません。
私が考えている「プロ」であることの条件は、以下の３点を備えていることです。
１）約束できること
２）常に変化させていること
３）人間的であること
もちろん、これ以外にも、幾つかの条件が考えられますが、それらも、上記の３点をクリアしたうえでないと意味を持ちません。
仕事というのは、そもそも「約束」に始まり、「約束」に終わるものです。「プロ」であれば、顧客の求めることを「約束」でき、かつ、それを実現できなければなりません。もちろん、顧客の要求は、だいたいにして厳しいものですし、そのように感じるものです。しかしながら、それが厳しく感じるのは、自分だけかも知れません。市場の要請が既にそのレベルであるなら、それを厳しく感じる自らのレベルは低いことになります。「プロ」として通用しないレベルかも知れません。
「プロ」であるなら、顧客の要求に潜む矛盾や欠落を指摘し、最適な要求に仕上げるのに協力できなければなりません。この点でも、しばしば首をかしげる場面に遭遇します。顧客の要求に矛盾があることを承知で、そのまま作業を続け、最後に「それは言われていないこと」とか「顧客の要望にミスがあれば、結果はこうなるのは当然」などと、居直る場面を見ることがあります。彼らは「プロ」ではない。
「約束」は、一般には開発期間であったり、機能や性能（品質）であったり、コストであったりしますが、その中には、ドキュメントの品質なども含まれます。もちろん、ソフトウェア製品が使用に支障を来すようなバグが含まれていないことは言うまでもありません。「プロ」は、仕事を“する”ことを求められているのではありません。「約束」に対する“結果”を出すことを求められているのです。
そのためには、色々な“解決方法”を持っていなければなりません。要求仕様書の書き方も、状況に合わせて使い分ける必要があります。分析法方や設計方法も何種類か持っていることが求められるでしょう。抜かりなく作業を進めるためのスケジュールの表現や、その進捗を管理する方法も持っていなければなりません。テストやデバッグの方法も、何種類か必要でしょう。
その他に、人のドキュメントを素早く読む力や、ソースリストを読む力も必要でしょう。そのうえで、何種類かのレビューの方法を体得していることも必要でしょう。
もう一つ、「約束」を実現するためにとても重要なものがあります。それは、自らの状態を観る力です。残念ながら多くの人は自分を誤魔化しながら作業を進めています。「こうした方がいいかな」と思いながら、結局のところ何もせず、後になって「バグ」となって噴き出すのです。バグは向こうから入ってくるのではないのです。その人が呼び込んでいるのです。バグを敵視するポーズを取りながら、その実は、その人の一挙手一投足がバグを部屋に呼び込んでいるのであり、その人の浮かべる言葉が、バグをソースの中に潜り込ませているのです。
必要なプロセスを不用意に省いてしまった自分に気付かなければ「プロ」ではありません。したがって、「プロ」は、そのような「自分」が観えなければなりません。そして、常に自分を最適な状態にコントロールできることが条件です。
「プロ」は常に自分を変化させなければなりません。市場の要請が絶えず変化している以上、顧客の要請も変化します（市場の要請についての認識／迫り来る市場の要請）。そして「約束」はこの「要請」に基づいている以上、「約束」を実現させる方法も常に変化させなければなりません。
そのためには、市場の要請の変化を常に監視していなければなりません。新しい手法や考え方の提案は、市場の要請が変化したこと（あるいは変化の必要性が生じたこと）の現れでもあります。ソフトウェア・エンジニリングに関する適切な雑誌を追跡したり、時代の要請の変化を捉えた、ワインバーグやデマルコ、ヨードンなどの本も読んでおく必要があります。もちろん、単に読むだけではなく“感じる”ような読み方が必要であり、その中には実際に行動することも必要になります。
そうして、新しい時代の要請に通用する方法や考え方を取り入れることです。それに着手した時期が早ければ、習得にかける時間が十分にあります。でも、そこで行動を起こさないで放置していれば、あ〜っという間に数年は過ぎてしまいます。
変化のための時間を確保できないのは、見積もりの問題であり、スケジューリングの問題です。これは明らかに「プロ」の条件です。これが出来なければ、何も始まらないのですから。
要求仕様書の書き方
見積もりのための技術とそれに基づいた詳細スケジューリング
分析・設計手法
適切な言語やその背景となる考え方やアイデア
手法やアイデアを支援するツール
テスト技法やデバッグ技法
構成管理や変更制御の考え方とその実施方法
ノウハウや問題を「共有」するための環境や方法
時代にそったレビューの方法
など、ソフトウェア・エンジニアにとって変化させる必要のある項目は沢山あります。これらの内、すでに幾つかの項目について、時代の要請するレベルを有し、さらに残りの項目についても、日々怠ることなく更新できることが「プロ」の条件です。「庵主の日記」でも述べたように、「ソフトウェア」の世界は、もう誰にでも出来る世界ではなくなっているのです。「自習」のできない人が活躍できるような職場ではなくなっているのです。時代にあわせて変化させることが出来なければ、たとえ今、この仕事に就いているからといって、必ずしも２１世紀も優先してこの仕事に就くための「優待券」にはならないのです。
もう一つ、私の独断的選考で、念のために「人間性」を失っていないことを挙げておきたいと思います。仕事は出来ても、「喜怒哀楽」を解せないならば、私は「プロ」とは認めたくないのです。「仕事が人をつくる」と言います。仕事の仕方次第で、人の性格まで変わってしまいます。優れた仕事の仕方を体得していれば、人間性を損ねることはないはずです。
逆に、仕事の上手な仕方を知っている「プロ」ならば、相手を思う余裕もあるでしょうから、実際には、この問題はそれほど心配することはないのかも知れませんが、若干の危惧を感じますので、敢えて項目に挙げることにしました。それは、ソフトウェア・エンジニアの多くは、プログラミング言語や、オブジェクト指向などの“技術書”は読んでいても、哲学や倫理、あるいは人間について考えさせられるような書物を読んでいる人は非常に少ないからです。
もちろん、技術を“極めれば”、同じところに到達できると考えられますが、それには時間がかかり過ぎます。ある程度の時間の中で、人間の喜怒哀楽や、人としての基本的な振舞いなどについて、その人としての考え方をもって欲しいと思います。そのために、考えるきっかけを適切な書物や人から得ることが必要です。「プロ」なら、技術書を読む間に、そのような機会を作って欲しいと思います。
「仕事は、その人の全人格の成果」であるというのが、私の基本的な考えです。実際、その人の人格は、プログラムの中に現れます。ハードウェアの世界以上に、ソフトウェアの世界は作者の「人格」を映します。