2009-04-25

組織はソフトウェアエンジニアに投資できるか

このブログで、日本のソフトウェア技術者は試行錯誤的アプローチで組込みシステムのソフトウェアを作ってきたと書いてきた。それでも組込み機器の品質が保たれているのは、日本人に特有の「あたたかい人間関係の中のやさしい一員」という性質と職人気質、そして品質を心配する強い意識があるからだとも書いてきた。

これらの日本人の特性プラス「何かあったらソフトウェアをすぐ修正」という行動によって、日本の組込みソフトウェアは今のところかろうじて高品質を維持していると思う。しかし、これらの状況は、ソフトウェアの規模が小さいことと、日本のソフトウェア技術者が劣悪な環境を我慢(高収入を求めずにオーバーワークに耐えるということ)しているからまだ破綻していないのであって、システムソフトウェアの規模が増大(例えば実行コード行数ベースで30万行を超えるような規模)し、技術者がその過酷な労働に耐えきれなくなってきたときには、組込みソフトウェアの品質と開発効率が著しく低下し始めるはずだ。

もしも、ソフトウェアに関してどうにもならなくなってしまったら、組織はこの状況を打開するためにソフトウェア開発に対して何らかの投資をするしかない。今回は組織がソフトウェア開発(実際にはソフトウェア技術者教育)に投資できるかできないかの境界について考えてみたい。ソフトウェア開発に関して悪循環が始まっているかどうかの指標は、組織がアウトプットしているソフトウェアが結果的に利益を生んでいるかどうかで簡易的に判断できる。どのプロジェクトも利益を出せていないのなら、悪循環のフェーズに入っていると考えられる。利益が出ている商品、製品、プロジェクトと利益がでていない商品、製品、プロジェクトが混在している場合は必ずしも悪循環のフェーズに入っているとは言えない。

何はともあれ、ソフトウェアエンジニアという末端の立場から離れて、自分が経営者になったつもりでこの後の記事を読んでいただきたい。

なお、ソフトウェアは毎日のソフトウェアの活動で構築される。ツールにノウハウを隠蔽することはできるが、ツールを使いこなせるようにするにはトレーニングが必要になるから、結局はソフトウェアエンジニアに対する教育やマネージメント、インフラに対して投資をしなければ、ソフトウェアの品質や開発効率は上がらない。そう考えると、よっぽどの裏技を使わない限り、ソフトウェア開発に対して何らかの投資をしない組織のソフトウェア品質と開発効率は上がらない。

そして、プロジェクトマネージャーより上の立場の者は、まずは、ソフトウェアエンジニアに対する投資を組織からどうやって引き出すかについて考え、それが無理だと分かったとき、もしくは自分自身がエンジニアに投資を進言する立場にない場合は、組織を見限るか、それとも組織に留まって、どれくらい自己投資できるかどうかという方向に考えを切り替えるべきだと思う。

【組織がソフトウェアエンジニアに投資できるかどうかの境界】

1. 儲かっている会社は投資できる

当たり前だが、潤沢に利益を出している会社はソフトウェア技術者教育やツール、インフラ整備、プロセス構築、技術コンサルの導入などに投資できる。人を動かすだけで一見投資が必要ないように見える社内コンサルのような支援部隊を組織するような場合でも、人材を外から引き抜くのにお金がかかったり、現場から人材を外すことで工数の穴埋めをしなければいけなかったりするから投資は必要だ。

儲かっている会社はいろいろな手を打つ選択肢がある。ただ、気をつけなければいけないのは、ソフトウェアに関する投資ははっきりとした効果が見えにくいから、投資が役に立たなかったとしても口先だけで継続的に組織からお金を引き出そうとする人たちもいるということだ。

でも、儲かっている会社はある程度の無駄をしても原資があれば、何かしらの手を打ち続けることはできる。現在のように不況に陥ってしまうと、儲かっていた会社も利益が減ってしまい、ソフトウェア開発に対する投資を絞ってしまう傾向はあるだろう。

