パスワードを忘れた? アカウント作成
325563 story
プログラミング

プログラマーの情熱を奪わない開発プロセスとは? 137

ストーリー by headless
思いつかない 部門より

あるAnonymous Coward 曰く、

本家/.「Is Process Killing the Software Industry?」より

テスト駆動開発はベストプラクティスであるということは皆の知るところだろう。コードを100%レビューする。単体テストでのコードカバー率を70%にする。循環的複雑度を20以下に抑える。開発を始める前に顧客の要望を調整しておくなど。大量の「ベストプラクティス」は、それぞれ素晴らしいアイディアのように見える。しかし、ベストプラクティスをこなすことに追われる開発者には、革新的・創造的な作業をするための時間がどれぐらい残されるだろうか。
O'Reilly Radarの記事では、良いコードを確保するために取り入れるプロセスが多すぎると、開発者の情熱を奪ってしまうと主張している。 「素晴らしいコードを書くことのできるプログラマーから、プロセスが情熱を奪う。不満を抱くプログラマーが質の悪いコードを書き、良いコードを確保するために管理部門がプロセスを追加する、という悪循環に陥り、さらに士気が低下する」ということだ。

では、プログラマーの情熱を奪わない開発プロセスとはどういうものだろうか。

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • モチベーションとか情熱とかそういうものは、同じ奴を相手に、同じようなことを、繰り返しやっていて、その度に同じような評価しか受けられないなら、誰であっても徐々に失われていくものだ。
    別の言い方をすると、人間は「なにか違う」からこそ情熱を維持できる。

    ただし、情熱は「余裕」の産物でもある。なので、あまりにも違いすぎる仕事に対しては、人は情熱を燃やせない。あまりにも違う仕事は余裕をすべて食い尽くすし、さらに言えば「余裕」っていうのは、本当に余力があるかどうかではなくて、
    「余力があると認識出来るかどうか」
    にかかっているから。

    だから目標設定というのが大事になる。前と同じ仕事をやるなら、「もっと早く」とか「もっと楽に」とか「もっと高品質に」とか。違う仕事をする場合は「あまり違いすぎない」とか。そういう調整が必要になる。

    残念ながら「開発プロセス」などのアルゴリズム中に、このような調整を自動的にやってくれるものは見当たらない。

    --
    fjの教祖様
  • プロセス云々より (スコア:3, すばらしい洞察)

    by Zenkaichi (27811) on 2011年05月14日 12時14分 (#1952080) 日記

    納期が最初に決まってる開発をどうにかして下さい

    --
    Sir! yes, sir!
    • by ksh2ksk4 (11188) on 2011年05月14日 22時30分 (#1952406)
      納期最優先は構わないが,往々にしてコスト/クオリティとのトレードオフが発生することを認識してほしい.
      納期は先に延ばせない,予算がないので人員は投入できない,開発する機能は減らせない/段階的リリースもできない・・・

      詰んでるよ.
      親コメント
  • by Anonymous Coward on 2011年05月14日 12時00分 (#1952075)
    プロセスじゃなくて手法かもしれませんが、ペアプログラミング。
    注目しているんですが、なかなかパッとしませんね。
     (厳密にはペアプログラミングとは違うかもしれませんが、
      同レベルの担当者が複数いる状態)

    若いころは「人より知ってる」こと「オレがいないと回らない状態」
    を求めて孤高な方向へ向ってましたが、
    最近は「いかに手離れがいいか」の方が重要だと思うようになりました。

    常に複数人がかかわっていれば、思いつかないような発想が得られたり、
    なんかあっても割と当てになる人間が回りにいることになり、
    いつでも逃げられるし、精神的に非常に楽で、楽しく、
    心が折れることも少ないかと思うんですけどね。
    • by Anonymous Coward on 2011年05月14日 15時53分 (#1952203)

      客先常駐でまともな開発者は自分一人・・・他は中国人ばかりって感じの仕事をしてましたが、これが無いと本当にきついですね。

      何でも自分のところに相談が来てしまうし、かといって見てやらないと炎上する。
      自分ひとりではどうしたらよいのかと悩んでいても、誰も頼りにできない。
      これがとてもベストプラクティスとは思えなくても、自分が思い浮かんだ案で進めるしかない。
      迂闊に風邪を引いて休むことも出来ない。
      チーム全体のスキルを上げようにも、そもそも上の課題だけで手一杯になってしまう。

      えぇ、最終的に心が折れて逃げましたが(--
      この記事で話題にしてるような話以前の内容だとは思いますが、そもそもリソースに余裕が無いと情熱なんて持ちようがないです。

      親コメント
    • Re:ペアプログラミング (スコア:2, おもしろおかしい)

      by quililila (23086) on 2011年05月15日 10時10分 (#1952531) 日記

      > プロセスじゃなくて手法かもしれませんが、ペアプログラミング。
      > 注目しているんですが、なかなかパッとしませんね。

      まぁ理由は簡単で、コストが2倍になるからなんですよね。
      一方、効果の方もそれなりにでかいんですが、定量的にはかれないものなので管理者を説得するのが難しい。
      一応の理解は示してもらえるけど、実行に移すには嘘でもいいから数字が必要であり、
      では嘘でもいいから売り上げ2倍とか期間半減とか数字を出せるかというと、それもちょっと無理。

      経営陣の上の方までソフト屋でペアプログラミング推奨とか、とりあえず実験的に小規模でという以外は
      採用できない手法だと思われます。

      親コメント
  • 相手が可愛らしい女性だと少し良いカッコしようと頑張ってしまいそうです。

    • Re:ペアプログラミングで (スコア:2, おもしろおかしい)

      by Sukoya (33993) on 2011年05月14日 12時23分 (#1952088) 日記

      手を出せない異性と一対一なんて二次元よりたちが悪いでありますよ?
      その罠で何人が会社を辞めたと思っているんでありますか

      #そして手を出せる相手(例:アラサー)に手を出して人生オワタも稀によくある!

      親コメント
    • 相手が天海祐希さんみたいなドSなお姉さまならいかがでしょう?
      親コメント
    • Re:ペアプログラミングで (スコア:1, おもしろおかしい)

      by Anonymous Coward on 2011年05月14日 20時01分 (#1952335)

      まともにペアプロ運用しているなら、同程度のスキルの人と組むのが普通ですので、

      > 少し良いカッコしようと頑張ってしまいそうです。

      無理しても見透かされて恥ずかしい思いをするかと思いますが。

      相手に「すごいですねー、先輩」なんて感心してもらえるような状況だと
      ペアプロとしては破綻、本来の目的を達成できていないと思われ。

      え?「本来の目的」はそこじゃないって?

      親コメント
  • by Anonymous Coward on 2011年05月14日 12時29分 (#1952092)

    せめてテキストエディタで書けるフォーマットにしていただきたい。
    プレインテキストとは言わないが、TeXなりHTMLなりテキストエディタで扱えるもので。

    Officeでドキュメント作ると、本題以外の部分で時間かかるんだよねぇ……
    フォントなどの見た目に文句つけられたり、書いている最中に強制終了されたり。
    あと図だけじゃなくてちゃんと文章も読め!

    • by Anonymous Coward on 2011年05月14日 12時38分 (#1952098)
      プログラムだけやってれば良いならモチベーション下がらない
      報告書やドキュメント、打合せのための資料作りとか雑務が増えるたびどんどんやる気が失せていく
      親コメント
      • by Anonymous Coward on 2011年05月14日 17時06分 (#1952250)
        報告書やドキュメント、打合せのための資料作りが雑務だと思っている間は改善はないでしょうね。
        親コメント
    • by Anonymous Coward on 2011年05月14日 14時16分 (#1952146)

      自分の場合、

      emacsでプレインテキストで書き下ろして、wordに流し込んで体裁だけ整える。
      図なんかは文章が出来上がった後でVisio使って描いてword上に貼り付ける。

      って感じでやってます。改行打ったタイミングとかにwordが余計な事をする
      こともないしはかどりますよ。

      親コメント
  • by hetareDAIO (17407) on 2011年05月14日 14時27分 (#1952155) 日記

    実際にやろうと思ったら規模の大きいところほど困難を伴うと思われますが、開発プロセスは個々の能力に合わせて能力別に適用基準を変えられる様にすべきかと考えます。

    結局、能力差が多分にある環境において、一番よくあるパターンは、一番低いレベルに基準が合わさってしまうことです。そうすると、能力の高い人にとっては無駄な労力を割くことにしかなりませんから不満が出てきて当然でしょう。見る機会はあまりありませんが、逆のパターンもしかりです。皆が同じ基準で仕事をする時点で、出来る人出来ない人どちらにも不満は出てきます。同じ基準こそが問題だと思います。

    その能力をどういう基準でもって判断するのか、等、色々難点はありますが、個人的には試行錯誤して取り組んでいきたいテーマではあります。

    --
    ほえほえ
  • 追加仕様 (スコア:1, すばらしい洞察)

    by Anonymous Coward on 2011年05月14日 11時25分 (#1952068)

    営業やプロジェクトマネージャがイエスマンで仕様確定後の糞クライアントの追加要求を追加して
    せっかく作り終わったシステムを作り直す羽目になるのは避けて欲しいね。(モチベーションが下がる。)

  • by Sukoya (33993) on 2011年05月14日 12時14分 (#1952082) 日記

    バグ修正と納品前の仕様変更に伴う修正を無くせば、志気なんて鰻でもメダカでも鯨でも上がるんだろう

    ……無理じゃね?

  • by Anonymous Coward on 2011年05月14日 13時20分 (#1952120)

    プログラマーに限らず、労働者の情熱を奪わない職場なんて、どれだけあるのか。
    ほんの一握りの幸せな人を除いて、職業なんて、情熱をすりへらすものだと思う。
    客あっての職業なんだから、不条理な客にふりまわされたり、同業他社との競争に
    生き抜いていくためにはどこか無理しないといけないだろうし、国際競争に
    さらされれば高コストな日本人はコストに見合うだけの働きを見せないといけない
    だろうし。

  • 仕事でやらない (スコア:1, すばらしい洞察)

    by Anonymous Coward on 2011年05月14日 14時55分 (#1952171)

    仕事でやらなければいいのではないかと。
    趣味のコーディングに開発手法を持ち込んで脳汁が出る範囲を調整して、仕事でもこれならなんとか脳汁垂れるかもしれん…というレベルにミニマイズして還流。

    ぶっちゃけ営業でも開発でもQAでも自分のやりたいような仕事なんかできる訳ないんだし、360度集中砲火を受けたり顧客の前で公開レイプされてレイプ目になっても微笑み返しを残せる位の隠し玉を持っておけないと、仕事のやりがいが家の電気代節約のため位しかなくなってしまう。

  • プロジェクトの運営は、大きな規模・人数によるウォーターフォールを前提としているように思える。
    でも、意識の対象が「プログラマー」になっているのは、ウォーターフォールが適用される例が少ない「全部自分でやってます」的な、小プロジェクトもしくはフリープログラマーの意識ではないだろうか?

    「そういうプログラマーを集めてプロジェクトを進めるとき」の話であれば納得。(OSSっぽい)
    でも、大規模なOSSの開発で、ソースレビューとか出来るものなのでしょうか?
    自分のイメージでは、人があちこちにいて、関数なりモジュールなりを作ったり書き換えたりしながら、リポジトリに登録して、採用不採用を判断される・・・・みたいなイメージしかないのですが。
    人が分散していて、コードレビューって出来るもの?

    ※私の偏見?

    • by Anonymous Coward on 2011年05月14日 17時18分 (#1952255)

      > 人が分散していて、コードレビューって出来るもの?

      西欧、北米東西海岸、日本に分散したチームで仕事のプロジェクト回してます。
      ソースコードレビューはGerrit http://code.google.com/p/gerrit/ [google.com] 使ってます。
      内製のイシュートラッカと連動させて、普段の仕事のフローの一部にレビューが組み込まれてます。

      ただ、確かに非同期なテキストでのやりとりだけでは効率が悪いこともあり、
      ちょっと込み入った話になるとすぐ音声チャットと併用になります。
      パートタイムでしか関われない人が多いOSSだと、リアルタイムコミュニケーションの
      セットアップが難しいかもしれません (時差の関係で、可能がウィンドウが狭いので)。

      まあひとつのデータサンプルとして。

      あーでも規模はあんまり大きくないなあ。レビューなどで密接に関わりがあるチームは20人いかない。
      あとは独立性の高い機能を実装するのに臨時で人が加わることがあるけど。
      100人のチームになったら違う体制が必要だと思います。

      親コメント
    • でも、大規模なOSSの開発で、ソースレビューとか出来るものなのでしょうか?

      誰かがパッチを投げたら、皆でああだこうだ文句をつけあう(または無視してとりあわない)のって、コードレビューなんじゃないですかね?

      もちろんコミッタは、そういうの抜きで自分のコードをレポジトリにコミット出来るけど、
      いつも他人に文句を言う係なので、自分のコードもきっちり作るし、
      そもそもそういう人間と認められないとコミッタにはなれない。認められなければお前ヤメろと言われるか、フォークするだけ。
      そういう風にOSSのプロジェクトは回ってるんだと思います。

      親コメント
  • っていうか,開発やらせてください.
    顧客調整とか社内調整とかもうたくさん.
typodupeerror

普通のやつらの下を行け -- バッドノウハウ専門家

読み込み中...