地方からの戯言

　開発業務に携わる方たちだけではなく、多くの方々は、仕事でも仕事以外でも「ドキュメント」を書いていることと思います。業種によっては、ドキュメントを書くことが本業で、それ以外の業務の割合が少ない、という方もいるのではないでしょうか。

　私が属する開発業務の世界でも、やはり多くのドキュメントを書くことがあります。それは設計書であったり、ユーザーや受注元とのやりとりであったり、いろいろな種類のドキュメントを書きます。

　こと開発の世界に限ると、ドキュメントを書き記す理由は大きく分けて2つあります。

　1つは、「今システムを作るために必要であるため」であり、もう1つは「後で何か不慮の事態が起きた際に利用するため」です。開発標準として多くのドキュメントが定義されていますが、このコラムを読んでいる皆さんは、標準をアレンジしていることが多いのではないでしょうか。

　基本としてドキュメントは必要なもの、というのは疑う余地のないところだと思います。ですが、ドキュメントを書いているときには、「これは本当に必要なものなのだろうか」と不思議に思うこともあるのではないでしょうか。

　作成される大量のドキュメント、しかしその大半はその後日の目を見ることもなく、ファイルキャビネットやファイルサーバの中で眠り続けることも多々あります。もちろん「万が一の事態のため」という目的もあるので、一概に日の目を見ないことが悪いと言い切るものではありません。しかし中には「実は不要なもの」「今の時勢に合わないんもの」であり「体裁を整えるため」に、とりあえず作るだけ作ってしまうものも紛れ込んでいるのではないでしょうか。

　そういった類のドキュメントが増えるに従い、現場にかかる負担は増加していき、本来やるべきことができなくなるという悪循環を生みだします。そのような状況に陥るのは、大抵せっぱつまってきたころになりやすく、弱り目に祟り目というか、なんとも言い難い状態になることもそう少なくはありません。

　個人的に考えるのは、ドキュメントというものは「必要な種類」のものを「必要な量」作成できることがベストであり、種類が少なくても量が多くてもあまりいいことではないということです。

　ただ、難しいのは、「適した種類」と「適した量」を作るということです。携わる案件の規模にもよるでしょうし、関わる人々の求めるレベルにも左右されるでしょう。ある案件の際は小規模であってもしっかりしたレベルのドキュメントを大量に求められたり、別の案件では要件定義や詳細設計など、必要最低限なものだけでよいというように、さまざまなケースがあります。

　この辺りを考えると、標準的なドキュメントでも、場合によってはそれほど重要視しなくてもいいのではないか、と考えることがあります。もちろん必要がないのではなく、体裁を整えるために時間を費やしたりする必要がない、という意味合いでですが、「見てくれ」よりも「中身重視」で進めることがあってもよいのではないでしょうか。

　極端にいえば、開発途中であれば体裁は二の次で、中身の記述がはっきりとしていればよく、レイアウトが微妙にずれているとか、多少冗長な記述があるとか、本質的な部分から外れる点においては「後で」修正する方法をとることも、1つの進め方です。

　もっと進めれば、議事録は音声や動画だけで最初は済ませてしまうとか、要件定義も詳細設計も最初の時点では箇条書きレベルでも許してしまうとか、「あるのが望ましい」ものならばいっそのこと「悪いけどない」としてしまうのも、一概に間違った方法とはいえません。実際のものづくりに集中できれば、それはそれで良い方法なのだと考えます。

　このような考え方を進めると、開発に付随するさまざまなイベントにおいても力を入れるべきところに力を集中し、抜いてもよいところは抜く、というメリハリのきいた仕事ができるようになるかもしれません。例えばドキュメントのレビューは大事なイベントですが、そこで行うのは体裁よりも内容にのみ限定するとか、コードレビューも同じように内容に限った点を集中的にレビューすることで、その時点でかける必要のない力を、別のところに割り振ることもできるようになるでしょう。

　各フェイズごとにしっかりと体裁も整えられたドキュメントを作成できるのは非常に素晴らしいことです。ただそこに時間を費やすあまり、本来の目的がおろそかになってしまうようであれば、一度そのバランスを見直すことも大切なのではないでしょうか。ドキュメントが揃っていたとしても、一番大事なシステムやアプリケーションがなければ、ただの資料の集まりでしかないのですから。

　これを書いている私自身、このように仕事が進められればいいな、と思うほど、理想が混じっています。現実の現場では「そうは言っても体裁よく作らないといろいろなところにマズイでしょ！」という状況であることばかりです。ですが、理想だからといって、諦めずに常に良い方向へ改善できるよう、少しずつでも考えていきたいです。

　昔と比較すると、いろいろなものが大きく変化してきていますが、開発の中で大きく変わったことの1つに、「1行で表す処理内容」があるのではないか、と最近感じます。

　非オープン系であればステップ数というかコードの行数が1つの目安であったこともありますが、ここ数年でこのコードの行数というものに対しての考え方が大きく変わってきたようにも思えます。

　以前は、1行で行う処理内容はできるだけ簡潔に、という風潮が強かったことと思います。個人でのプログラミングであれば、1行に複数の処理内容を記述するマルチステートメントも使われましたが、これはコードを見る相手に一定以上のレベルを求めるため、業務で開発を行う世界ではできるだけ利用しないようにルール化されていたところが多いのではないでしょうか。

　その後オブジェクト指向言語が増え、それにともない1つのメソッドに対しての行数に対して目安が設けられました。一画面に収まる程度でのコーディングを規約としているところも多いと思います。

