恐怖駆動開発、あなたの体験は？ 117
ストーリー by headless
恐怖 部門より
恐怖 部門より
本家/.「Ask Slashdot: Have You Experienced Fear Driven Development?」より
数年ほど前、東南アジアで規模の大きなWeb開発プロジェクトに参加した。正式にはアジャイル/スクラム開発手法が取り入れられていたにも関わらず、実際の開発はマネージャーが押し付けてくる恐怖で駆動されていた。Scott Hanselmanの定義によると、恐怖駆動開発(Fear Driven Development: FDD)には以下のような3種類がある。
- 組織的な恐怖: 開発者はミスを犯すことやビルドを破損すること、バグを生み出すことを恐れ、組織は書類の作成に注力して過剰なプロセスを生み、コードを書くことを妨げる。
- コード変更の恐怖: 既存のコードを変更することで予期しない副作用が発生する可能性や、修正済みのバグが復活する可能性などにより、開発者はストレスを感じる。コードベースが古く、内容をよく理解できていないことなどが原因。
- 失業の恐怖: 組織が解雇をちらつかせて開発者に長時間の重労働を強いる。開発者がまともに動作しないコードをチェックインしたり、失敗を認めたくないマネージャーがデスマーチに導くといった結果になる可能性がある。
私が参加したプロジェクトは当初予想の4倍の期間がかかり、1日18時間、週6日労働になることもあった。FDDは定着しているのだろうか。
あるある過ぎる (スコア:5, 興味深い)
＞組織は書類の作成に注力して過剰なプロセスを生み
ソース内のコメントミスを1箇所修正するのに
・修正仕様説明資料とその打合せ議事録(1,2次受けに2種類)
・第三者込みのソースレビューと議事録(1,2次受けに2種類)
・単体/結合/システムテスト仕様と議事録(1,2次受けに2種類)
・単体/結合/システムテストの品質報告資料と議事録(バグ0の説明が必要ｗ)
・単体/結合/システムレベルでの性能評価資料と議事録(劣化無しの説明が必要ｗ)
・単体/システムレベルでのセキュリティ報告資料と議事録
・水平展開調査資料とその打合せ議事録(1,2次受けに2種類)
・バグ発生原因の追求資料とその打合せ議事録と発表会と発表会の議事録
・出荷の申請書とソースマスタ変更依頼
・出荷の作業手順書と議事録
・顧客説明資料とその打合せ議事録
・出荷の客先入館申請書
・出荷の結果報告書
とまぁ、うんざりする程の資料を作らされる某プロジェクトの事ですね。
ついでに言うと
1.コメント変更前後に影響が無い事を証明するために、バイナリのハッシュ比較をする
2.ハッシュの衝突で無いことを証明するために複数種のハッシュ関数を使う
3.ハッシュ実装のバグで無い事を証明するために、異なるOS(Win/Linux)上でハッシュを取る
とか、やらされた時には、コイツら病気か?と思った。
なお、作業結果はA4資料数枚にわたって仔細な手順付き資料を作った上で、1,2,3次受け全員(10人位)を集めて検討を重ねた……。
※結果はNG、客にコメントミスを(悪印象になるから)報告できないからだってさ
※※という結果なので、顧客に金が貰えず、埋め合わせで作業単価の下方修正を強要される
Re:あるある過ぎる (スコア:1)
話が少々違うのかもしれないが、、
>で、開発者側としては、クソみたいな手順→やーらない、と言うのはマズイとも言っている訳です。品質管理は、システム開発の重要な部分なのですから。
それそのものは否定したくはないのですが。
要するに品質管理するための「手順」は定められない(定めきれない)と考える方が正しいと思います。
なので、せいぜい「よりましな」手順を決めることが出来るぐらいなのでは。
統計から、ある手順を抽出する場合、システム(の不良率)が正規分布する前提が必要です。
システムの不良原因を除去するため、各工程の不良率を測定します。
で、不良が多数発生した部分は正規分布する前提で、不良が多発する部分を除去する手順を策定するわけだ。
でも、システムは生き物で、必ずしも、不良原因が正規分布するわけじゃないような気がする。
最近、「サービス」製品(っても必ずしもソフトウェアだけではない)の、
いわゆる「DevOps」っぽい、運用と開発が一体になったようなところにいますが。
そのようなところにいると、各工程の品質が云々、というは意味があると思えないのですな。。
不良原因が、ころころ変わりまくるのではないかと思っています。
もちろん、品質は重要ですし、品質向上のために手順を定めるのは悪いことではありませんが
実際には、手順を定めきれないのではないのかと疑ってます。
結局「統計データに表れる」というのは思った以上に、現れない部分がある気がします。
今後、ソフトウェア開発は、純粋にソースコードを記述するだけてなく、
「サービス」や「IoT」なども「ソフトウェア開発」と呼ばれます。(というか呼ばれてますが)
その場合、いままでと同じような「システム開発」の「統計データ」を当てはめることはできないような気がしています。
なので、「統計データ」を取ると品質管理ができると仮定することは無理があると思っているのですが。
#だからなんもするなとは言わないのですが。。。
Re:あるある過ぎる (スコア:1)
>大人と言うより子供、単なる駄々っ子に見えるが。
んー、なんか違和感がありますかね。。
品質で重要なのは、「不良を出すな」と命令することではなく、不良を出さないように皆で協力する、ですよね?
ちがうのかしら。
「不良の原因なんかわかんないよ」というのは駄々っ子ではなく、現場の実感なのでは。
がちがちの手順で縛るのは、「不良を出すな」と命令されているようで、重要なところを外しているような気がします。
スペイン流管理手法 (スコア:3, 興味深い)
というやつですね。ピープルウェア [amazon.co.jp]にあったので覚えてます。
ググったら丁度紹介されている方がいたのでリンク [geocities.jp]を張っておきます。
15世紀位(おそらくその前から)からある伝統的手法です。
まともな技術者は逃げてしまうので長期的には非効率的な筈ですが、中々なくなりませんね。
どうしてなんでしょう。
Re:スペイン流管理手法 (スコア:1)
給料が安かったりして元々優秀な人があまりいない職場だと有効な方法なのでしょう。
それで元々少ない優秀な人が逃げてしまい、うまく仕事が回らなくなるとますます
締め付けを厳しくするという悪循環に陥ります。
マネージャーを選ぶときも頭がよくて優秀な人がいればいいのですが、そういう人がいない場合
声が大きいとか、ケンカが強いとかの人間をマネージャーにして恐怖駆動開発をやらせます。
Re:スペイン流管理手法 (スコア:5, すばらしい洞察)
この業界に実業団のラグビー部やアメフト部を抱える会社が多い理由が判った気がします。
Re: (スコア:0)
+1.
その発想はなかった。納得です。
実業団を持ってる=余裕がある、に違和感があったのですが、これは納得。
Re: (スコア:0)
じゃじゃ～ん！まさかのときのスペイン流レビュー！われわれの監査項目は１つ！
Re: (スコア:0)
むしろタイトパッカーとルースパッカーと言ったほうがしっくりくる。
どっちみち奴隷だろ。
最近も難民が海に投げ込まれる事件がおきたけど、海の上では損耗より恐怖でコントロールしやすくしたほうが効率がいいんだろ。
人気言語の場合代わりはいくらでもいるんだから消耗品扱いされるだろうな。
Re:スペイン流管理手法 (スコア:1)
東南アジアで取り入れられている日本の悪習は日本固有か否かという疑問。
…いや、タレコミの本文ぐらい読もうよ。
ネガティブな考えだと (スコア:2)
恐怖駆動開発だろうが何だろうがサービスイン出来ればこっちのものという考えもあるんでしょう
Re:ネガティブな考えだと (スコア:1)
技術的負債が積み重なると、サービス拡大やその先で問題となることも多いんですけどね。
こんな開発手法じゃ、そこまでたどり着けた例が少ないから、あんま問題になってないとかだったりして。
＃ ソシャゲ業界の話で、黎明期の頃はどんなゲームでも売れたけど、「サービスインできるだけの会社」はアクセス数に耐えられずバタバタと死んでいき、「アクセス増に耐えられるだけの基盤を持った会社」だけが現在に残っている、とか聞いたので、完成さえすればOK的なのは結構危ない。
マネージャーが悪いんだー (スコア:0)
俺は悪くないぞー
マネージャーがやったことは恐怖駆動開発って言われることだぞー
だから俺は悪くないぞー
いや、気持ちはわかりますけどね……。
Re: (スコア:0)
そこまで先回りしてコメントする気持ちはよう分からん…
信頼駆動開発 (スコア:0)
私自身の経験としては、デスマーチはありますが、恐怖を感じたことは皆無です。
そもそも恐怖 って何？、職場に恐怖なんてあるの？と思って、逆の概念として"信頼"ってのを考えてみました。信頼駆動開発です。
１） 組織的な信頼: 開発者はミスやビルドの破損、バグを生み出すことを恐れていない。
なぜなら、組織は書類の作成にも注力しており、信頼できる仕様・テストケースがあり、開発者は各自安心してコードが書ける。
２） コード変更に対する信頼: 既存のコードを変更すること生じうる、予期しない副作用・バグが復活は簡単に検出・修正できる。
開発者はストレスとは無縁である。
なぜなら、コードベースが古かったり、実装がよく理解できていなくても、
信頼できる仕様書・テストケースがあるため、副作用やバグは自動で検出でき、すぐに修正できるからである。
３）組織への信頼: 組織は契約に基づいた労働しか求めない。
開発者がまともに動作しないコードをチェックインしても、それはユニット単位でのテストで検知でき、
マネージャはユニット単位で修正を指示するだけ。
コードを書く人、テストする人、修正する人、マネージャ、各自割り当てられた業務を粛々とこなすだけである。
こうやってみると、
- 同僚やチーム全体を信用も信頼もできない
- 自身にも彼らと上手く連携して仕事を進めるためのスキル（コードの質とか、テストや仕様書の作成能力、改善の提案能力）がない
場合、その開発者は恐怖駆動に陥ると言えるかも知れません。
心理学的には、恐怖とは人間の防衛機制から生じるものです。
ここからは意地悪な解釈ですが、恐怖駆動とは
自分のスキルを超えた、自分ではコントロールできない状況（つまりデスマーチ）に陥った不幸な人が
本能的に「自分は悪くない、同僚やチームが悪い（＝信用できない）」と自己に言い聞かせて、現実逃避した結果であるようにも思います。
とにかく、私は良い職場に恵まれたようです :-)
Re:信頼駆動開発 (スコア:1)
「お前バカだろ」とか「愚かしい」みたいなモデレートが欲しくなるな
Re:信頼駆動開発 (スコア:1)
１，２の理由に書いてある「信頼できる仕様・テストケースがあり」と、
３の「粛々とこなすだけ」ができるのも「信頼できる仕様・テストケースがあり」
ということだろうから、なんだかんだ言っても
「信頼できる仕様・テストケースがあり」
という一点がクリアされれば、何とでもいえるってことかな。
Re: (スコア:0)
ネタでも本気でも少し休んだ方がいいと思うよ。
ソフトウェア工学を歪めているのは (スコア:0)
ソフトウェア工学を歪めているのは、ソフトウェア工学の実践の場である開発の場で、
「こうもり」行為をする人間では無いか。
＃もちろんこうもりさん自体をdisっている訳では有りません。自宅近くの川の暗渠が
＃切れた辺りに居て、夕方なんか川の上をひらひら飛んでいるのは風情があります。
＃あくまで比喩での「こうもり」です。
「こうもり」行為とは、
・客先では開発側の人間を気取り、
・開発現場では客側の人間を気取る
行為で、
これをすると、
・した人間には一切責任が加わらない。
・その代わり、何一つ生の情報が入らず、針の音程度でも魂切る位驚く。
驚くだけならいいけど、その驚きを他人のせいにする。
・テスト設計に関して最高の位置に居る（客と開発の接点）にもかかわらず、
何もしない。何もしないだけならいいけど、テスト設計の肝の情報を握り
潰す。
・以上の経緯から、周りに（漠然とした）恐怖をまき散らす。それを何とか出来る
情報に接する唯一の人間なのに、なにもしない。
・しないことを誇りにすら思っている。
こんな人間が居ると、ソフトウェア工学の実践上、良いが悪いになり、悪いが良いに
なり、へんなメッセージをアカデミアの人間に発する事になってしまう。
別に全ての人間にプログラム開発をしろとは言わないが、が、「こうもり」行為だけは
困る。
完全に違います (スコア:1)
「こうもり」行為とは、
・客先では客側の人間を気取り、
・開発現場では開発側の人間を気取る
行為です。
Re:完全に違います (スコア:1)
「こうもり」行為とは、
両親をデスマーチで殺された少年が、デスマーチ根絶を誓い、
修行したり、資産家になったりした後に
高性能スーツに身を包んで、夜な夜なアレなSEとかPGとかクライアントを仕置きする
行為です。
#こんな俺でも今では立派なプロジェクトマネージャー
##でもプロジェクトは炎上するのだ
これぞ理想像 (スコア:1)
＞・客先では開発側の人間を気取り、
＞・開発現場では客側の人間を気取る
良いマネージャすぎてワロタｗ
Re: (スコア:0)
だから、これをいいと思うのが大問題です。
客先、現場、どちらの場面でも無責任に
なる点が問題です。
たしかに正調の「こうもり」は、
〉・客先では客側の人間を気取り、
〉・開発現場では開発側の人間を気取る
で、こちらなら問題ないですが、
自分の言っている、
〉・客先では開発側の人間を気取り、
〉・開発現場では客側の人間を気取る
だと、常に当人は傍観者になり、場所ふさぎ
にしかならないです。（ネゲート基準の
こうもりです。）
悪いを良いと思い込んでいるから、何時までも
同じ事が繰り返されるのが判らないのですかね！
悪いを良いと判定するソフトウェア工学は
世に仇なす有害な知識です。
Re: (スコア:0)
ナニいってんの（笑）
Re: (スコア:0)
だから、
寓話のこうもりも
鳥に対しては地を這うものといい、
地を這うものに対しては鳥といい、
あの丘の向こう側を見てみたくないか？
とか言ったら、評価も全然違うだろう、
という話です。
Re: (スコア:0)
要は全権を握っている傍観者ってことだよね。
双方で「気取っている」だけでその側には立っていないという。
でも、そんな程度の人間を全権を握った立場から追い落とせないのは、
よほど開発者の力量が低いか、超恐怖駆動の組織でしかありえないと思うけど。
それはマネジメントの問題だろう (スコア:0)
「こうもり」行為はソフトウェア工学の問題か？そも工学の対象ですらない。
Re: (スコア:0)
ソフトウェア工学の問題です。
根本的に解決したいなら、ソフトウェア工学といえど、
マネジメント分野に切り込まなくて、どうするの
ですか。
Re:それはマネジメントの問題だろう (スコア:1)
だからそれは、マネジメントの問題であって工学の問題じゃないだろう？
Re:それはマネジメントの問題だろう (スコア:1)
よし、マネジメント工学という学問領域を作ろう！
信仰駆動開発 (スコア:0)
うまく動くように祈る。機能がバグっているけどばれないことを祈る。
ここをこうすればよくなると信じている（が動かない）。何故かこれを消すと動かない。
誰かやってくれることを祈る。確率的に運がよければ動くから信じろ。
どこまで行ってもこの宗教はなくならないな。
Re:信仰駆動開発 (スコア:1)
実行する前に手を合わせてお祈りしますよね。
Re:信仰駆動開発 (スコア:1)
なんか記憶に引っかかるなと思ったら「マリオノール・ゴーレム」（ゴーレム精霊駆動法儀）だった。
＃大清水さちさんのニャルラトホテプ漫画
らじゃったのだ
能力のあるPGをアサインできなかっただけでは？ (スコア:0)
色々と理由はつけてるけど、案件の難易度にあったスキルとレベルのPGをアサインできなかった、ってだけじゃ。
改修案件で元のソースを理解できないとか、ビルドエラーが取れないコードをコミットするとか、もう駄目駄目じゃん
ゆとりだなあ (スコア:0)
＞1日18時間、週6日労働になることも
なんだ、まだ１日もマージンがあるじゃないか
そんな退屈な仕事じゃ評価対象にもならないという恐怖が襲ってきそうだ
ハードパンチ (スコア:0)
初めてのお仕事の時のこと。
ある意味その会社はかなりヤばいところだったけど、金払いはよかった。「いつまでにできる」と社長に約束して開発に取り掛かった。
先輩は自分より一日先に仕上がる予定であり当日を迎えた。
先輩「すみません、あと少しでできます」
社長「お前ができるといった日だぞ！！」
と言うことで、ハードパンチが飛びまして、先輩は私の机の横でボコボコに。（血が飛んできた）
社長「明日はオマエだな？できるだろうな？」
私「はい、できますっ」
社長「がんばれよ」
まさしく恐怖駆動開発でした。
分からないところは聞くなり作ってもらうなりしてなんとか間に合わせてギリギリセーフ。
もうやめてかなりたつけど、あの会社知らない間に大きくなってたwwww。
懐かしいなぁ・・・
Re:ハードパンチ (スコア:1)
遅れるなら事前に報告すればよかったのにね。
社長は遅れたことに怒ったんじゃなく、余裕持って相談されなかったことに怒ったんでしょ。
Re:ハードパンチ (スコア:5, すばらしい洞察)
いや、そんなことより、単に傷害事件なのに。
Re: (スコア:0)
ミスをしたら流血沙汰
注意するときは拳で語り、殴られた本人には何が悪かったのか伝えない
あなたのところの会社名教えてほしいわ
そんな会社には間違っても入社したくないから
Re: (スコア:0)
守れない日付約束するからだ。5割増しくらいの日付で約束すべきだった。
ソフト業界くらいじゃないかな日付がずれても許される文化があるのは
Re:ハードパンチ (スコア:1)
タイムゾーンも暦も指定してないから、いくらでも言い逃れができます。
ましてシステムだとアプリケーション日付（05:00-30:59みたいな）というものもあるし。
Re: (スコア:0)
日本は偉大だーみたいな話がいいって？
最近あるの？そういう話。
Re: (スコア:0)
> 日本は偉大だーみたいな話がいいって？
日本には偉大な人もたくさんいるけど、
偉大な日本人の話をしても、自分が偉大だというわけじゃないからね。
自分が偉大だと勘違いする人は、頭がおかしいと思う。
え？そんなやついないって？
でも、日本人や日本のことをけなすことを「自虐」だと言うのは、まさしく同じ勘違いじゃないの？
って思う。
Re:週末恒例の自虐ネタスレッド (スコア:2)
確かに、日本人が自分以外の日本人をけなすのは自虐じゃないな。モデ権あったら+1.
新人。プログラマレベルをポケモンで言うと、コラッタぐらい
Re:週末恒例の自虐ネタスレッド (スコア:1)
＞日本には偉大な人もたくさんいるけど、
＞偉大な日本人の話をしても、自分が偉大だというわけじゃないからね。
＞自分が偉大だと勘違いする人は、頭がおかしいと思う
これは、個別例を過度に一般化しているケースにあたるので、その通りだと思う。
が、
＞でも、日本人や日本のことをけなすことを「自虐」だと言うのは、まさしく同じ勘違いじゃないの？
これは、もともとが一般化された言説（日本人は～、日本は～）だから、全然同じではない。
（過度な一般化を行わない）「ひどい日本人、ダメな日本人がいる」だけの主張を「自虐」だという人は見たことない。
むしろ、太平洋戦争を正当化する主張の人は陸軍の牟田口中将あたりを忌み嫌ってるように思います。
Re: (スコア:0)
ソフトでは日本は半島に負けていると思う。
けんちゃんで橋も落とすし、デパートも崩すけど、
ソフトでは、それが有利に働いているとしか
思えない。
ソフトでは日本ははなから挑戦者でしょう。
Re:週末恒例の自虐ネタスレッド (スコア:2)
Re: (スコア:0)
あなたが関心のあるネタをタレこんでもよろしいのよ?
Re:失業の恐怖 (スコア:1)
日本では
転職が多い=仕事が続かない=社会的階層が低い、
ように見られたり、
非正規＝新卒採用されなかった=社会的階層が低い
ように見られるからでしょうね。
アメリカでは仕事内容が決まっていて
スキルアップや給与増のためには
転職が必要な傾向が
日本より強いんだと思います。
職務給、職能給、どちらがいいんでしょうか。
-- 風は東京に吹いているか
Re:失業の恐怖 (スコア:1)
「出来ない」は、良いところに転職することが「出来ない」と考えるのが妥当なのでは。
実際、転職したら生涯所得が低くなりますしね。(統計上)
http://www.jil.go.jp/kokunai/statistics/kako/2012/documents/17_p211-220.pdf [jil.go.jp]
転職して給料が低くなるなら、転職しない方がいいのは明らかですよね。。