「素人まがいのシステム開発」を見分ける方法

自分のプロダクトだっていう意識が皆無なのかテストしないやつ多いよね
最近転職したんだけど、テストしてもリリース後にバグが見つかるからテストは意味がないとかぬかすし
新卒から数年のクソガキが、なぜかプログラマを単純作業労働者かと何か勘違いして下に見ているし
テストをしないプランナーとかディレクター

プログラマーが単純労働者だったとしてもテストは必要。
単純労働ってことは、工業製品なんですよ。で、工業製品はテストと称する品質チェックをしてますけどね。

素人まがいなところで、単純労働者扱いされて働くのは、正直メンタル的にかなりつらいと思う。マトモなプログラマーほどそう。

給料がそこそこあっても、そういうところで働くは、ストレスがたまると思う。
一度もプロ的な仕事をしたことがない人たちは、そういうのは全然気にならないから、平気。

ということで、素人まがいの人たちが、量産されていく。

素人まがいな開発の見分け方と、担当者としてできること

素人まがいの開発かどうかを見分けるのは簡単です。
・テストを甘く考えている
・成果物（ソース）の管理が甘くて、デグレードする
この２つを見るだけで、ほとんどの「素人まがい」は判別することが可能です。
素人まがいのマネージャーも上記をどう考えているかをみれば、ある程度は判別可能です。

で素人まがいの開発に、スタッフ（担当者）として参加した場合は、
「本来はこうあるべきなんです」という態度をとると、人間関係がこじれますし、
また素人まがいのマネージャー（リーダー？）からも嫌われて
なにもイイことがありませんので、注意してください。

担当者が出来ることは、担当者に与えられた権限や責任の範囲しかないことも忘れてはいけません。担当者が、リーダーやマネージャになることは出来ません。たまに、担当者なのにマネージャらしいことまで慈善事業でやっている人もみかけるけど、「人間できたひと」だなぁと個人的には感心する。

あと、素人まがいの人に、素人まがいっていったら大抵の場合、怒りだして態度を頑なにするだけなので
担当者としてよほどの力が無い限りは、そういう人たちを理解させるとか、説得するのもほぼ不可能です。

まぁ「デグレード」って単語が出てきたら「前より悪くなることなんだな～」と思えばOKです。
デグレードとは｜「分かりそう」で「分からない」でも「分かった」気になれるIT用語辞典

素人でもプロ顔負けのものを作れるが・・・

・プロまがいな人たち
・素人まがいな人たち

言葉の定義になるけど、プロって名前がついてるだけマシだと思った方がよい。

素人とプロとの境界はあるようでないんだけど、
素人まがいな開発を定義できるのなら、その区別は出来るはず。

プロなのにとバカにしている人たちがいるが、
素人まがいよりもマシな開発をしていたら、それはプロなんです。

素人には、素人まがいな開発はできても、プロまがいな開発は出来ません。

ここで重要なのは、出来上がる成果物の良さでなくて
開発手法としてのよさです。

このあたりは微妙で、
素人でも、プロ顔負けのものが出来てしまうんだけど、
やってることが、素人まがいな開発手法なだけです。

素人まがいな開発手法は、僕なら嫌だし、そういうのが普通だと思われているようなところでは働きたくないなぁとは思う。

具体的な事例に対して、担当者として出来ることを考えてみる

以下は、「新米マネージャが管理する小規模プロジェクトにおいて発生する諸問題とそ..」を読んだ感想文みたいなものです。

今まで、この手の話でも、現状追認するような擁護するようなエントリーを書いてきましたが、さすがに今回は無理です。ありがちな気はするけど、ここまでひどいのは、色々馬鹿にされがちなSIerとかでもない感じがしなくはないです・・。

テストを甘く見ている