　このオブジェクト指向言語が台頭したあたりから、1行で行うことができる処理量がそれまでとは比べものにならない程増えました。メソッドの戻り値やプロパティーの値から、さらにメソッドやプロパティを呼び出すロジックは、今では極々当たり前の記述となっています。

　さらに昨今では、匿名関数やLINQ、新しいものでは Reactive Extensions などが登場し、1行で行える処理量は増え、さらに複雑なことを行えるようになっています。

　もっと言えば、ここでいう1行というのは画面上での1行と関係は無くなっています。エディタ上では複数行に見えても、ブレークポイントを定義してみると1行だった、ということも多々あります。

　また反対に、まったくコーディングを行わずに処理を行う事も可能になっています。個人的に興味を持っている Workflow Foundation もそうですし、パラメータだけの設定でメンテナンスプログラムを作成するようなユーティリティも古くから存在しています。

　このように変化してきたことを踏まえると、プログラムやシステムを「コーディングの量」で判断することには、大して意味が存在していないでしょう。ライン数やステップ数では、コーディングの結果作り出したものの価値は計れないのです。

　そのような状態でステップ数等を何かしらの判定基準に利用することは、せいぜい労働時間、作業時間を計る1つの目安にしかなりえません。クラス数やアセンブリ数であっても同じで、判断材料として利用するにはとても相応しくないものなのです。

　他にも判断材料として用いられるものとして、「人月」についてはかなりの方が問題を含めていることを認識されていると思います。そしてそれを解決するベターな方法もまだ存在していないこともご理解されていると思います。

　しかし、実際には人月は物凄く基準として利用しやすく、ある種共通的な認識が出来上がっている土壌だと感じます。私は、開発側が利用者側に人月を用いて価格を示すことにはそれほど反対ではありません。これに変わる何かが見つかるまでは、人月を利用して構わないと思います。

　私が問題と感じているのは、企業内部での判断に人月的な思想だけを持ち込むことで、「何人月の作業を行ったのか」それだけで判断されることです。判断を行う際には、かけた時間量だけでは不足で、実際にはなんらかのレベルを示すようなものが、業界基準として必要なのではないでしょうか。ITSS や国家資格、民間資格等はそのために利用されるのが望ましいのではないか、と考えます。それに加えて実際の作業結果が重要になるのだと思います。

　ある人が 1カ月かけて作成できる量は、別の人にとっては 3 日で終わる量かもしれません。このような状態を正しく利用者に伝え、その上で判断されることは開発側にとっても利用者側にとっても、お互いに幸せな方向へ向かうことができるのではないでしょうか。もう少し業界内部での、開発者それぞれでの切磋琢磨は必要なのではないでしょうか。

　特定企業だけで通用する判定基準はあまり価値のあるものではないと思います。業界を統一する、何かしらの公的な判断基準が制定されることは、今後の私達の業界に必要不可欠なのではないか、そう私は考えます。やはり努力した分は評価されたいですし、明確に判断されるのであればそれに対しての努力も行いやすいのではないでしょうか。

　業務を行う上ではプロジェクト、または組織を束ねるためにも、しっかりとした体制が必要です。一般社員に始まりリーダー、管理職と、置かれる場所によって名前こそ違えど、多くの役割が必要とされています。求められる役割に適した人材が、そのポジションに収まることで、迅速かつ円滑な行動が可能になるのです。

　この仕組みは、おそらく企業というものが登場して長い年月が過ぎた中で、先人の知識や経験より導かれたものであるのは、疑う余地もありません。ですが、実際には肩書きだけの人材や、立場にそぐわない行動をする人、仕組みを表面的になぞっただけの体制など、あまりうまく動作しているとは思えないのではないでしょうか。

　今までは年功序列が主立った仕組みであったということもあり、昇格と昇給はほぼ同意であったと思います。年を重ねて経験を積むことを前提として、役職を上位にシフトさせていったのでしょう。

　しかし近年ではさまざまな要因が重なったこともあり、単純には今までの経験を生かすことができなくなっています。ですが、役職などについてはあまり見直されることがなく、過去の経緯を受け継いだ状態、つまり「年功序列的なやり方」を続けているところも多いのではないでしょうか。そのために、上位職ではあるけれどもあまり有効な活躍ができていない人が増えているように感じられます。

　さらにはドーナツ化現象として、中間層が不足するような状態になると、事態はもっと深刻です。活躍ができていない上位職と、ベテランにと呼ぶにはまだ時間のかかる人たちだけが、企業を構成する状態になってしまうと、そこから改善するには並々ならない努力が必要です。

　あらためて考えてもらいたいのは、「そのような状態であっても今までのやり方を続けますか」という点です。現実としてうまくいっていない状態がある、改善していく必要がある、と認識しているのであれば、何か行動を起こさなければ、状況の好転は望めません。

　しかし、この問題は、現場側でどうこうできるものではありません。経営側の問題です。

　私は現場側の人間ですので、経営側の思想はほとんど分からないのですが、実際に経営を行われている方々は、このあたりの問題についてどのように考えられているのでしょうか。機会があれば、ぜひ聞いてみたいと思います。

　私が個人的に考える改善案としては、「現行の役職を廃止し、スキルの有無と権限の有無によって立場を流動的に変化できるよう扱う」という案を考えたりしています。イメージとしては、フォルダやファイルに対してセキュリティ設定を行うような感じでしょうか。Active Directoryなど構築している場合、「役職ではなく権限を主体に考えることが適している」という考え方があります。この考え方を、実際の現場にも適用するというのは、どのようなものなのでしょうか。

