  |
はてなキーワード: BDUFとは
私は大規模・小規模、それこそものすごい人数でのチームや、自分一人のプロジェクトまで経験してきた。化石のような連邦事務局でもクールなシリコンバレーの会社でも働いたことがある。私は１２種類以上のプログラミング言語を学び使っていた。私の時代には ウォーターフォール/BDUF (big design up front), 構造化プログラミング, トップダウン, ボトムアップ, モジュラーデザイン, コンポーネント, アジャイル, スクラム, エクストリーム, TDD, OOP, ラピッドプロトタイピング, RAD, その他思い出せない様々な手法が生まれた。 でもそれらで上手くいってると思えるものは一つもなかった。
（ 注：ここで書いてある「ソフトウェア開発手法が上手くかない」の意味について説明させてほしい。それらはソフトウェア開発のプロセスや、ソフトウェア開発そのものについて予測性や再現性を提供していないという意味だ。ほとんどのソフトウェア開発手法はプログラミングに工学風のプロセスを提供してくれる。しかし、上記の理由でそれだけでは不十分だ ）
チーム生産性・幸福度・メンバーのつながり・１日あたりのコード量・人月・コードの品質・製造された成果物、、、そういったもの以外でソフトウェア開発手法が上手くいってるか、いってないかを図るものはあるのだろうか？
もちろんどんな手法論だって、それに合わせた正しい指標を使えば上手くいってるか・いってないかが計測できる。しかし一番肝心の問題 ーー予算と期限内で要求を満たす事ーー について定常的に結果を図れる開発手法を見たことがない。
上記は私の経験則だけど、僕の知ってる殆どのプログラマは同じような事を経験している。それらの話から言えるのは「ソフトウェア開発手法について厳密な研究は存在しない。なぜならソフトウェア開発上のすべての要素をコントロール事が出来ないからだ」
こんな思考実験をしてみよう、
２つのプログラマのチームがある。どちらも要求・期間・予算はしっかり確定していて、同じ開発環境・プログラミング言語・開発ツールを使うとする。一つのチームはウォーターフォール/BDUFをつかう。もう一つのチームはアジャイルテクニックを使う。
この思考実験にはもちろん意味がない。メンバー一人ひとりのスキルや性格、お互いにどんなコミュニケーションを取るか、そういったことの方が開発手法よりも大きな影響を与えるのは明らかだ。
アリスター・コッバーンが２００３年に"People and methodologies in software development" (http://alistair.cockburn.us/People+and+methodologies+in+software+development) という記事でまとめている。
" 人と人の間で、更には刻々と経過する時間の中で変化するメンバーのキャラクターこそがチームの振る舞い、結果に影響する最初の要因だ。 "
私がプログラミングを始めた1970年当時、開発体制はプロジェクトマネージャー・ビジネスアナリスト・シニアプログラマと言った階層構造でガッチリと管理されていた。開発言語やツールを選ぶことは許されていなかった。私はいくつかの大きく複雑なプロジェクトに関わっていたが大体上記の様な働き方だった。成功したプロジェクトもあれば上手くいかないものもあった。
今は開発言語やツールに合わせて、開発手法・働き方をプログラマが選ぶのが当たり前になっている。アナリストやらがプログラマを監査することは殆どなくなった。プロジェクトマネージャーは"リーダー"・"スクラムマスター"という形で矮小化され、管理職の権限は無力化され「チームの意見をまとめる事」以外は何も出来なくなっている。
ガントチャート・スケジュール・ドキュメントを使った「厳格なマネジメント」は"ユーザー"や"ステークホルダー"の関与を省かせて、"ユーザーストーリー"を要約していた。今や私の周りではまともな大人が監督してるとは思えないプロジェクトばかりだ。プログラマのカウボーイスタイルのコーディングを放っておいてるのに、彼らは自分好きな手法を適用するか作るかさせて、１９８０年代以上に決め事・儀式だらけだ。
実際、今のプログラマは１９７０年代のCOBOLの現場以上に手法論について厳格で、盲信している。実際私が最近関わるプロジェクトは、大体の場合何も価値を生み出さないのに一人か二人のメンバーが開発したプロセスや"ベストプラクティス"を背負わされてるものばかりだ。
プログラミングチームが手法論を採用する（多くの場合チームの数名か、一人のいじめっ子が決めるのだが）と、やがて厳格に従うように要求を始め、やがてそれは宗教になる。そうなることではじまる無自覚な攻撃が、手法論やテクノロジーが生産性を高めるより早く、チームの生産性を下げてしまう。
私の経験から言わせると、アリスター・コッバーンの論文やフレデリック・ブロックスの「銀の弾丸はない」http://www.cs.nott.ac.uk/~cah/G51ISS/Documents/NoSilverBullet.html で述べられているように、プロジェクトを成功させるにはチームメンバーが共通のビジョンを共有する事（その本では「コンセプトの統合」と呼ばれている）が必要だ。特に何かの手法論を指しているのではなく、これと言ったプロセスがない場合でも同じだ。私はプロジェクト管理ツールの「完了」ボタンをクリックするだけのチームで働いことがあるが、何故か分からないがBDUFやアナリストの監査の元で働いていた昔よりも気分が悪いものだった。
私はプログラマは様式やツールにこだわるより、同僚の話にもっと耳を傾け、もっと一緒に働くことに注力したほうが良いとおもう。そしてプログラマは手法論やプロセスについてもっと疑って掛かった方が良いと思う。そうすればみんな魔法の様に生産性が上がる、間違いない。多分プログラマが社交的なスキルを高めるのは他の職業より大変な事だと思う。（私は必ずしもそうだと思っていないが。）でもそういったスキルを鍛える事は、手法論を試すより事よりはるかに元が取れる、間違いない。
これの翻訳です。
http://typicalprogrammer.com/why-dont-software-development-methodologies-work/
注1 '14/02/11 まだ半分しか翻訳してません。（明日完成予定）
