地方エンジニアが感じる地方・中小企業での悩み

低いレベルに合わせることの罠

»

 ここのコラムを読みに来ていただいている人達の中で、業務で開発を行われている人は数多くいると思います。多くの場合、複数人でチームを組み役割を分担しあい開発作業を行っていくことでしょうが、その際には色々とルールを決めることがあるかと思います。対応時の手順や体制、コードの書き方などなど、数えてみると思っている以上のルールが存在しているのではないでしょうか。

 一人で開発するのであれば、そういったルールもさほど出番はないのですが、複数人で行う場合には、何かしらのルールがなければよりよい結果を出すことは難しいと言われています。実際に、人によって作業の方法が変わってしまうのであれば、一定以上の成果を出すことは非常に困難で、品質にもばらつきが生じます。

 会社として問題のない品質を生み出すためにも、何らかの制約が必要になるのは致し方ない点があるのですが、どこに視点をおくかによってその制約はメンバーのモチベーションを下げる大きな要因にもなり得ます。

 例えばコーディングの際のルールとして、コーディング規約を定めているところは多いと思います。自社の中で、またはその案件固有のルールとして定められたそれは、誰がやっても同じレベルの品質を維持するために必要と言われています。ですが、その規約のレベルによっては、10年以上前のコーディング方法であったりするので、開発しながらも納得のいかない人を多く生み出していたりもします。

 会社視点で考えると、このような誰が行っても一定の品質を生み出せることは、大変重要な事だというのは理解できるところです。ですが、使う側にしてみればそこはさほど重要ではなく、スピーディに対応できるような規約であってほしいと思われることでしょう。

 最新の技法にならうのをルールとする、とまではいかなくとも世の中に出て数年たったのであれば、それは技術者として当然知っているのが望ましいと私は考えます。.NET の世界で言えばよく話題にあがるのは LINQ で、企業によっては読めない人がいるから禁止、とこの技術が登場してから一体何年経過していると思っているんだ、と言いたくなるような環境もまだまだたくさん見かけられます。

 サラリーマンとして開発を行っている人達を卑下しているわけではありませんが、さすがに登場して 10 年、古くは Visual Studio 2008 から利用できる書き方です。それを読めない人がいるから、といって利用しないよう定めているのは、少なくとも技術を扱う企業としてあるべき姿ではないでしょう。そのような規約を定めているということは、自分たちの技術は 10 年は遅れています、と言っているようなものです。

 このような規約を定めている会社は、何故かこの点を深く考えていないように思えます。確かに、出来上がった成果物の質、という点だけを考えるのであれば、今では多種多様な方法がありますので、一つの技術にこだわるメリットは薄いのかもしれません。ですが、私にはそれは技術を扱う立場を放棄しているだけではないか、そう感じられるのです。よく言えば枯れた技法を選択していることが、問題だとは思いません。枯れた技法しか選択肢がない状態が、開発する側にとっては大問題だと思っています。

 このように考えると、低いレベルに合わせて規約を整えるというのは、長い目で見るとあまりメリットのないことなのではないでしょうか。参加しているメンバーの平均よりもやや上のあたりに、ベースラインを設けることこそが、これからもふまえるとベターな方法論なのではないでしょうか。

 マネージメント側に立つと、どうしても今ある戦力での動き方に目を奪われがちで、今の戦力を育てる方向へはなかなか進みにくい、というのは理解できるところです。ですが、それをやっていかなくては、いつまでたっても現状維持に近いけど実際は退化している状況に陥ってしまいます。

 一つの仕事を質良くこなすことは確かに重要です。ですが、そこに成長する要素が何もないのであれば、それはどこかで打ち止めになってしまってもおかしくありません。そうならないためにも、今より少しだけでも上を目指す、そういったレベル間でのルール定義が必要なのではないでしょうか。

Comment(2)

コメント

ハリコフ

記事を読んでいると、低いレベルに合わせて規約を作るよりも、むしろ機能の難易度や特性で区分けして、その単位で規約を作るっていうのも面白いかなって思いました。

自然とレベルの高い人が誰でも出来るような雑用レベルの仕事から解放されて、やりがいのあるレベルの高い仕事に割り振られるようになる・・・かなと。

まぁ、現実的には壁が高すぎて難しいでしょうけど。

しっかし、現実に存在するレベルの低い人の扱いは、確かに悩みます。でも、他に平易な方法があるのに無駄に難しい作りをする頭の良い人もいるので、実はお互い様だとも思ったりします。

山無駄

お客様が自分自身でテーブルとカラムの命名規約を作り開発会社に強制したところ、あまりにも
意味不明な名称になったため開発ができなくなり、開発会社は自分たちのルールとの変換表をつ
くって見比べながら開発した、という笑えない話を聞いたことがあります。

また、急にルールが必要となったので何処からか適当にコピーして持ってきて取りあえず使って
いたが、いつのまにかそれが社内で標準となり、誰もなぜそのルールが存在するかもわからない
まま使い続ける、なんてのもよくある話です。

ルールも漫然と導入して使っていても何もメリットはないので、「目的を踏まえた設計」「導入後の徹底」「ルールが目的に沿っているかの評価」「評価、改定もしくは廃止」のPDCAサイクル
が必要なのでしょうね。

コメントを投稿する