　この人はマネジメント技術が秀でているので、チームマネジメントを行う権限を与える、この人は実際の実装作業が得意なので、実装における権限を与える。逆にこの人は年数だけはかなりあるけれども、設計能力はあまり持っていないので実装権限だけ与えよう。この人はオールラウンダーなので、マネジメントも実装も権限を与えよう。

　そして、このように割り振られた権限をもとに、給与を決めていくという方法です。実力主義的な部分が強いと思いますが、なかなか降格させることが難しい役職よりも活用を行いやすいのではないか、などと考えています。現時点でも資格の有無で手当が出されている企業もあると思いますが、その考え方の発展型だと思います。

　肩書きは、実際の業務にほとんど意味をなしていません。大半の人はそれを感じているとは思いますが、肩書きとは無縁な状態で業務を行っている企業は、あまり存在していないと思います。そのため、肩書きは立派だけど大したことができない人を増やし続けているのではないでしょうか。そしてそれは、企業として本当に望んでいる姿なのでしょうか。私は違うと考えます。

　このような話題を考えるきっかけとなったのは、企業にとって社員に適切な評価を下すことは「規模が小さくなるほど難しくなりやすい」という実情を見る機会が多くなったことです。設計も実装もテストも行わないシステム部の社員が存在したり、営業活動を行わない営業部の社員が存在したり、本来の組織としての存在意義に反する方々を目にすることが多くなっているように思えたのです。

　このような人たちを、どのようにすれば減らすことができるのか。それが今後、対応を求められる課題の1つなのだと思います。

　チームを組み業務として開発を行う場合に、問題となる点があります。「メンバー内で技術レベルにばらつきが存在した場合、どこに基準をおくか」という問題です。

　技術者としては、常に高みを目指していきたい気持ちもありますので、チームにおける技術リーダー的なポジションに就く方に合わせたくなります。ですが、それではほとんどの場合においてうまくいかないのではないでしょうか。最も高い人にレベルを合わせようとすることは、ものすごく他メンバーに対して負荷をかけてしまうことになります。全員が全員、学習熱が高く並々ならない向上心を持っているならば、あるいは成功するかもしれませんが、実体験を含めて思い出してみても、そのような状況になることはほぼないといってもいいでしょう。

　それではどのレベルを軸として考えるべきか、どのレベルであればチームとして活動がうまくこなせるか、また次へ繋ぐことを考慮してどのレベルに合わせようとすればいいのか。こうあるべき、という理想はありますが、現実としてどうすべきかというのは大変に難しい問題です。

　単純に今の案件だけを考えるならば、チームの中でも低い側に軸を置くのが良いのでしょう。もちろん要件を満たすことのできるレベル、という最低条件を満たす必要はあります。ですが、低い位置に軸を置いてしまうのは、エンジニアリングを行う企業として避けなければならないことだと、わたしは思います。

　いまも大事ですが、「これから」も同じくらいに大事なのではないでしょうか。「いま」をこなしたとして「次」がなければ、結局は駄目な結果でしかありません。技術レベルを低く合わせることは、自分達の将来を閉ざしてしまう行為だと、わたしは考えます。そのような状態では、競合する他企業に追い抜かれることは至極当然です。

　しかしあまりにも高すぎるレベルに合わせるのも、同様によくない結果しか生み出しません。技術のリーダーとなるべき人に求められるのは、どこまでなら追いつけるか、どこまでなら例え厳しくても追いつけるか、という部分でのバランス感覚ではないでしょうか。

　参加するメンバーとしては、できるだけ自分のことだけを考えず、少しだけでもほかのメンバーを気にして「ここまでなら大丈夫だ」と意見するぐらいがちょうどいいのではないでしょうか。参加するメンバー全員がこのように考えるところまでくれば、そのチームはほぼ間違いなくいいパフォーマンスを発することができる状態になる。わたしはそう思います。

　もしかすると、多くの方もこのように考えているかもしれませんが、現実問題としてそれほど簡単にことは進みません。理想としていろいろ掲げたとしても、現実には「納期に追われて時間がない」というような問題に悩まされた挙句、妥協案としてメンバーの中での最低ラインに合わせざるを得ないことが多々あります。

　「どこまでなら努力してもらえるか」、というのは、当然個人的な資質が関連してきますので、一概にどうこう決めることもできません。また、チームを率いるポジションの者の考えだけではなく、企業としての考えも考慮しなくてはなりません。

　率いるポジションから見て、チームメンバーの中にも「できれば外れてほしい」と思える人が含まれることがあるかと思います。中には、そのような人員には仕事を与えないプロジェクトもあると聞きます。わたしも似たような立場ですので、そうしたいと思う心情は理解できますが、これはやってはいけないことです。ましてや、パワハラ紛いなことを行うなどは言語道断です。誰かに対して「辞めた方がいい」とか言ってよいのは、相当の権限を持つ人だけです。少なくとも、一介のプロジェクトマネージャが言っていい言葉ではありません。

　大変なのは重々承知ですが、それでもチームを率いる立場であるならば、メンバーが有効に労働できるよう手配を行うことが、マネージャやリーダーの責務です。マネージャやリーダーの判断として特定メンバーに資質的な問題があると思われる際は、さらに上層部へと判断を仰げばいいのです。

　メンバーが自主的に活動する環境、それぞれに合った作業内容、メンバーに合わせた努力目標の設定など、チームを束ねるマネージャやリーダーというのは、難しく非常に大変なポジションだと思います。ですが、少なくとも会社としてある種類の期待を寄せているのですから、あなたにそのような立場に就くことを命じたのです。そう考えれば、また気持ちも変わってはこないでしょうか。

