SSブログ

いつも受け入れられるとは限らない改善提案 [プログラマー現役続行]

社会人となって30年間、様々なソフトウェア開発従事していた経験から言うと、改善提案は上位のマネージャや部門長に受け入れられる場合とそうでない場合があります。その中でも、問題が発生してから、その問題を解決するという改善提案は受け入れられることが多いです。しかし、発生するであろう問題を予測して、それに対して事前に対策を打つという改善提案は、理解されなくて、受け入れらないことがあります。

問題が発生してからの改善としては、ソースコード管理用のリポジトリは用意していたが、開発の終盤までビルドは、一人の開発者のPCでしかできなくて、ビルドを間違いなく行う必要がでてきて、やっとサーバで自動ビルドが一日一回行われるとかです。さらに、コードの品質が悪くてバグがたくさん出るので、FindBugsなどの静的解析ツールを導入して改善しますと言った提案です。しかし、静的解析ツールを導入した時点ではすでに遅く、すべての警告を修正することができなかったりまします。そうすると、どの警告を修正するかしないかの分類をしようということになるのです。

一方で、同じ状況で、プロジェクトが開始された時点で、継続的インテグレーション環境や静的解析ツールを導入して、最初からすべての警告を潰していきましょうという提案は、そのような環境を準備するために工数を費やす利点を理解できなくて、却下されたりすることがあります。あるいは、説得するために多くの資料を作成させられることになります。

この場合、問題が発生してからの改善提案は、上位のマネージャに対して「提案活動をした」ということで評価されるでしょう。しかし、予測される問題に対する改善提案は評価されないかもしれません。そうなると、事前に予測される問題を潰すという改善提案を現場はしなくなるわけです。

どのような問題が発生するかを予測するには、予測される問題を過去に経験して、それを解決したという経験がないと、できないかもしれません。その意味で、上位のマネージがそのような経験を積んでいる必要がある訳です。しかし、逆に考えると、そのようなマネージャであれば、プロジェクトが開始された時点で開発環境の整備などをトップダウン的に指示するはずであり、現場が改善提案をする必要がないわけです。これは、マネージャでなくても、中堅のソフトウェアエンジニアに対しても当てはまることです。

私も、ある時、中堅のエンジニアに対して、これから、たくさんの機能を開発していなければならないので、古いCVSを用いた手作業のビルド環境から、Subversionを用いた継続的インテグレーション環境を整備して、単体テストも整備すべきと提案したことあるのですが、「これから開発しなければならない、たくさんの機能と開発環境の整備のどちらの優先順位が高いか精査して、開発環境の整備の方が高ければ人を割り当てます」と言われたことがあります。正直自分の耳を疑ったのですが、議論してもしかたないので、その後、自分と若手の協力会社の2名で開発環境整備して、全面的に移行させてしまいました。

あるいは、別の遅れているプロジェクトでは、遅れを取り戻すために私が手伝えることを5項目ほど列挙して、その中にも継続的インテグレーション環境の構築も含まれていたのですが、すべて却下されたことがあります。残念ながら、そのプロジェクトは、私が予測した通りの問題が多数発生していました。

このようにマネージャや部門長などへのソフトウェア開発に関する改善の提案は、その内容によっては、すんなり受け入れられる場合と、本質的な提案であっても「理解されない」場合があります。