2. 儲かっていない組織でも技術者への評価に差を付けることで投資はできる。

利益がそれほどない組織でも、ソフトウェア開発に投資する意志とある程度の金(例えばソフトウェアエンジニア一人に対して年間最低10万円以上)を捻出できれば、新入社員や将来有望な技術者、今後、利益を生むアーキテクチャ(再利用資産を構築できるアーキテクチャ)を設計できるアーキテクトに対して集中的に投資するという方法はある。

アメリカではプログラム言語の書き方を知っている程度のスキルのエントリーレベルのソフトウェアエンジニアの年収は200万円以下だと聞いたことがある。そこから、スキルがアップするにつれて年収が上がっていく。日本も同じようにスキルがゼロに近い新入社員への報酬を減らしたら、優秀な技術者への投資分の数十万円/人くらいは出せるだろう。

しかし、このやり方は日本人にはなじまない。日本では長い間その組織、業務を経験させ、その時間の中で成長させるというところが多い。あえてこれを教育と呼ばないのは、組織的な戦略を持たずに現場に任せきりで、日々の業務をやらせているだけで技術を引き上げようという意志を持っているプロジェクトは多くないと感じているからだ。だから、組織が意識的に取り組む「投資」とOJTという名の実際には何もしていない状態は分けて考えている。

逆に、新入社員こそ組織として投資しやすい対象であるというのが日本の特徴だ。もっと、やってくれと言われることはあっても新入社員ばかり金をかけて不公平だという中堅、ベテランエンジニアはほとんどいない。

ソフトウェアエンジニアの中に年功序列ではなく、スキルの高さによって評価に差をつけて、実際にサラリーに差をつけて、そこから投資の費用を捻出するという方法は、よっぽど組織の上位層に強い意志と決断があって、目指すべきゴールがはっきりしていないとできるものではないと感じる。

なぜなら、日本人の「あたたかい人間関係の中のやさしい一員」という性質は人と人に差を付けるというのをいやがるからだ。自分もあまり好きではない。テストの点数で評価している訳ではないから、何をもって投資対象として選択されたのかについて技術者の中に疑念が生じると「あたたかい人間関係の中のやさしい一員」という性質を活かすことができない。

だから、技術者に格差を付けて集中的に投資する方法は日本の組織ではなじまない。

3. 自分で自分に投資する

組織がソフトウェアエンジニアに投資しない、選択的でも投資できないのなら、自分で自分に投資するしかない。お金をかけようとかけまいと冒頭のような状況でエンジニアに対して投資する気がないのなら悪循環からは決して抜けられない。(誰かがスキルアップするトレーニングを自分に提供してくれる筈だと考えるのは、そうならなかったときにスキルアップできないのは人のせいだと考え自己努力しなくなってしまうから危険だ)

自分自身の投資の仕方については次回の記事に回すとして、もしも、自己投資に成功してスキルアップした時に起きる問題について触れておこう。

何らかの投資の結果、自分のスキルが向上しソフトウェアの開発効率や品質をアップできるようになるとどうなるか。そもそも、組織が投資してくれないので自己投資しているのだから、スキルアップが成功したとしても、組織貢献を明確に示すことができないのなら、組織からの評価を期待することはできない。

自分のお金や時間でスキルアップして、組織貢献を実現できたのに評価されないかもしれないのだ。評価されないどころか、スキルアップして開発効率や品質向上を実現してできた余裕につけ込まれて他人の開発効率や品質の悪いソフトウェアを何とかする仕事を回されてしまう危険性さえある。

これはやりきれない。頑張ってスキルアップした技術者の努力が報われない社会、業界が発展する訳がない。

でも、現実はこんなもんだ。だから、頑張ってスキルアップできた技術者はその組織で報われないことが分かったとき、例えば組織を出てコンサルタントになり、1 の儲かって利益を出せている会社を助ける側に回ることになる。

