筆者は4年前，SE(システム・エンジニア）から記者に転職した。今思い起こせば，SEを続けるモチベーションを維持できなくなったことが，転職の理由の一つだった。

　SE時代には，「コミュニケーション不足による要件定義の誤り」や「設計時の勝手な思い込み」，「プログラムのケアレスミス」など，注意していれば防げるような問題がもとで何度も痛い目にあった。もちろん自分の能力不足が原因だ。しかし一方で，能力を発揮できる環境が整っておらず，高いモチベーションを維持し続けることが難しかったのも確かだ。

　現在は取材で多くのSEやプログラマに話を伺っているが，「モチベーションを維持しにくい」と語る人は少なくない。以前の自分の姿と重なって見えてしまう。むしろ開発期間の短縮化に対する要求がきつい今のほうが，環境が悪くなっているようだ。

　では，SEやプログラマがモチベーションを維持できるようにするには，どうすればよいのだろうか。

　やはり，仕事を正当に評価することが大切だと思う。SEに限らないが，人は正当な評価を受けてこそ，その能力を発揮する。しかしこれまで，SEやプログラマの評価はあまり真剣に行われていなかった。顧客の要望を聞き入れて無理をして働いても，評価が正当に行わなければ，SEやプログラマは報われない。過酷なプロジェクトを乗り越えた後で，うつ状態になったり，燃え尽きたりしてしまう（関連記事）。

　SEやプログラマの評価は難しい。経済産業省の情報処理試験やベンダー独自の試験の合格者に奨励金を与えることは，個人のスキルアップには有効だがシステム構築プロジェクトを通した評価にはならない。残業の多さや，1カ月で書いたソース・コードの量などで評価できるものでないことは明らかだ。プロジェクトの売り上げや利益額は，会社に対する貢献度を測ることはできても，プロジェクト・チームや個人を評価するには適していない。

　評価する方法を二つ考えてみた。一つは，発注者側にアンケートをとって評価してもらうこと。やや客観性に欠けるが，顧客満足度は有力な指標になるだろう。もう一つは，技術力を数値で示すことだ。構築したシステムの規模を何らかの指標で測り，それを基に生産性を示す。生産性を示す数値を使って，プロジェクト・チームやエンジニア個人の評価を行う。

　システムの規模を測るのが難しいところだが，例えば，本来は見積もりのために使われるFP(ファンクション・ポイント)値を使ってみるのもいいかもしれない。FP値はシステムの機能の量を測る尺度なので，ユーザーの視点で，システムがどれだけの規模なのかを表すことができる（参考：日本ファンクションポイントユーザ会のサイト）。システム構築プロジェクトの終了後に，そのシステムのFP値を測定して開発工数で割り，この「人月当たりのFP値」を生産性の評価指標にする。そうすれば，プロジェクトを通して行ったSEやプログラマの創意工夫は，生産性に反映され，評価に直結することになる。

　筆者はSE時代に一度だけ，FP値を使って自分の生産性を測ったことがある。実際にやってみると，社内の平均値よりも高い生産性であることが分かり，仕事をする励みになった覚えがある。

　FP値を評価指標に使うことには異論もあるかもしれない。携わるプロジェクトの性格や目的，あるいは構築や運用といった職種の違い，までも考えれば，理想的な評価指標を打ち立てることの難しさはよく分かる。だが少なくとも，SEやプログラマの技術力を示す指標について，もっと活発な議論を交わすことには意味があると思う。

　顧客の要望を聞き入れて短期間でシステムを構築した場合，残業続きで大変だったかもしれないが，密度の濃い仕事をしていれば生産性は高いだろう。新しい技術にチャレンジすれば，一時的に生産性は下がるかもしれない。しかし，新しい技術は多くの場合，古い技術よりも高い生産性をもたらしてくれる。新技術の習得が将来の高評価に直結すれば，高いモチベーションを維持しやすい。

　技術力を示す生産性の指標に業界全体が取り組めば，健全な価格競争ができる下地も整う。SEやプログラマ個々人だけではなく，SI会社やソフトハウスの客観的な評価にもつながるからだ。もちろん，言うのは簡単だが実行に移すのは難しい。しかし，SI会社やソフトハウスは技術の会社である。自社がどれだけの技術力を持っているのかを定量的に示し，ぜひ，技術力の高さを競ってほしい。そうなれば，SEやプログラマのモチベーションを高く維持できるのではないだろうか。

（松山　貴之＝日経オープンシステム）