ソフトウェア開発は、ソフトウェア工学の知識と職人的能力を必要とする仕事です。

如何なる仕事であれ、形式知のみでこなすことはできません。熟練者がいて、熟練者のもつ暗黙知を後継者が引き継いで行くことにより、維持・発展・進化します。後継者は、プロジェクト開始時に、十分な知識や熟練度を持ち合わせていなくても、プロジェクトに参加しながら、能力を身につけます。

ソフトウェア（日本のビジネス処理系ソフトウェア）開発の現場を覗くと、ソフトウェア工学知識に偏重したマネジメントを行なっているケースがあります。技術文書に書かれた知識（形式知）に精通していれば、いかにもソフトウェア技術者であるかのような誤解もあるようです。ソフトウェア工学の成果を記述した技術文書は、実際の仕事で成果を上げた方式等を広く知ってもらうために書かれた文書です。しかも、著者は内容を整理・洗練しようと努力していますから、一種のモデルと言っても良いものです。仕事を進める上では必要な知識ですが、実際のソフトウェア開発の現場では、そこには書き表わされていない、たくさんの泥臭い問題に遭遇します。例えば、

（１） 　顧客が、IT化したい業務を明確に認識していない場合、ソフトウェア要件を聞き出すのは容易ではありません。中にはベンダーにはいつでも要求できると思い、プロジェクトが中盤にさしかかっているにも係わらず要求を出してくる顧客がいます。このような危ない顧客には、プロジェクト開始前に、システム構築の手順をしっかりと理解しておいてもらわなければなりません。
（２） 　ソフトウェア開発の人材の調達は困難を伴ないます。対象となるソフトウェアがどのような技量を備えた人材を何人必要とするかを見極めるには、熟練したシステム技術者の判断に委ねる必要があります。また、要件を満たす人材が直ぐに集められるわけではありません。優秀な技術者ほど集めにくいものです。必要な人材は育てなければなりません。
（３） 　方法論はプロジェクトの状況に合わせて選択する必要があります。プロジェクト毎にどの方法論が適切か、細かな部分はプロジェクト遂行中に調整します。型紙に合わせたようなやり方で仕事をすれば無駄な作業が生じるだけでなく、失敗の種となります。
（４） 　その他、顧客、システム技術者、プログラマ間の良好な連係プレー、良好な人間関係、マネージャーのリーダシップ、予測される問題の回避、・・・。

などは、ソフトウェア工学では扱わない問題ですが、ソフトウェア開発を成功させるための重要なノウハウです。このようなノウハウは他にも数え切れないくらいあります。

ソフトウェア開発をソフトウェア工学に則って行う場合でも、成功するプロジェクトには優れた熟練技術者が大きく貢献していることを見逃すことはできません。

著書『ソフトウェア職人気質』（ピート・マクブリーン著/村上雅章訳　株式会社ピアソン・エデュケーション）によりますと、ソフトウェア開発においても、伝統的な徒弟制度における熟練職人（Craftsman）、徒弟奉公を済ませた一人前の職人（Journeyman）、徒弟（Apprentice）と同様の人材が存在し、ソフトウェア開発における徒弟制度を積極的に取り入れることにより、ソフトウェア工学の限界を補完し、一層の生産性・品質向上に貢献できると述べています。

本書で言うソフトウェア開発における徒弟制度について簡単に紹介しましょう。徒弟は学校でソフトウェア工学を修めたか否かに係わらず、実際のプロジェクトに参加し、熟練職人や職人と一緒に行なう作業を通して多くのことを学び体得し、一人前の仕事ができるまで修行します。ここで得るものは単に技術的なことだけではありません。仕事への取り組み姿勢・態度と言った精神的なものまでも学習するのです。小規模のソフトウェアならば独自に開発できると、熟練職人から認められたとき、職人となります。職人は熟練職人と密着してプロジェクトに参加し、ソフトウェアの重要な部分に責任を持ちます。職人同士は刺激し合い、一つの専門領域に閉じず、ソフトウェア全体に意識を向け、永続的に学習し、仕事を行ないます。顧客や熟練職人、職人から信頼や高い評判を得るようになると、熟練職人として独り立ちするのです。熟練職人は、職人や徒弟と仕事を共にしながら、彼等を指導すると同時に自らも彼等から刺激を受け、技量に磨きをかけるのです。

本書に書かれている熟練職人（Craftsman）や職人（Journeyman）は、自己の技量を深めるため、いろいろなプロジェクトを渡り歩き、人脈を築き、ついには評判の高い熟練職人になることを目指しているのですが、優秀な技術者の囲い込みをしたがる日本企業では、著者が言うような徒弟制度は馴染みにくいでしょう。日本独自の徒弟制度を模索する必要があります。