　1人で仕事を行っている際には、マネージャやリーダーといったポジションを体験するのは難しいです。もしそのような立ち位置に就くことがあった際には、視点を変えてみることで新たな楽しみを感じることができると思います。自分が整えた環境でメンバーが精力的に活動できたとしたら、非常に嬉しいことではないでしょうか。

　唐突ですが、あなたは周囲からどのようなものを求められているか、考えたことはありますか？

　技術者として、多種多様な技術に精通することでしょうか。勤務先が得意とする業種に精通して、その道のプロフェッショナルとなることでしょうか。はたまた、広く浅く対応できるよう対応力を磨いてほしいのでしょうか。

　会社によって、またその企業が保有している人材によって、求められるものは変わります。技術者が揃っている環境で、さらに技術者を求められるのは、なかなか稀だと思います。その会社で不足している領域、もしくは増強したいと考えられている領域をカバーできるよう求められる場合が多いのではないでしょうか。

　例えば、わたしの勤務先ではどちらかというと、ある程度広い領域をカバーできる人材が求められています。現有しているリソースとしてベテラン層が多いので「尖った」開発者を求めるかとも思いましたが、実際はそうでもなかった様子です。

　そのような環境では、例えプログラムを組む技術にものすごく長けていたとしても、あまり正当な評価が下されることは少ないと思います。反対に、プログラムを組むことよりも実際にユーザー先へと赴いて要件定義やサポートなどが行える人材の方が、より評価されることになります。

　このこと自体はまったく問題ではありません。企業としては、至極当然なことだと思います。企業が求めるスキルと企業に提供するスキルが一致する場合が、最も評価を高くするのは当然です。仮に自分が経営者の立場であれば、と考えることにより理解、納得ができるのではないでしょうか。

　これはある種の真理みたいなものですので、そこに不満をいうことは間違っていると思います。自分の能力を正しく評価されていないと感じる場合、よくよく考えてみると企業側が求めているものを提供できていなかった、ということはかなりあります。

　もちろん、本当に正当な評価がなされていないケースもありますので一緒くたに言い切ることはできないでしょうが、そのような企業は遅かれ早かれ何かしらの問題を起こし、衰退していくでしょう。最も発生しやすいのは、人材の流出だと思います。正当な評価が望めない環境に対して、そこに留まろうと思い続ける人はそれほど多くはありません。

　現状に不満をもつのはかまいません。それ自体は問題のない、むしろ人間として健全な状態だと思います。ですが、大切なのは不満を持つだけで終わりにするのではなく、その不満を解消するにはどうすればよいのか、このことについてじっくりと考えて行動することなのだと思います。

　改めて考えてみることにより、自分が抱いているイメージと会社が求めているものとのギャップに気づくことができるかもしれません。

　それでも、自分は自分の望む道で突き進みたい、そう考えられる方もいるかと思います。しかしそれは平坦な道ではありません。自分を貫き通すためには、周囲を納得させるだけの実力が最低限必要です。求められているレベル以上の実力を備えてこそ、会社の方針に従わなくとも認められる、ある意味の“わがまま”を通すことができるのだと思います。

　そのレベルに達してもいないのに、自分がやりたいことだけをやるというのは決して良いことではありません。会社のため、だけではなく、自分自身のためにも良くありません。結果を残していない状態で、わがままが許されるのは、いい換えると自分を甘やかしているだけなのです。給与をもらう立場、払う立場に関わらず、労働を行って結果を残すことは、プロとして最低限守るべき一線なのだと、わたしは思います。

　そうはいっても、どのようにして周囲に認められれば良いのか分からない、そう考える方もいるでしょう。そのようなときには、自分をプロデュース、またはセールスを行うことを考えてみてください。

　もし社内の同僚や上司がユーザーだとしたら、どうすることで「自分」という商品を使ってもらえるか、またはどうなっていれば使ってもらえるか。いまの社内の状況や世の中の状態を考えると、どうあれば他よりも使ってもらえるか。そのような視点から考えてみると、今の自分に不足している部分や伸ばすべき部分も見えてくるのではないでしょうか。

　「プログラマだから、ITエンジニアだから、これだけできればよい」。そのような時代はもう過ぎていると思います。今までの積み重ね＋αで、または今までとはまったく異なる部分で、自分という1つの商品を売り出せられるようになれば、自ずと目指したい道を進み続けることができるようになると思います。

　これは、決して新入社員をはじめとする若い世代だけの話ではありません。ベテランであろうと同じことです。むしろベテランであるならばこそ、さらに技術を、知識を、コミュニケーション力を身につけていかなければならないのではないでしょうか。

　わたしがその典型ですが、技術者を名乗っているにもかかわらず、技術的な話題を書かないタイプの人が世の中にはいます。もちろん、「書け」といわれれば少しは書くことができるでしょうが、「技術的な話題なら他にも前線でバリバリに情報発信されている方々がいらっしゃるしなぁ」と、どこか尻込みしてしまうのが本音です。

　わたしの場合、主に追い掛ける技術がどちらかというとマイナー路線というのもあり、なかなかエンジニアライフのようにパブリックな場所で書くというのも何だかなぁ、と感じてしまいます。

　実際にその技術がマイナーか？ と言われれば、実際はそうでもないのかもしれません。自分が目にする範囲ではあまり扱われていない話題で、実はもっと多くの方々が扱っている技術なのかも知れません。

　このように感じてしまっている自分の状態は、ひょっとすると社内などにおいて情報を発信しない方々と同じ状態なのではないか、視点を変えてみると、同じように当て嵌まる事柄は多いように思えます。