そうなると、成長した技術者が去ってしまった組織が潤沢な利益を出せていなかった場合は、さらにソフトウェアの開発効率が悪くなり、品質も悪化し、残った技術者が残業することでしか対応できなくなる。

この論理だと、ソフトウェアエンジニアは自己投資でスキルアップしても報われないから、自己投資しないでじっとしていた方がいいのかということになってしまう。

そんな筈はないから、こう考えるしかないと思う。

組織がエンジニアに投資をしないのなら、エンジニアは自己投資してスキルを上げ、スキルアップしたことでソフトウェアの開発効率と品質を高め、顧客満足が高まったことに対して満足を感じるようにする。顧客満足を高めたことで自分のモチベーションを保ち、顧客満足を高めることに貢献したことを組織に示し評価を得、同じことを他の技術者もできるようにするには投資が必要であると説く。

4.  ソフトウェア開発やソフトウェアエンジニアに投資しないという選択

組織がソフトウェア開発に投資しない、技術者も自己投資しないとう選択肢はないのか。ないことはない。以下のようなケースが考えられる。

a) 投資せずに技術者に負担を強いる。
b) ソフトウェア部品を外から買い自組織では作らない。(サプライやにaを強いるか、逆にソフトウェア部品の価格をつり上げられるという問題あり)
c) 安い海外の労働力にシフトする。(「あたたかい人間関係の中のやさしい一員」という特性は使えない)
d) ソフトウェアでは勝負せず、真似できないハードウェア技術で勝負する。

以上、組織もエンジニアに投資を行い、エンジニアも自分自身に投資をし、投資の結果、ソフトウェアの開発効率と品質が上がり、顧客満足が高まり、それが自己満足につながって、組織にもその成果を認めエンジニアを評価し、投資の効果を確認するのが一番いい。それができないのならソフトウェアエンジニアは幸せにはなれないように思う。

次回は、お金をできるだけ使わないでソフトウェア技術者に対する投資をする方法について書こうと思う。
 

2009-04-11

ルールに振り回される日本人


日本人が本質的な目的を忘れルールに振り回された典型的な例がニュースで流れた。

制服ワッペン2万枚作り直し、3400万どぶ…都下水道局

4月10日3時6分配信 読売新聞

東京都下水道局が昨年、制服に付ける都のシンボルマークを添えたワッペンを2万枚作製したところ、シンボルマーク使用に関する内規に反したとしてこれを使わず、新たに約3400万円をかけて、ワッペンを作り直していたことがわかった。

 デザインは組織名の下に5センチ余の波線を付けたシンプルなものだったが、この責任を問い、都は担当幹部2人を訓告処分にしていた。内規を杓子(しゃくし)定規に解釈した「お役所仕事」の典型とみられ、公費の支出の在り方に批判が集まりそうだ。

 都下水道局では、所属する計約3000人の職員用に、予備を含めて計約2万着の制服を作っているが、1978年から同じデザインだったため一新することにし、右胸に付けるワッペンも新たに作ることにした。

 ワッペン(縦2・5センチ、横8・5センチ)はシリコン製で、イチョウ形をした都シンボルマークの横に局名を記し、「水をきれいにするイメージを出したい」との願いを込め、その下に水色の波線(約5センチ)を添えることにした。職員が考案したものだった。

 ところが、約2万枚のワッペンが完成し、一部は制服への縫い付け作業が始まった昨年11月に開いた局内の会議で、ワッペンのデザインが、シンボルマークの取り扱いについて定めた都の内規「基本デザインマニュアル」に抵触する疑いが浮上。内規には、マークの位置や文字との比率などが細かく記載されており、誤った使用例として「他の要素を加えない」と規定。同局では今回、この規定を厳格に解釈したという。

 ただ、この規定は例外も認めているが、同局では、波線部分を取り除いて作り直すことを決定。制服を含めた費用は当初、約2億1300万円だったが、新しいワッペンの作製費と縫い替えの費用として、約3400万円を追加支出した。

 都は今年3月、最初のワッペンのデザインを決めた担当の部長と課長(いずれも当時)を訓告処分とした。今月から制服を一新したことは発表したが、ワッペン作り直しに関する一連の事実は公表していない。

 下水道局は「事前に規定を見ていれば防げたもので、担当者のミス。多額の費用負担を生じさせて申し訳ない。次のデザイン更新は何年先になるかわからず、それまで誤ったワッペンを続けることはできなかった」と説明している。

 下水道局を巡っては、JR王子駅(北区)のトイレの汚水が、約40年にわたって近くの川に流れ込んでいた問題で、2007年6月にこの事実を把握しながら、対策を取らずに放置していたことが判明している。

