2014-02-12

何でソフトウェア開発の手法って上手くいかないの?

私は大規模・小規模、それこそものすごい人数でのチームや、自分一人のプロジェクトまで経験してきた。化石のような連邦事務局でもクールシリコンバレー会社でも働いたことがある。私は12種類以上のプログラミング言語を学び使っていた。私の時代には ウォーターフォール/BDUF (big design up front), 構造プログラミング, トップダウン, ボトムアップ, モジュラーデザイン, コンポーネント, アジャイル, スクラム, エクストリーム, TDD, OOP, ラピッドプロトタイピング, RAD, その他思い出せない様々な手法が生まれた。 でもそれらで上手くいってると思えるものは一つもなかった。

( 注:ここで書いてある「ソフトウェア開発手法が上手くかない」の意味について説明させてほしい。それらはソフトウェア開発のプロセスや、ソフトウェア開発そのものについて予測性や再現性を提供していないという意味だ。ほとんどのソフトウェア開発手法プログラミング工学風のプロセス提供してくれる。しかし、上記の理由でそれだけでは不十分だ )

ソフトウェア開発手法が上手くいってる」っていつ言うことが出来るの?

チーム生産性幸福度メンバーのつながり・1日あたりのコード量・人月コード品質・製造された成果物、、、そういったもの以外でソフトウェア開発手法が上手くいってるか、いってないかを図るものはあるのだろうか?

もちろんどんな手法だって、それに合わせた正しい指標を使えば上手くいってるか・いってないかが計測できる。しかし一番肝心の問題  ーー予算と期限内で要求を満たす事ーー について定常的に結果を図れる開発手法を見たことがない。

上記は私の経験則だけど、僕の知ってる殆どプログラマは同じような事を経験している。それらの話から言えるのは「ソフトウェア開発手法について厳密な研究存在しない。なぜならソフトウェア開発上のすべての要素をコントロール事が出来ないからだ」

こんな思考実験をしてみよう、

つのプログラマのチームがある。どちらも要求・期間・予算はしっかり確定していて、同じ開発環境プログラミング言語・開発ツールを使うとする。一つのチームはウォーターフォール/BDUFをつかう。もう一つのチームはアジャイルテクニックを使う。

この思考実験にはもちろん意味がない。メンバー一人ひとりのスキル性格、お互いにどんなコミュニケーションを取るか、そういったことの方が開発手法よりも大きな影響を与えるのは明らかだ。