　情報をまったく持っていない、そのような状態は実はかなり稀です。多くの場合は、自分が持っている情報の価値に気付いていないことが多いのだと思います。ではなぜ、情報を持っているにも関わらず発信しようとしないのか。ここには何点か考えられることがあります。

　1つは、自分が持っている話題が世間的に見てどの程度のレベルなのか判別できないため、この程度の話しかできないのか、と思われたくないという気持ちが強く感じてしまっていることがあるかと思います。冒頭でわたしが技術ネタに躊躇してしまっているのは、このパターンです。

　もう1つは、あまり興味をひけない話題かもしれないので、声を発したはいいが、無反応で終わるのではないか、というある種の恐怖感です。反応がないというのは、発信側にとって最も避けたい状態です。反応が起きなさそうと思われる内容は、できるだけ避けたいという気持ちが働きます。その気持ちが強く働きすぎてしまい、何かを発信させることを躊躇わせてしまうのです。

　実際、大したことのない内容かもしれません。あまり他の方に関わりの見えない話題かもしれません。ですが、今こうしてコラムという形で自分の意見を発するようになり、そこを考えることにあまり意味がないということに気づくことができました。大したことがあるかどうかは書いた本人が決めるものではなく、読まれた方が決めるものだからです。

　書いた側としてはすごく力を入れて書いた内容であろうと、読まれた方が「大した話題じゃないな」とスルーされることは多々ありますし、その反対に気楽に書いた内容ですが、予想以上の反響が来ることも同じくらいあり得ます。

　わたしのように別段文章もうまいわけでもなく、大した内容を扱っている訳でもないのですが、それでも何かしらの反応があがる時があります。レスを返してくれる皆様には本当に感謝でいっぱいです。またTwitterなどで、「コラム読ませてもらいました」と言われると、小市民なわたしですから、それはもう有頂天で諸手をあげてガッツポーズものです。

　もし、何か話したいことを抱えているのであれば、どのような場所でもかまわないのでそれを文書や言葉で発してみてください。そうすると違う意見を聞くことができたり、賛同を得る機会が確実に増えます。機会が増えることにより、今まで接点のなかった他の方々と交流を持つことも十分あります。

　また個人的に感じたのが、「社内に向けて発信することよりも社外に向けて発信することの方が楽だ」という点です。企業規模にかかわらず、社内に向けての情報発信というのは意外にも難しい、と感じています。わたしが勤めるのは小規模企業ですが、たかだか数十人という世界にも関わらず、発信した情報に対するレスポンスというのはなかなかありません。この状態は目に見えるだけに厳しいところです。

　ですが、ここエンジニアライフやTwitterといった、広大な外部の世界に通じる場の方がレスポンスが帰ってくる割合は高いように思えます。それが単純に母体数が理由なのか、性質上関心が高い方が目を通すからなのかは分かりません。ですが、実際に反応は起きやすいのではないか、と感じています。

　もし社内へ向けて何かを発信しようとしたが躊躇されている様な方がおりましたら、一度外部へ向けてその情報を発信してみることをお勧めします。それにより

　「まずは声を出してみなければ何も始まらない」

　という点に気付くことができるのではないでしょうか。

　……ちなみに副次的な効果としては「発表する内容の取捨選択する技術が磨かれる」というのもありますね。脊髄反射的なものを減らすことはできるのではないか、と1人勝手に思っています。

　年も変わり2010年になりました。あと2～3カ月程過ぎると新社会人達がデビューする時期となります。企業によってはもうすでに事前研修といった形で、新社会人達と接しているところもあるのではないでしょうか。そこで毎年話題・問題になるものの1つが「新人教育」です。

　過去に似たテーマにて書いた際（道具使いの技術者たち）、勉強会以外にはどうすればいいか後日改めて、ということを最後に書きました。そこでわたしが考えていた方法は「車輪の再発明」を部分的に行わせる方法です。

　車輪の再発明と言うと、同じことを再度行わせる無駄なイメージが強いのではないかと思います。実務の面ではまったくもってそのとおりだとわたしも思いますが、人材育成を絡めた話となると位置づけが異なってくると考えます。

　人材育成においては極論すると「自分達と同じ、もしくはそれ以上のことが実行できるよう」物事を教え身につけてもらうのが目的だと思われます。OJTにて実務の形を利用することにより実践的な知識を身につけてもらうのも、社内講習会などでいろいろなテーマを話したりするのも、「自分達と同じ」ことが実行できるように希望するからこそ、行っている部分が強いのではないでしょうか。

　しかし、それは非常に難しいことであり、単純にOJTを行ったからといって達成できる目標でもありません。特にわたしが感じているのは、

「アプリケーションを作成できる人材に成長したとしても、小規模でもライブラリ・フレームワークを作成できる人材にはまだ遠い」

という状況です。目の前のアプリケーションを作成することはできても、ソリューション全体に適用するライブラリ・フレームワークを用意できる方というのはかなり限られているのではないか、と感じています。

　これは「視点をどこに持つか」という問題で、この業界で長く働いているからできるというものでもありません。人によっては、その視点を持つ機会がない環境ということもあり得ます。個人的には長く働かれている方ほど苦手分野とされる割合は多いように思えます。それは純粋にアプリケーションのみを作成している際にはあまり必要がないものである為に、ある程度の時間を業務に費やしてきたとしても、ライブラリやフレームワークを用意するスキルが身に付かないのだとも思えます。

