現在、世の中には
ソフトウェアの開発現場が
数多く存在します。

以前、ソフトウェア開発には
現場やプロジェクトに応じて
さまざまなタイプがある・・・
という事をご紹介させて頂きました。

しかし、現場によって
違うのはタイプだけではありません。

そこには、明らかな

レベルの違い

というものも、存在します。

 

それでは、その
レベルの違いというのは
どこから生まれてくるのでしょうか?

 

私がフリーランスの
エンジニアとして
独立する前は、
プロジェクトに応じて
各社を転々としていました。

そこで、私はいくつかの
開発現場を経験したのですが、
ある会社に移る前に

「あそこの会社はソフトウェアが
ちょっとね・・・。」

といった話を複数人から
聞く事がありました。

どうも、その会社は
ソフトウェアの評判はあまり
良くなかった様です。

当時は既に、私も
ソフトウェア・エンジニアとして
水準以上のスキルを持っているという
自負はありましたので、
自分が行けば何とかなると
思っていました。

その会社がソフトウェア開発の
ノウハウが遅れているのなら、
それを私が伝えれば
良いだけだと思っていたのです。

ですが、実際に
その会社に移ってみると
問題は「そこ」ではありませんでした。

では、何が問題だったかと言うと
ノウハウの様な「知識」ではなく、
開発に携わっている人達の「意識」だったのです。

例えば、その会社に在籍している時に
こういう出来事がありました。

当時、私はあるソフトウェア開発チームの
リーダーでしたが、
プログラミングの作業を
メンバーにお願いしようと、
開発する機能を記述した
仕様書を作成していました。

それは、独立した
文書として作成していたのですが、
このやり方に、当時の職場の
上司から物言いがついてしまったのです。

その上司が言うには、
仕様書は、これまでの仕様書に
追加して記述しないと駄目だと
言うのです。

実際に開発現場に立っている
私にとって、それは納得が
できませんでした。

以前の仕様書に追加する形だと、
書く方も、どの章に入れるか考えたり
目次の構成を変えたりと面倒だし、
読む方も、古い情報と今回必要な情報が
入り混じっていて面倒だし
誰も喜ぶ人はいません。

確かに、以前の仕様書に追加する
形だと、一つの仕様書で全ての機能が
網羅できるという利点はありますが、
しかし、それにどこまで必要性が
あるのかも疑問ですし、必要があったとしても
開発が終わってから、追加すれば良いだけの話です。

しかし、それを当時の上司に言っても
聞き入れてもらえませんでした。

・・・

しかし、話はそこで終わりません。

数ヶ月後、その上司は他部署の
勉強会に出席していました。

後日、グループ会議で
その勉強会の報告があったのですが、
その上司の報告内容は、

「○○の部署では、仕様書を書く時には
独立した仕様書を書いていて、
開発が終わったら、それまでの仕様書に追加する
方法を取っている・・・
こんな方法があるんだと思いました。」

といったものでした。

これは、まさに
私が提案して却下された方法です。

確かに、私はその会社の「正社員」では
なかったので、よそ者だったかもしれません。

しかし、よそ者の言う事には
耳を貸さずに、自分の社内の人達の言った事は
無条件で受け入れられる・・・
つまり、本質を見ていないのです。

そこのソフトウェアが何故
周りから評価されていないのか?

・・・その理由は
私がその会社に移って
少し経って、ある程度理解できました。

理由はいろいろ挙げられるのですが、
一番大きな理由は、
ソフトウェア開発の焦点が
ユーザーの方ではなく、
自分達のプロセスの方に
向いていた事だったと思います。

例えば、ユーザーの方から
何か意見や要望があった時に、
うまくやれば、3日で出来る様な事でも
きちんと、要求仕様を決めて
仕様書を書いて・・・といったプロセスを
踏んでいく。そして結局ユーザーに提供するまでには
3ヶ月かかってしまう。

そして、ユーザーの方に提供した時には
既に

「今更そんなもの作られても・・・」

といった言葉が返ってきたりする。

どんなに、重要度や緊急性が高くても
そのやり方を崩さない・・・という開発が
行なわれていました。

しかし、そこの会社は
それを改善する為の
意見を聞く耳も、変化を受け入れる体制も
持っていませんでした。

この様な意識下での開発では、
知識がどんなにあったとしても
無に帰してしまいます。

 

ソフトウェア開発のレベルを
上げる為には、
知識よりも先に意識を上げる事が大事・・・

その事を覚えておいて下さい。