Lazy Diary @ Hatena Blog

PowerShell / Java / miscellaneous things about software development, Tips & Gochas. CC BY-SA 4.0/Apache License 2.0

標準レベル未満のメンバーを開発プロセスの工夫で救えるか

開発プロセスを工夫することで、標準レベル未満のメンバーを救えるのか?という話。

satob.hatenablog.com

satob.hatenablog.com

少なくとも、開発プロセスは「標準レベル未満のメンバーを救うこと」が主目的ではないよなぁ、とは考えています。そういう救いのためには「できない所に触らせない」仕組みが必要で、それは開発プロセスじゃなくて役割分担とか開発フレームワークの役目だよね。

開発プロセス標準化によって普遍的に狙いたいのは以下のようなポイントで、この辺は開発者のレベル関係なく役に立つ。

  • 考えなくていいことを考えなくて済むようにする。どっちでも良さそうなことに決めを作る。
  • 開発に利用している技術や製品のgotchasを避ける。 *1

さて、それとは別に、たとえばCMMIによる生産性向上がすべて幻想か?と言われると、それも違うと思うわけです。ただ、CMMIが計測しているのは「開発者個人のスキルの改善」と「開発者のスキルとは関係ないプロセスの改善」であって、「開発者のスキル不足をプロセスがどれだけカバーできるようになったか」ではない、ということなのだという理解です。

あと、「開発プロセスが優れているために生産性が上がる」というケースが信じられない人でも、「開発プロセスがマズくて生産性が下がる」というケースは信じられるのではないかと思います。この際、開発プロセスが整備されていない(生産性の向上・低下の理由が多種多様すぎて、何が原因なのか切り分けもできない)状況では、あらゆる生産性の向上・低下の原因が「開発者個人の技能によるもの」と誤って認識されてしまうおそれがあり *2、そうならないためにも何らかの形で開発プロセスの整備が必要なんだろうな、と考えています。

*1:大学の技術者倫理の授業で「自分の専門について、自分以外は素人だと思いなさい。自分の専門以外について、自分は素人だと思いなさい」と教えられて、これは今でもよく覚えています。

*2:木下光生「貧困と自己責任の近代日本史」(人文書院, 2017, p.302)に、貧困の原因を考える際「貧困に至る理由の融通無碍さに起因して、自己責任を原因として結論してしまう」という話があり、同じ事象が開発者の生産性についても起こるんではないかと。