　視点をどこに持つかというのは、言い換えると「考え方を変化させる」技術の1つです。この領域の技術は講習会だOJTだといってなかなか身につくものでもないでしょう。もしかすると、経験が最も重要なのではないか、とまで思います。

　体得してほしい思想を実際に体得してもらうには「同じような状況」が最も効果的です。現状で共通部品を作られているような方々でしたら、自分がそう思うに至った状況というのもある程度は作りだすことができると思います。わたしの場合、それは「同じロジックが複数個所に点在している」という状態を目にし、そのような環境で長い間プログラミングを続けていたことが始まりでした。

　プログラマは元々面倒くさがりな性質の方が多い、とはよく聞く話です。事実、わたしはそのタイプの性格でして、同じことを何度も行うのはどうにも苦手です。そのような場面では、

「次からはもっと簡単にできないものか」

「何とか楽できないか」

と、考えてしまう性格です。始まり方が良いか悪いかは別として、このような考え方を持つ人程早くから共通化させる思考が身につきやすいのではないでしょうか。一見すると手を抜いている様に思えるかも知れませんが、手を抜くことと楽をすることは、似ているようで異なるものです。

　同じような状況を用意し、できるなら同じ方向性の思想を持ってほしい。そう考えると車輪の再発明を行わせることはかなり有益です。問題と思える個所を実際に目にした時、どのように感じ取りどのように解決していこうとするのか。中には思いもよらない方法で対応する人も出てくるでしょうし、全く対応をしない人も出てくるとも思えます。

　対応するにせよしないにせよ、「なぜ、そうしようと思ったか」を説明できるようになればそれは1つの成功なのだとも思えます。対応しないことが誤りだとは一概に言いきれないのです。それぞれの会社、それぞれの風土によっては対応しない・できないことが最も適していることもあるのだと思います。

　業務として開発を行う場合、いかにして生産性・保守性・品質を上げていくのかがポイントとなります。しかし人が成長する為には、整った環境は逆効果になることが多々あります。あえて効率的でない状況を用意することで、もっといろいろなことを考えてもらう。生産性や保守性、品質を考えつめていくと行きつく先は二極化です。そこまで辿り着いてしまうと、共通化を行うような人材というのは更に増えることはなくなるでしょう。二極化し生産性や保守性・品質が高いレベルに到達しているがために、反対側へと成長させることは逆にものすごく労力や時間を必要とします。

　そこまでの状態になりますと、多くの人に育ってもらうのではなく最初からできる人を雇う、そのような方向性しか残されないと思います。かかる労力を考慮して最初からできる人を雇うのが早い、という考え方です。ですがそのような人材を望む企業ほど、そのような人材が訪れることは少ないのではないでしょうか。

　このように考えると、できるだけ多くの人に成長してもらえるような環境を用意するのが望ましいと思います。そのために車輪の再発明、というのが負担の少ない方法の1つなのではないでしょうか。

　現在業務上の都合もあり、（ようやく）WPF・Silverlight関係を調査しています。分かっていたとはいえ、その強力さになんともいえない気持ちになります。

　WindowsFormsと比較して、あまりにもパワフルなんですよね。普通に利用するだけでも、さまざまな視覚効果があるのはもちろん、一番のメリットはロジックが綺麗に分離できる部分なのではないかな、と感じることがあり、早急な習得が必要だなぁ、と思っているところです。

　調査を行っている間、「これからの開発スタイル」という問題に対して、1つの方法を示してくれているように思えていました。

　Microsoftとしては「開発者とデザイナーのコラボレート」という触れ込みで、分業化をメイン軸に置いている気がします。個人的な感覚としては「それはわかるけど、それができるところは非常に限られるだろ」という考えで、わたしの勤める企業みたいな中小・零細なところでは、なかなかUI設計にデザイナーを投入するなどということは、予算の都合もあり実現できないことがほとんどです。

　そのような状況ですが、少々違う見方をすると「これこそウチのような企業に向いている」のではないか、と思えるようになりました。

　わたしの勤める企業では人材のドーナツ化が著しく、中堅世代と呼べる人材がほとんど存在していません。そのためなのか別の理由からなのか、ベテラン勢な方々は新しい開発において対応しようという意識に乏しく、.NetはおろかVB6からの脱却すらできそうにない状況です。

　また極端にいえば、「既存方式以外での設計を拒絶」する傾向が強い環境です。わたしは.Net系の案件をやっており当初はDB関係と実装関係、そしてPJリーダという位置づけだったのですが、気がつくと何から何まで自分でこなさなくてはならない状態になっていました。良くいえば「任せられている」、いい直せば「放置プレイ」ですね。

　そのような環境の場合、ベテラン勢の方々ができることというのはかなり限られてきます。そこで「うまくいけば利用できるかも」と考えたのがExpression Blendです。

　実装に関わるアーキテクトな話題や、データベースの設計、要求分析等最近の案件は低価格でハイレベルな結果を求められています。そのような状況において新しい方式をなかなか受け入れようとしない、身につけようとしない方々でも比較的参入しやすい領域があります。それは「GUIデザイン」（ただし高度なUXを求めるような案件ではなく、既存業務システム的なUXを求められるケースに限定して）です。

　WPF・SilverlightなどのRIAに関係するテクノロジーを詳しく知らなくとも、既存業務システムのGUIデザインであればExpression Blendにてかなりのことが可能です。業務システムはまだまだリッチなUXをそれほど必要とはしていません。WindowsFormsを用いてデザインするのと同レベルでほとんどの要求はクリアできるでしょう。

　そうなるとこの場合疑問に思われるのは、「それならばWindowsFormsを使い続ければいいのでは？」という考え方なのではないでしょうか。