それでは、日本ではどのような徒弟制度が相応しいのでしょうか。私は、前稿「プロジェクト管理における暗黙知と形式知（その１）、（その２）、（その３）」で述べたような、組織的に暗黙知を継承する方法が適していると考えています。

しかし、この方法の適用にはいくつかの障害があります。

１つは、大企業が熟練職人を育てる環境にないということです。具体的には、次のことを指しています。

（１） 　ソフトウェア熟練職人になるには、ソフトウェア熟練職人の下につき、書物からは得られない暗黙知を実際のプロジェクトに参加して継承されるのですが、大企業には熟練職人がいないのです。ソフトウェア熟練職人になるには１０年～２０年以上の経験を積む必要がありますが、ソフトウェア熟練職人になる前に、管理職の道を選択させられ、結局は管理者になってしまうのです。
（２） 　大企業にあるのは、小規模企業にない、仕事のチャンスです。そこで、大企業はソフトウェア熟練職人が比較的集まっている中小企業に仕事を発注し、その場をしのぐことになります。大企業の仕事は、顧客から受注した仕事を取りまとめる仲介業者的な仕事になっています。ソフトウェア産業は良くゼネコン（General Constructor）と比較されますが、似た産業構造をしています。
（３） 　大企業は科学的管理法を重視し、徒弟制度を軽視する傾向があります。ソフトウェア熟練職人になるにはソフトウェア工学を身につけていなければならないのは当然ですが、ソフトウェア開発の職人的側面の重要性を認識していない経営者が多いのです。

　このような事態になっているのは、大企業の人事制度がソフトウェア開発の人材育成に合致していないからなのです。大企業は現在の利益を求めて、目まぐるしく方向を変えます。俯瞰すると、「これからはグローバル化だ」、「これからは品質管理だ」、「これからは環境問題だ」と、付和雷同しているように映ります。人事部もそのような事業戦略に合わせるように行動しますから、ソフトウェア開発の熟練職人を育てることができないのです。人事部の人たちはソフトウェア開発の熟練職人がどのようにして育つかを全く理解していないのかも知れません。ソフトウェア職人の人事はソフトウェア熟練職人に任せるのが妥当で、人事部に任せてはならないのではないのでしょう。

この大企業の悩みはどうすれば解決できるのでしょうか。経営者が「ソフトウェア産業は基幹産業」だということを認識する必要があります。この認識がなければ、将来に亘って、ソフトウェア開発の熟練者を育てる気にならないでしょう。そして、ソフトウェア熟練職人を育てるために、人事制度を変え、ソフトウェア開発を一生の仕事として認め、処遇する必要があります。ここで注意すべきは、認定制度を導入しないことです。認定制度は知識があることを認定するだけです。仕事ができることを認定するのは、熟練職人や顧客の評判です。経営者がすべきことはこれだけではありません。最も大切なことは、ソフトウェア熟練職人がもつ付加価値を事業に活かすことです。ビジネスとして循環するようになってはじめてソフトウェア熟練職人を育成する意味が生じるのです。

一方、小規模企業では、暗黙知の継承は比較的容易です。しかし、経営的には人材を育成する資金・対象領域の広がりに課題が残されています。

小規模企業の社員は大企業の社員以上に独立心が強い人材を集めなければなりません。独立心が強い人材は努力して仕事のノウハウを習熟しようとします。自らソフトウェア熟練職人として一人前の扱いを受けるよう動機付けることです。小規模企業はソフトウェア工学の知識や暗黙知習得の機会を提供しますが、そのために特別の資金を用意する必要はありません。独立して行くソフトウェア熟練職人には仕事でのつながりを維持するようにします。その結果、独立し易くなり、ソフトウェア熟練職人が互いに仕事を回し合うようになります。

１つの小規模企業で習熟できる対象領域は絞られるかもしれません。しかし、ソフトウェア職人は他の領域でも応用が効く力を身につけます。市場は変化しますので、ソフトウェア熟練職人はその変化に合わせて、得意領域を探っていく努力を怠ってはなりません。

小規模企業のもう１つの課題は、人材の定着です。小規模企業には優秀な人材がなかなか定着しません。理由は事業の安定性がないこと、ソフトウェア熟練職人への道が見えない不安からです。小規模企業であっても、得意領域をものにして、評判を得ることにより、優秀な人材は集まるはずです。人材を育て、巣立ちを喜び、その繰り返しで、事業を継続できれば成功と言えるでしょう。■