マネージャ「このスケジュールなんだけど、テスト期間長過ぎじゃない？」
プログラマ「え、でも機能もこれだけありますし10日程度は妥当かと」
マネージャ「いやいや、画面たったこれだけじゃない、通しのテストなんてみんなでやれば1日ぐらいで終わるでしょ？」
プログラマ「バグがあったらどうするんですか？」
マネージャ「俺がレビューしてるんだからそんなでかいバグ出るわけねえだろ。ナメてんのか」

---

プログラマ「セキュリティ周りのバグもあるので、修正には3日程かかると思いますが」
マネージャ「ふざけんな！テストは今日で終わるスケジュールだろ！」
新米マネージャが管理する小規模プロジェクトにおいて発生する諸問題とそ..

引用先の文章をどうよんでも、僕には理解できないんです。
大きいバグが、最後の最後で出てしまうのは、テスト工数とか言う以前に、開発の方法自体に問題があるとしかちょっと思えないんですね。

はっきり分かっていることは、
素人まがいの開発をしているところは、テストを甘く見ているということは確実です。

担当者として出来ることは、以下のことぐらいだと思う。
・担当部分で致命的なバグをださない
・担当部分が明確に区別できるようにする
・重要なロジックには関わらない

ただ、担当部分がプログラム部分全てとかそういう場合はこの手のテクニックは使えません。

最終的には、マネージャの意見を取り入れるしかないわけですが
マネージャが決定したという部分を必ず追及して、キレれられたら、こっちも逆ギレするのがよいと思う。
そうできない人たちは、理不尽なことを受け入れて、諦めるしかないかと思う。

ソース管理が出来ていない

プログラマ「前のプロジェクトでgitを使って便利だったので、今回のプロジェクトでも使いたいのですが…」
マネージャ「バージョン管理とか使ってるの?あんなの効率悪くなるからやめたほうが良いよ」
デザイナ「私もそういうの面倒だからあんまり使いたくないな」
マネージャ「前に俺がやってたプロジェクトではフォルダで日付ごとに管理してた。同じ風にすれば大丈夫だろ」
新米マネージャが管理する小規模プロジェクトにおいて発生する諸問題とそ..

新しいバージョンのソフトウェアの品質が、以前より悪くなること。また、以前修正した不具合やバグが再発・復活すること。また、新しいファイルなどを古い内容で上書きしてしまい、更新内容が失われること。
デグレードとは 〔 リグレッション 〕 〔 先祖返り 〕 - 意味/解説/説明/定義 ： IT用語辞典

素人まがいの開発では、たいていソース管理がちゃんとできてなくて、デグレードとか平気で起こります。頻繁にデグレードとか起こってるようなら、もうそういうところとはお付き合いを辞めたほうがよいと思う。

担当者として出来ることは、ソース管理の役を自ら申し出るぐらいしかできないと思う。

メンバーに、gitとか使わせるのが無理でも、共有ファイルベースのソース管理になったとしても、
最終的に、ソース管理アプリで、一元管理できてればトラブルが防げることも多いので、
ソース管理の役を申し出て、ほかの人たちの分まで管理してあげるってことです。

でも、その路線は、現実的な解決策だけど、担当者としての作業量が増える割には、メリットがあまりありません。
ということで、損得勘定のできる優秀な人は、自らそんなことを言いだしません。（でも、文句だけは声高に言うことは忘れない）

ただ、プロジェクト的には、この路線はよいことなので、
マネージャーの立場にあれば、ソース管理の役割を、あれこれ文句を言ってくる人たちにやらせればよいかと思う。

あとは、メンバーにgitなどを使わせるのは、今回は無理で、それでもツールを使った管理の実績を作れば今後は流れが変わるかもしれないという嘘っぽい希望話をして、説得した後に役割をあたえれば、たいていはそういう役目を引き受けることが多いと思う。

想定外のことが起こると対応できない