　確かにそれでも構わないと思います。ですがそれでは実装側がWPFを用いた開発を行う場合、問題のあるベテラン勢の方々は本当にやることがなくなってしまうかもしれません。

　冷静に考えればそれはそれで構わないのかも知れませんが、企業として考えた場合、「今あるリソースの有効活用」は社員それぞれがよく考える必要のある課題だと思います。

　「できない人には辞めてもらう」という姿勢の企業もありますが、その適用先は大体にしてベテラン勢ではなく、新人や中堅などそれ以外の層が対象です。

　今回Expression Blendを話に用いたのは、「実装」と「デザイン」が製品として明確に分かれているから、というのが大きな理由です。同一製品で全てがこなせるのは開発者にとって理想ですが、こと今回のような場面では「分かれているからこそ有効に活用できる」ケースなのではないでしょうか。

　今あるリソースを有効に、という観点で考えると各々ができることを最大限にこなすのが理想状態です。本来であれば「上司の使い方を考える」のは大変おこがましいことであるのかもしれません。反対に、わたしのことが同じように「使えない人材」と思われているのは大いにありえます（それはそれでれっきとした評価ですので理解はしますが……納得はしないですけど）。

　ツールの使い方も大事です。それと同じくらい人の使い方も大事です。いろいろな事柄がかなりのスピードで変遷している状況の中、改めて今後の方針を考えてみることは大切ではないでしょうか。

　この業界に信じられていることの1つに「PGが育ってSEになる」があるかと思います。実際、わたしの会社でもその考え方は根強く、上記と同じく考える空気が蔓延しています。

　大枠では異存がないのですが、よくよく考えてみると微妙に変なのですよね、これ。「PGが育つとSEになる」のであればその逆、「SEはPGの作業を行える」も本来ならば成り立たないとおかしいと思いませんか？

　しかし、現実にはどうでしょう。自分たちがPGとして作業を行えるSEの方というのは、意外に少数なのではないでしょうか。独断と偏見に満ちたイメージとして、「古くからのSE」タイプでは「もう実装はできない」と思っている人が多そうです。

　また世の中には、PGとしての経験を積まずにSEをされている方というのも存在します。感覚的には大企業の方が多そうなイメージですが、実際に調べたことがないので、真偽の程は確かではありません。ですが、どうやら簡単には「PGとして経験を積みSEになる」と言い切れない何かがここにあるのだと思われます。

　そもそもPG、SEとはどのような職種なのでしょう。

　英語としての単語では「PG：プログラマ」は存在しても、「SE：システムエンジニア」という単語は存在しないそうで和製英語との事。海外ではどちらもプログラマとして呼ばれているとのことだそうです。定義としてはこのようなものだそうですが、実態はどのようなものでしょう。

　PGは「実装」、SEは「設計」。何となくですがこのようなイメージを描いている方は多いのではないでしょうか。そしてこの感覚を、恐らくは上級職に就かれる方ほど共通して持っているのではないかな、などとわたしは思います。それがPGとSEで単価が異なる、というところに表れているのではないでしょうか。また、「SEが設計した内容を元にPGが実装する」、このイメージが比較的多くの人に信じられているため「SE＞PG」と言う様な間違った上下意識を生み出しているのだと思います。個人的には上下ではなく、作業の順番を表しているだけの気がしていますが……（以前のコラムに対するコメントとして、さらに「SE＞PG＞CE」と思われていることもあることを教えていただきました）。

　「間違った」と言い切るのは次のように考えているためです。

　PGとしての経験を元にSE的業務を行う、これ自体は何も問題もありません。PGで得た経験はSEにとって重要なものだというのは理解・納得できます。ここまででは「PGが育つとSEになる」というのも間違いではありません。

　しかし、昨今の情勢から、PGが知るべき範囲というのは拡大の一途を辿っています。そのため今のPGは、現在SEと呼ばれる方達が過ごしてきたPG時代とは異なった知識領域が増える、もしくは領域がスライドしていると思われます。

　これが「PGが育つとSEになる ⇒ SEはPGの作業を行える」、という考え方が成り立たないケースを生み出す原因になるのだと考えられます。PGからSEと育った方達が努力せずにそのままでいる限り、現実のPG領域が進歩している事態に対応できなくなることによって「PGができないSE」を作り上げているのです。もちろん、SEでありPGでもある方もいらっしゃいます。ですがそのような立派な方達の数よりも、そうではない方達の数が圧倒的に多いのではないでしょうか。

　もしPG作業ができないSEの方こそ少数派であり、ほとんどのSEは常に努力を怠らないのでPG作業も可能、であるならば「SE＞PG」と言われることも仕方ないでしょう。しかしPG作業ができないSEの多さから見て、「SE＞PG」と言ってよい状態には程遠いのが実態なのだと思います。

　ここについては主に2つの考え方に分かれると思います。

　1つは「SE＞PG」と言うためにはSE層のさらなる努力も必要ですので、研鑽を重ね本当に「SE＞PG」であるように目指すこと。もう1つは「SE＞PG」ではないことを認め、すべてを別職種として同列に扱うこと。もちろん同列に扱うという場合は、その人の技術・能力など職種以外の別の点にて判断されるので、どちらを選択したにしろ努力は必要となります。

　PGであろうとSEであろうと、もっと言えばどの職種であろうと常に努力を続けることが大事なのではないでしょうか。あくまでも個人的な意見ですが、努力をしないなら仕事をやめてほしい、業界から去ってほしい、と思える程です。下に努力を求めるなら自分も努力しておけ、と。