冒頭の図の上が東京都下水道局が当初、採用する予定だったワッペンのデザインだそうだ。波線が入っていることがルールに違反している=あってはならないという考えにとらわれてしまったわけだ。

この東京都下水道局幹部の判断について石原慎太郎知事は10日、定例記者会見で「本当にたまげた。骨身に染みて反省するよすがにさせる」と述べ、作り直しを決めた同局の幹部らを処分する方針を明らかにした。石原知事は、この問題を報じた読売新聞を掲げながら、作り直す前のデザインについて「東京の下水はきれいだなって感じがするし、いいじゃない」とし、「規格に合わないからと作り直して、バカじゃねえかほんとに」と怒りをあらわにしたそうだ。

このニュースを聞いてたしかに「バカじゃねえか」と感じたが、実はこのような「バカじゃねえか」という話しは身近でよく見かけると思った。

この話しには日本人特有の2つの問題があると思う。ひとつは「組織やプロジェクトを構成するメンバーが組織やプロジェクトの目指す目的について十分に意識していない」ことと、もう一つは「組織やプロジェクトを構成するメンバーがルール作りに参加しておらず、ルールを改善することができると考えていない」ということだ。

【組織やプロジェクトの目指す目的について十分に意識していない】

ようするに組織目標という遠くにあるゴールを見ずに、自分の直近にあるものしか見ないため近視眼的な思考となり結果的に、遠くにある組織目標に背反するような判断や行動を取ってしまうケースだ。

東京都下水道局のホームページを見ると経営計画2007というページに以下のような3つのスローガンが掲げてある。

○安全で快適な都市生活をめざして 
○お客さまサービスの向上・経営効率化の取組
○危機管理対応の強化・地球環境保全への貢献

職員が組織内で一つ一つの判断をする際に、この3つの目標を常に頭に入れておいて、これらの目標に向かった行動になっているかどうか考える癖をつけていると今回のような問題は起こらなかったと思う。

都の内規「基本デザインマニュアル」でマークの位置や文字との比率などが細かく決め、使用例として「他の要素を加えない」と規定したのは、シンボルマークの基準を定めることによって、一般市民がシンボルマークによって都の各部門とその責務を一目で判断でき、分かりにくかったり、勘違いすることを防ぐことが目的だったと推察される。

一方で東京都下水道局の文字の下に水色の波線(約5センチ)を添えることにしたのも「水をきれいにするイメージを出したい」との職員のアイディアであった。どちらも、東京都民へのサービス向上が目的だった。

それに比べて、約3400万円を追加支出してワッペンを作り直すという判断は、結果的にユーザーである都民の税金を無駄にすることになるから、組織目標であるサービス向上の目的にそぐわない。

こういう一見どっちを取るべきか判断が難しい事例は日々組織の中で発生している。本末転倒と思われる顧客の利益にならない小さな誤った判断、行動は組織の中で意外にも頻繁に発生している。「これはセクショナリズムだ」と思ったときは、組織目標に照らし合わせると顧客満足の向上を疎外するような判断や行動がなされていることが多い。