上司「あれから2週間だけど、こんなにバグ多すぎじゃリリース無理じゃない？」
マネージャ「違うんですよ！デザイナーが全然テンプレートの使い方覚えてくれないし、あのプログラマ人PHPわからないとか言って仕事中にPHPの本とか読んでるから遅れたんです！たぶん自分だけだったらこんなに時間かなりませんよ。」
新米マネージャが管理する小規模プロジェクトにおいて発生する諸問題とそ..

原因らしき文句をいうだけで、解決策をまず考えようとしたいところが、素人まがい。

失敗をしないように計画を立てるのがプロだというわけではなくて
失敗しそうになった時に、計画を立て直せるとか、解決方法を持っているのがプロなんです。

スケジュールの引き方も、結局は適当にひいても、きちんと考えて引いてもそう変わらないことも多いのが現実だと思う。
だって、実際にやってみないと分からないものにたいしてスケジュールを立てるのだから。

過去に似た事例があるとか、過去に全く同じ事例があればよいが、この業界の仕事でそんな簡単な仕事はまずない。

担当者として出来ることは、マネージャーとの力比べぐらい。

フレームワークを使わない、逆にフレームワークを使いたがる

マネージャ「どう、俺の書いたURLルーティングライブラリすごく便利じゃない?」
プログラマ「大文字を使うとうまく動かないのですが」
マネージャ「あー、それは仕様だからしょうがないよ。mod_rewrite使えば問題無いでしょ？」
プログラマ（他人が再発明した車輪のバグを修正するのって本当に不毛だな…）
新米マネージャが管理する小規模プロジェクトにおいて発生する諸問題とそ..

新人さんとか理想に燃える人たちに多いんだけど、
すぐに、話題になっているフレームワークを採用したがるというのも、十分素人くさい。

評価しないで、いきなり使おうというのが、ダメっぽいし、
フレームワークをつかうと、いろいろ楽になることがあるのは事実だけど、
フレームワークを使うことで、落とし穴にはまるっていう発想がないところが素人くさいんですね。

フレームワークでさえも、経験と実績を積むことで意味をなすので
そういうのがない場合は、みんながはまる落とし穴にはまると思っても間違いないと思う。

みんながはまるけど、経験と実績があればはまらないっていうのが、
フレームワーク関係なしに、この業界の開発には多いと思う。

逆に使いたがらないっていうのも多いのかもしれないけど、
予算が削減できるとおもったら、なんでもフレームワークを使うべきだという人たちも結構増えたと思う。

良いものを作る路線と、働きやすい環境とは別だと思った方がよい

Web系のシステム？とかに多い気はするというか、
素人がネットをしていて見かけるものって、そういうのしかないのかもしれないけど

デグレードを起こしているようなところは、いくら良いもの？良いサービスを提供していても、働きやすい環境かどうかは別だと思った方がよいかもと思う。

・デグレードを起こしている
・優秀な人たちが多い雰囲気

この手の場合は、優秀な人たちはわがまま言えて働きやすいという環境だと考えたほうがよいと思う。
その属性に当てはまらない人は、そこでは苦汁をなめさせられる可能性があるってことです。

ソース管理をgitなどのツールをつかうだけで、デグレードがなくなるわけではない。

安易な解決方法は、長期で見ると、ドツボにはまる

新米マネージャが管理する小規模プロジェクトにおいて発生する諸問題とそ..

• [management]
• [はてな匿名ダイアリー]
• [論]
• [*clip]

ダミータスクや過剰見積もり、短期的には有効なんだけど、常態化すると長期的にはかなりのデメリットになったりするので困る。

2014/11/30 15:40

安易な解決方法を、解決案として採用してきた結果、現在があると思う。
テスト工数を理解させるよりも、嘘の工数をでっちあげる方がよいのは、短期の話。

素人まがいの人たちを騙せると思ってるのは、大きな勘違い
素人まがいの人たちは、自分たちにとって都合のよい知識は、早々に手に入れる傾向にある。

テスト工数が必要という知識は手に入れたがらないのに、
開発（テスト抜き）の工数にこれだけかかるのは、おかしいという知識は、すぐに手に入れてくる。