　わたしはSEにPG、そしてCEも含めて「異なるスキルを必要とする別職種」と考えています。その方が現実を表しているという気がするのです。皆さんもよく見かけるとは思いますが、PG作業がとてもハイレベルであったからといってSE作業も同様にこなせるとは限りません。SE作業が神の如く素晴らしくこなせていたとしてもその人がPG作業も素晴らしいとは限りません。ゲームでいう上級職ではないのですから、片方がこなせたからといっても、もう片方をこなせるとは言い切れないのが当然です。

　ほとんどの方はこのことを理解していると思えるのですが、なぜか「SE＞PG」という意識はなくなることがありません。不思議なものですね。

　いろいろ書いてきましたが、恐らくは実力主義的の企業でなければ、SEやPGなどを別職種として見る事は難しいのではないか、と感じています。どこか年功序列的な考え、「ある程度の年数を重ねて上級職へ」という思想がベースに根付いている企業が多いのであるならば、実力主義的思想が中々定着しないというのはうなずけます。

　そのような人達にとって「SE＞PG」でなければ、自分達をも否定してしまうことになるのでしょうから。

　気がつけば、無事に5回目の社内勉強会を開催できました。今まで何度か行って、自分の勤務先ではオープンな雰囲気を醸し出すコミュニティスタイルよりも、どこかクローズドな雰囲気なセミナースタイルの方がやりやすいと実感しています（それでいいのかどうかは悩むところがありますが……）。

　もともと、わたしはMicrosoft系のセミナー、カンファレンスなどに好んで参加する性格でしたので、企業主催型のセミナースタイルな勉強会に慣れているせいもあるかと思います。反対に、コミュニティ主催型には全く参加していないという状態です……。前にも書いたのですが、わたしは「土日開催でなければ参加する」というほとんどのエンジニアと真逆な行動パターンですので、参加が難しいのですよね（次に参加できそうなのはMSパートナーカンファレンス2009でして、ちょっと間が空いています）。

　まぁそんなわたしが行っている勉強会ですので、スタイルも内容もやはり「カタめ」な内容に偏ってしまいがちです。色々な記事や参考意見を見聞きする限り、あまり褒められたスタイルではなさそうです。

　ですが5回程やっていると、

「誉められないスタイルだろうと、それが適している風土はあるとこにはあるんだなぁ」

という、一般的な考え方とは少々趣が異なる考え方を持つようになりました。

●活発でない企業、受身な社員が多い部門、チームには押しつけ気味なスタイルが向いている

　コミュニティ勉強会などの記事を読んで、同じような（似たような）ことを行おうと思っても、開催する企業自体の風土、もしくは参加をお願いする相手方が非常に非協力的（受身な人も含め）などなど、もともと「自主的に行動する」人達が集まるコミュニティで行う勉強会スタイルを、そうではない企業の中で行うとほぼ確実に失敗で終わると思われます。

　回数を重ねれば自主的に動き出すことはありますが、そのような文化が育っていない場所でいきなり「勉強会だー！」と意気込んでみたところで無理なのです。変なたとえですが、発言や意思表示に慣れていない人にいきなり、

「Twitterで適当につぶやいてみて」

「社内にBlog用意したから好き勝手に書いてみて」

と押しつけるような状態です。

　相手にしてみれば何をどうしていいのかすらわかる訳がありません。そうして戸惑っている間に時間だけが過ぎ、最後に何事もなかったかのように戻ってしまうのです。

　理想的なスタイルというのは、それに見合う環境が整っているからこそ初めて理想的なのだと思います。スタイルだけ理想に近づけたところで、それを構成する環境が理想に近くなければどこかで破綻します。

　今のわたしの勤務先のように、自主的にどうこうする空気が薄いところでは、ある程度の強権を発動して、半分業務の一環的なスタイルで行うのがやりやすいのではないか、と思います。

　最初の数回をそのような形でこなしてから、自由参加を求めるようにすると結構惰性で参加しつづけてくれることがあります。そうなれば第一段階はOKです。「集まってくれる」この壁がなかなか継続するにあたって大きい障害ですので、まずここをクリアすることが最優先です。相手が惰性で参加してくれようと自主的であろうと、話を聞いてくれる観客がいなければ主催者のモチベーションも何もありませんから。

●続けるかどうかは自分だけが決めてよい

　社内勉強会は「やってみると良さそうだからやる」のでは続きません。「自分が喋りたいからやる」のが大事だと思っています。あくまでも自分（主催側）の気持ちが大事だと。

　よく勉強会を開くメリットは～と書かれる記事も多く目にしますので、何となく「やったほうがいいなぁ」という気分にさせられますが、これはあまりお勧めできません。

　「社内に技術を伝える」ですとか「雰囲気を変える」ですとか。綺麗な言葉でいろいろなメリットとして語られることが多いですが、あくまでもそれは勉強会を行った結果の余波みたいなものと考えています。主催者が「やりたい」ことをやった結果についてくるものだと。やりたいと思えないことをやったところで、良い影響は発生しないのです。

　ですので最初は周りのことなど考えずに、自分が喋りたいことを喋る、それだけのために集まってもらう位に捉えてみるのがいいのではないでしょうか。そうして数をこなすうちに、周囲に良い効果が出てくるものだと信じています。

　わたしは理想として目指したいところがありますが、今はまだそこまでたどり着いていません。ですがまだまだわたしは「喋りたい」と思うことがあるので、社内勉強会は続けていこうと思っています。たとえ良い結果が残せなかったとしても、わたしは一向に構いません。

　「やりたい」からやっただけなんですから。