アリスター・コッバーンが2003年に"People and methodologies in software development" (http://alistair.cockburn.us/People+and+methodologies+in+software+development) という記事でまとめている。

" 人と人の間で、更には刻々と経過する時間の中で変化するメンバーキャラクターこそがチームの振る舞い、結果に影響する最初の要因だ。 "

私達の最大の敵

私がプログラミングを始めた1970年当時、開発体制プロジェクトマネージャービジネスアナリストシニアプログラマと言った階層構造ガッチリ管理されていた。開発言語やツールを選ぶことは許されていなかった。私はいくつかの大きく複雑なプロジェクトに関わっていたが大体上記の様な働き方だった。成功したプロジェクトもあれば上手くいかないものもあった。

今は開発言語やツールに合わせて、開発手法・働き方をプログラマが選ぶのが当たり前になっている。アナリストやらがプログラマ監査することは殆どなくなった。プロジェクトマネージャーは"リーダー"・"スクラムマスター"という形で矮小化され、管理職権限は無力化され「チームの意見をまとめる事」以外は何も出来なくなっている。

ガントチャートスケジュールドキュメントを使った「厳格なマネジメント」は"ユーザー"や"ステークホルダー"の関与を省かせて、"ユーザーストーリー"を要約していた。今や私の周りではまともな大人が監督してるとは思えないプロジェクトばかりだ。プログラマのカウボーイスタイルコーディングを放っておいてるのに、彼らは自分好きな手法適用するか作るかさせて、1980年代以上に決め事・儀式だらけだ。 

実際、今のプログラマは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 まだ半分しか翻訳してません。(明日完成予定)

注2 '14/02/12 翻訳完了しました。コメントの指摘に対応して文章を一部直しました。ありがとうございます

トラックバック - http://anond.hatelabo.jp/20140212004731
  • http://anond.hatelabo.jp/20140212004731

    一人称を私か僕かどっちかに統一しろ。 ―(ダーシ)は一つだけだと漢数字の一や音引きと見分けがつきづらいので二つ並べて使え。

  • http://anond.hatelabo.jp/20140212004731

    そもそも以前なんだよね ソフトウェアの構築に素人を1カウントとしてる時点で 手法以前の話なんだよね 家の設計する際に素人呼んで人数カウントするか? しないよな? そっからなんだ...

    • http://anond.hatelabo.jp/20140212173911

      建築現場でも何の技術知識も無い派遣作業員がやれることはいくらでもある。(そういう派遣的な人の使い方が良いか悪いかは別として) ソフトの構築だって言ったって、今や最低大学で...

      • http://anond.hatelabo.jp/20140212180803

        んで、プログラマー()とか言ってる奴の仕事の大半はただただ命令通りにコードを書いてくだけなんだから一昔まえの事務仕事と一緒。 誰でも出来る簡単なお仕事。 プログラミングし...

        • http://anond.hatelabo.jp/20140212183720

          http://anond.hatelabo.jp/20140212180936 http://anond.hatelabo.jp/20140212182634 http://anond.hatelabo.jp/20140212183140 流石増田www プログラマー()をバカにされたや矢のような反論www どんだけ自分たちをスーパーマン...

        • http://anond.hatelabo.jp/20140212180936

          んで、プログラマー()とか言ってる奴の仕事の大半はただただ命令通りにコードを書いてくだけなんだから一昔まえの事務仕事と一緒。 誰でも出来る簡単なお仕事。 プロ...

          • http://anond.hatelabo.jp/20140212183819

            元の建設現場がチョロいみたいな話とも繋がるんだけど。 ○○はチョロいって言っている人って、そんな工程にしか参加してない(出来ない)って場合が多い気がする。 日曜大工じゃ...

            • http://anond.hatelabo.jp/20140213135420

              工事現場には普通に派遣の人が作業に使われてたよ、派遣が普通にあった時代は。 物運びとかただただ人手が必要なことなんていくらでもあるから。 別に、実際「大工」とか、重機操っ...

      • http://anond.hatelabo.jp/20140212180803

        〉〉ただただ命令通りにコードを書いてくだけな これよく言われるけどフリーランスでやってきてそんな場面見たこと無いんだけど。。 そんなのどこにあるの?cobol限定の話? コボル限定...

      • トラックバック - http://anond.hatelabo.jp/20140212180803

        設計できるの?素人が? 出来ないでしょwwww コーディングは設計なんだから 建物の設計って素人ができるの? 建築業界って簡単なんだね

      • http://anond.hatelabo.jp/20140212180803

        んで、プログラマー()とか言ってる奴の仕事の大半はただただ命令通りにコードを書いてくだけなんだから一昔まえの事務仕事と一緒。 誰でも出来る簡単なお仕事。 なぁなぁ、それ...

        • http://anond.hatelabo.jp/20140214070655

          日付の計算もライブラリ依存だし、CSVの出力もライブラリ依存の、極めて無能なプログラマの俺には関係なかった。 むしろ動くけど遅いとか、そういう問題のほうが多いな。マシンパワ...

        • http://anond.hatelabo.jp/20140214070655

          なぁなぁ、それってつまり、お前の所、無能な馬鹿ばっか、ってことだろ? んで、そいつら給料もらって飯食ってるんだろ? で、そんなのが当たり前なんだろ? そしたら んで、プロ...

        • http://anond.hatelabo.jp/20140214070655

          まともに相手にするなって。 そいつはプログラマを馬鹿にして暇を潰したいだけ。(多分ニート)

  • http://anond.hatelabo.jp/20140212004731

    開発の手法がどんなに良くても、才能のない人間をアサインしてるんだから無理。 手法より人。   ビッグデーターがビックデーターの装置よりビックデーターを使う人のセンスが重要...

    • http://anond.hatelabo.jp/20140212180916

      キーマンがいなくたって成功できるようにならないと、業界は成長していけないんだ!

      • http://anond.hatelabo.jp/20140212182747

        現実を見ろ。 日々勉強して、勉強会にも参加し、テストコードも書き訓練しているトップコーダーたちと 仕事が終わったら、飲みに行って、キャバクラで遊んでいるような社員と どっ...

        • http://anond.hatelabo.jp/20140212194015

          現実を見ろ。 日々勉強して、勉強会にも参加し、テストコードも書き訓練しているトップコーダーたちと 仕事が終わったら、飲みに行って、キャバクラで遊んでいるような社員と ど...

記事への反応(ブックマークコメント)