この違和感をすばやく察知できるようになると組織の中のどこを改善すると流れがよくなるのか、組織目標の達成率が高くなるのかが見えてくる。(組織目標というのは目標売り上げ達成というような低レベルの目標ではなく、顧客満足の向上や社会貢献といった本質的な目標のことなのでお間違えなく)

組織目標や組織のポリシーと自分の中にある価値観がオーバーラップしていて、組織の価値と個人の価値を一部でも共有できていれば、いつも正しい判断ができる確率が高くなる。ただし、組織の目的が金儲けで、個人の目的も金儲けというようなケースではいくら価値観が共有できていてもいい方向にはいかない。

上司から命令されたからとか、クライアントからの要求だからといった近い視点ではなく、その判断や行動はエンドユーザーの利益になるのかどうかという視点を常日頃持っていると、確実にプラスの実績が積み重なっていく。そうでないと、やったけど役に立たなかったとか無駄だったというマイナスの実績ができてしまう。ソフトウェアエンジニアとしての活躍できる時間は限られているため、日々の活動はプラスの実績につながるようにしていかないといけない。

【ルール作りに参加しておらず、ルールを改善することができると考えていない】

ルールは天から振ってくるものであり、絶対に守らなければいけないと信じ切っている人をよく見かける。外部のセミナーに行ってきてセミナーの講師から「これこれを守らないと大変なことになりますよ」と恐怖心を植え付けられてきた担当者は、ルールの本質を外れて枝葉末節にこだわり始める。組織内で改善活動を行っている者にとっては、この手の話しは自分達の活動に水を差されることがよくある。

セミナーの講師やツールベンダーの営業の一部の人は、自分達の売り上げを確保したいために、必要以上に法律や国際基準、業界ルールを強調して、それを守らないと大変ですよと吹聴する。それを真に受けた担当者が過剰反応すると開発の現場にそのしわ寄せがくる。

そもそもの法律や国際基準や業界ルールが作成された背景はすっとばされて、○○した方がよいという文言は、末端にいくにつれいつのまにか○○せねばならないという強制の言葉に置き換わってしまったりする。

法律だって時間がたてば、時代にそぐわなくなって修正しなければいけないときがくる。国際基準や業界ルール、組織ルール、プロジェクトルールだって同じだ。組織の目標を達成するためにルールは常に改善する必要がないかどうかを考えている必要がある。

日本人は自分達で自分達が守るべきルールを作るということがどうも苦手なようだ。自分にはルールを作る権利があるという意識も低いし、その権利を行使しなければ自分が損をするという意識も薄い。たぶんデモクラシーの教育や文化が弱いのだろう。(誰かが決めたルールに従うのが普通と考える日本人としての国民性もある)

そういう環境に慣れてしまうと「ルールは変えられるもの」という感覚がほとんどなくなり、まじめであればあるほどルールには絶対に従わなければいけないと思い込んでしまう人がたくさんでてくる。

実は自分はこの日本人の特性を理解した上で、その特性を利用している。組織内で支援活動をするときに相手のルールに対する考え方見定めてこちらの攻め方を変えているのだ。

例えば、「ルールは絶対」と考えている技術者に対しては、必要な活動の目的よりもルールの方に重きを置いて指導、支援し、やることが決まっている以上やらなければいけないよという持って行き方をする。そして、その活動がプロジェクトに浸透したところで、ルールの向こう側にある本質的な目的を伝えて、何をどう判断するのか、どういうときにルールを逸脱していいのかを説明する。

一方で「ルールなんかくそ食らえ」と考えるチームには、逆にルールの向こう側にある本質について説明し、その本質が目指している価値とチームの目指す価値は一致している筈であり、そのために必要な活動であると諭す。そしてその結果ルールに沿った取り組みとなると説明する。

どっちにしても、必要な活動をして、最終的な目標(顧客満足の向上や社会貢献)につながればいい、そう考えれば、最善の判断、最善の行動は何か自ずと見えてくるはずなのだ。