プログラマーの情熱を奪わない開発プロセスとは？ 137
ストーリー by headless
思いつかない 部門より
思いつかない 部門より
あるAnonymous Coward 曰く、
本家/.「Is Process Killing the Software Industry?」より
テスト駆動開発はベストプラクティスであるということは皆の知るところだろう。コードを100%レビューする。単体テストでのコードカバー率を70%にする。循環的複雑度を20以下に抑える。開発を始める前に顧客の要望を調整しておくなど。大量の「ベストプラクティス」は、それぞれ素晴らしいアイディアのように見える。しかし、ベストプラクティスをこなすことに追われる開発者には、革新的・創造的な作業をするための時間がどれぐらい残されるだろうか。
O'Reilly Radarの記事では、良いコードを確保するために取り入れるプロセスが多すぎると、開発者の情熱を奪ってしまうと主張している。 「素晴らしいコードを書くことのできるプログラマーから、プロセスが情熱を奪う。不満を抱くプログラマーが質の悪いコードを書き、良いコードを確保するために管理部門がプロセスを追加する、という悪循環に陥り、さらに士気が低下する」ということだ。では、プログラマーの情熱を奪わない開発プロセスとはどういうものだろうか。
そのような「開発プロセス」などない (スコア:4, 興味深い)
モチベーションとか情熱とかそういうものは、同じ奴を相手に、同じようなことを、繰り返しやっていて、その度に同じような評価しか受けられないなら、誰であっても徐々に失われていくものだ。
別の言い方をすると、人間は「なにか違う」からこそ情熱を維持できる。
ただし、情熱は「余裕」の産物でもある。なので、あまりにも違いすぎる仕事に対しては、人は情熱を燃やせない。あまりにも違う仕事は余裕をすべて食い尽くすし、さらに言えば「余裕」っていうのは、本当に余力があるかどうかではなくて、
「余力があると認識出来るかどうか」
にかかっているから。
だから目標設定というのが大事になる。前と同じ仕事をやるなら、「もっと早く」とか「もっと楽に」とか「もっと高品質に」とか。違う仕事をする場合は「あまり違いすぎない」とか。そういう調整が必要になる。
残念ながら「開発プロセス」などのアルゴリズム中に、このような調整を自動的にやってくれるものは見当たらない。
fjの教祖様
プロセス云々より (スコア:3, すばらしい洞察)
納期が最初に決まってる開発をどうにかして下さい
Sir! yes, sir!
Re:プロセス云々より (スコア:1)
納期は先に延ばせない，予算がないので人員は投入できない，開発する機能は減らせない/段階的リリースもできない・・・
詰んでるよ．
Re:プロセス云々より (スコア:2, すばらしい洞察)
Re:プロセス云々より (スコア:2)
ほんとは、仕事の内容が決まっていないのに見積もりや発注/受注が可能なのは商習慣としておかしいよね。それがまかり通るということは、プログラマにしてみればそんな仕事でも断れない（でないと仕事がなくなり、食べていけない）ということ。
発注する側にしてみればそれでも受けてくれるところがある。要するに、プログラマ（開発側）が余っているのでは。
人生は七転び八起き、一日は早寝早起き
Re:プロセス云々より (スコア:1, すばらしい洞察)
顧客との要求仕様の折衝は工数に数えられず
そして社内承認が降りぬまま開発がスタートする
ホントこの業界は地獄だぜ
Re:プロセス云々より (スコア:1)
受注が決まっていいるだけマシと思うべし。
それに加えて受注が決まらず、でも双方の事情によりやることだけは決まっている。
受注が決まっていないため、社内ルールにより予算化されずにまともに人員を投入できず。
ところが競合の関係で非公式にはおおむねの納期は決まっているため、
スタートも切れないのに開発期間だけがどんどん減っていく。
# そんなプロジェクトもまもなく運用開始できそうです。
# 母さん、がんばったよ、僕。
ペアプログラミング (スコア:2, 参考になる)
注目しているんですが、なかなかパッとしませんね。
（厳密にはペアプログラミングとは違うかもしれませんが、
同レベルの担当者が複数いる状態）
若いころは「人より知ってる」こと「オレがいないと回らない状態」
を求めて孤高な方向へ向ってましたが、
最近は「いかに手離れがいいか」の方が重要だと思うようになりました。
常に複数人がかかわっていれば、思いつかないような発想が得られたり、
なんかあっても割と当てになる人間が回りにいることになり、
いつでも逃げられるし、精神的に非常に楽で、楽しく、
心が折れることも少ないかと思うんですけどね。
＞同レベルの担当者が複数いる状態 (スコア:2, 興味深い)
客先常駐でまともな開発者は自分一人・・・他は中国人ばかりって感じの仕事をしてましたが、これが無いと本当にきついですね。
何でも自分のところに相談が来てしまうし、かといって見てやらないと炎上する。
自分ひとりではどうしたらよいのかと悩んでいても、誰も頼りにできない。
これがとてもベストプラクティスとは思えなくても、自分が思い浮かんだ案で進めるしかない。
迂闊に風邪を引いて休むことも出来ない。
チーム全体のスキルを上げようにも、そもそも上の課題だけで手一杯になってしまう。
えぇ、最終的に心が折れて逃げましたが(--
この記事で話題にしてるような話以前の内容だとは思いますが、そもそもリソースに余裕が無いと情熱なんて持ちようがないです。
Re:ペアプログラミング (スコア:2, おもしろおかしい)
> プロセスじゃなくて手法かもしれませんが、ペアプログラミング。
> 注目しているんですが、なかなかパッとしませんね。
まぁ理由は簡単で、コストが2倍になるからなんですよね。
一方、効果の方もそれなりにでかいんですが、定量的にはかれないものなので管理者を説得するのが難しい。
一応の理解は示してもらえるけど、実行に移すには嘘でもいいから数字が必要であり、
では嘘でもいいから売り上げ2倍とか期間半減とか数字を出せるかというと、それもちょっと無理。
経営陣の上の方までソフト屋でペアプログラミング推奨とか、とりあえず実験的に小規模でという以外は
採用できない手法だと思われます。
ペアプログラミングで (スコア:2)
相手が可愛らしい女性だと少し良いカッコしようと頑張ってしまいそうです。
Re:ペアプログラミングで (スコア:2, おもしろおかしい)
手を出せない異性と一対一なんて二次元よりたちが悪いでありますよ？
その罠で何人が会社を辞めたと思っているんでありますか
#そして手を出せる相手(例:アラサー）に手を出して人生オワタも稀によくある！
Re:ペアプログラミングで (スコア:1)
Re:ペアプログラミングで (スコア:1, おもしろおかしい)
まともにペアプロ運用しているなら、同程度のスキルの人と組むのが普通ですので、
> 少し良いカッコしようと頑張ってしまいそうです。
無理しても見透かされて恥ずかしい思いをするかと思いますが。
相手に「すごいですねー、先輩」なんて感心してもらえるような状況だと
ペアプロとしては破綻、本来の目的を達成できていないと思われ。
え？「本来の目的」はそこじゃないって？
ドキュメントめんどくさい (スコア:2, すばらしい洞察)
せめてテキストエディタで書けるフォーマットにしていただきたい。
プレインテキストとは言わないが、TeXなりHTMLなりテキストエディタで扱えるもので。
Officeでドキュメント作ると、本題以外の部分で時間かかるんだよねぇ……
フォントなどの見た目に文句つけられたり、書いている最中に強制終了されたり。
あと図だけじゃなくてちゃんと文章も読め！
Re:ドキュメントめんどくさい (スコア:1, 参考になる)
報告書やドキュメント、打合せのための資料作りとか雑務が増えるたびどんどんやる気が失せていく
Re:ドキュメントめんどくさい (スコア:1, すばらしい洞察)
Re:ドキュメントめんどくさい (スコア:2, すばらしい洞察)
Wordでも改ページの存在すら知らないで改行でページを埋めてる人とか、ページ番号や項番、目次を手打ちするとかいますね。
文章が多い書類にExcelを使っちゃうなんて人は根性あるなと思います。
Excelの貧弱なシート管理機能で延々ページ管理するなどマゾ過ぎる。
結局、WordやExcelはコンピュータ門外漢向けの本ばかりで、きちんとしたツールとして概念から説明している本が少ないのがいけないのかも。
プログラマ自身もその思考をドキュメント程度の分野に応用できない不甲斐なさに気づくべきなんですけど、どうもそうはなりませんね。思考がプログラマではなく、プログラミングツールを使うツールユーザから脱せていない。
Re:ドキュメントめんどくさい (スコア:1, 興味深い)
自分の場合、
emacsでプレインテキストで書き下ろして、wordに流し込んで体裁だけ整える。
図なんかは文章が出来上がった後でVisio使って描いてword上に貼り付ける。
って感じでやってます。改行打ったタイミングとかにwordが余計な事をする
こともないしはかどりますよ。
Re:ドキュメントめんどくさい (スコア:1)
そんなアホな作業を擦る必要のない、LaTeXが一番良い。
は?言う事を聞かない??
Wordが言うことを聞く、と言う程度のレイアウトしかしていないなら、LaTeXでも問題ない。
fjの教祖様
Re:ドキュメントめんどくさい (スコア:2)
使いこなせるようになったつもりだが、2007 になった瞬間からワケワカメ。学ぶ気も失せた。
Tak.Miyoshi
Re:ドキュメントめんどくさい (スコア:1)
本来の業務以外に便利屋業務がふりかかってきてしまいます。
そんなんヘルプ見るかぐぐるかすればすぐ分かるんだからいちいち聞くなっちゅーの。
それが同じ部署の女の子からとかだったらまだしも、社内中のゆとり脳社員からひっきりなしにとなると
もうね。
Re:Excel一択 (Re:ドキュメントめんどくさい) (スコア:1)
Wordは見えてるモノ掴んで引き摺っても全然指定したトコに動かなくて全然WYSIWIGじゃないから論外
WYSIWIG? WYSIWYGだよね？
結局ドキュメント作るのに必要な機能をまともに提供できるソフトってExcel以外にはないという結論。
おや？Excelは全然WYSIWYGじゃないよ。
プロポーショナルフォントをマトモに扱えないのは、文書作成ソフトとしては、論外じゃないかね。
Re:ドキュメントめんどくさい (スコア:2, 参考になる)
技術文書のように、提携のフォーマットがあって文章量が多いものは、
FrameMaker おすすめです。
イラレで500ページとか、気が遠くなります（InDesignならあり）
個々に合わせる (スコア:2)
実際にやろうと思ったら規模の大きいところほど困難を伴うと思われますが、開発プロセスは個々の能力に合わせて能力別に適用基準を変えられる様にすべきかと考えます。
結局、能力差が多分にある環境において、一番よくあるパターンは、一番低いレベルに基準が合わさってしまうことです。そうすると、能力の高い人にとっては無駄な労力を割くことにしかなりませんから不満が出てきて当然でしょう。見る機会はあまりありませんが、逆のパターンもしかりです。皆が同じ基準で仕事をする時点で、出来る人出来ない人どちらにも不満は出てきます。同じ基準こそが問題だと思います。
その能力をどういう基準でもって判断するのか、等、色々難点はありますが、個人的には試行錯誤して取り組んでいきたいテーマではあります。
ほえほえ
追加仕様 (スコア:1, すばらしい洞察)
営業やプロジェクトマネージャがイエスマンで仕様確定後の糞クライアントの追加要求を追加して
せっかく作り終わったシステムを作り直す羽目になるのは避けて欲しいね。(モチベーションが下がる。)
Re:追加仕様 (スコア:1)
>社内で作ってしまえっていう話。
それを社内SEとか言っている場合が多いですね。
しかしだな (スコア:1)
バグ修正と納品前の仕様変更に伴う修正を無くせば、志気なんて鰻でもメダカでも鯨でも上がるんだろう
……無理じゃね？
情熱を奪わない職場なんてあるのか (スコア:1, 参考になる)
プログラマーに限らず、労働者の情熱を奪わない職場なんて、どれだけあるのか。
ほんの一握りの幸せな人を除いて、職業なんて、情熱をすりへらすものだと思う。
客あっての職業なんだから、不条理な客にふりまわされたり、同業他社との競争に
生き抜いていくためにはどこか無理しないといけないだろうし、国際競争に
さらされれば高コストな日本人はコストに見合うだけの働きを見せないといけない
だろうし。
仕事でやらない (スコア:1, すばらしい洞察)
仕事でやらなければいいのではないかと。
趣味のコーディングに開発手法を持ち込んで脳汁が出る範囲を調整して、仕事でもこれならなんとか脳汁垂れるかもしれん…というレベルにミニマイズして還流。
ぶっちゃけ営業でも開発でもQAでも自分のやりたいような仕事なんかできる訳ないんだし、360度集中砲火を受けたり顧客の前で公開レイプされてレイプ目になっても微笑み返しを残せる位の隠し玉を持っておけないと、仕事のやりがいが家の電気代節約のため位しかなくなってしまう。
なんか、チョット軸線があっていない気が・・・ (スコア:1)
プロジェクトの運営は、大きな規模・人数によるウォーターフォールを前提としているように思える。
でも、意識の対象が「プログラマー」になっているのは、ウォーターフォールが適用される例が少ない「全部自分でやってます」的な、小プロジェクトもしくはフリープログラマーの意識ではないだろうか？
「そういうプログラマーを集めてプロジェクトを進めるとき」の話であれば納得。（OSSっぽい）
でも、大規模なOSSの開発で、ソースレビューとか出来るものなのでしょうか？
自分のイメージでは、人があちこちにいて、関数なりモジュールなりを作ったり書き換えたりしながら、リポジトリに登録して、採用不採用を判断される・・・・みたいなイメージしかないのですが。
人が分散していて、コードレビューって出来るもの？
※私の偏見？
Re:なんか、チョット軸線があっていない気が・・・ (スコア:2, 興味深い)
> 人が分散していて、コードレビューって出来るもの？
西欧、北米東西海岸、日本に分散したチームで仕事のプロジェクト回してます。
ソースコードレビューはGerrit http://code.google.com/p/gerrit/ [google.com] 使ってます。
内製のイシュートラッカと連動させて、普段の仕事のフローの一部にレビューが組み込まれてます。
ただ、確かに非同期なテキストでのやりとりだけでは効率が悪いこともあり、
ちょっと込み入った話になるとすぐ音声チャットと併用になります。
パートタイムでしか関われない人が多いOSSだと、リアルタイムコミュニケーションの
セットアップが難しいかもしれません (時差の関係で、可能がウィンドウが狭いので)。
まあひとつのデータサンプルとして。
あーでも規模はあんまり大きくないなあ。レビューなどで密接に関わりがあるチームは20人いかない。
あとは独立性の高い機能を実装するのに臨時で人が加わることがあるけど。
100人のチームになったら違う体制が必要だと思います。
Re:なんか、チョット軸線があっていない気が・・・ (スコア:1)
でも、大規模なOSSの開発で、ソースレビューとか出来るものなのでしょうか？
誰かがパッチを投げたら、皆でああだこうだ文句をつけあう(または無視してとりあわない)のって、コードレビューなんじゃないですかね?
もちろんコミッタは、そういうの抜きで自分のコードをレポジトリにコミット出来るけど、
いつも他人に文句を言う係なので、自分のコードもきっちり作るし、
そもそもそういう人間と認められないとコミッタにはなれない。認められなければお前ヤメろと言われるか、フォークするだけ。
そういう風にOSSのプロジェクトは回ってるんだと思います。
奪われるほど情熱はない (スコア:1)
顧客調整とか社内調整とかもうたくさん．
Re:ぼくのかんがえる べすとぷらくてぃす (スコア:1)
担当プロジェクト終わったら、自分で次の仕事をとってくる。
できるのか？ってのは措くとして。
終わってから取りに行ってもダメだろ。終わる前から次のプロジェクトの受注に向けて活動を始めて、終わったときには受注完了、次のスタートが切れるようにしとかないと。
Re:ぼくのかんがえる べすとぷらくてぃす (スコア:1)
休みたいなら、休めばいいんだよ。自分で受注活動するなら、自分で実行時期を調整すればいいでしょ。
プロジェクトが終わってから自分で受注活動を始めたら、それこそ休む間が無いでしょうに。
Re:ぼくのかんがえる べすとぷらくてぃす (スコア:1)
>営業担当レス化とか。
逆の意味だけど、そう思う。
営業ってシステムかじっただけで上がっちゃったのが多いんで、
そういう営業はいらないよね。
>担当プロジェクト終わったら、自分で次の仕事をとってくる。
まさに、そんな感じの営業が多いんだよね。
でもって、適当に人に仕事なげて、営業しているとか言いおるわけな。
>これなら、実現可能な要求仕様になりやすい・・・はず・・・
実際、現在のIT関係の営業って、その通りで要求(誰の？)に見合った仕様らしく
それはそれで回っている(様に見える)らしいよ。
>営業担当の玉虫色トークに何度煮え湯を飲まされたことやら
営業と話をするのに、玉虫色だろうが黄金色でろうが、満足しちゃって
熱いのを見ないで飲むとそうなりますし、それが一般では結構あるらし
くて、それなりに繰り返されているのは、ベストかどうかはとにかく、
一般的なプラクティスらしいです。
つまり、あなたはあなたにあったプラクティスを選択しているのだと、
この投稿から、わたしは読み取りました。
Re:ぼくのかんがえる べすとぷらくてぃす (スコア:2, すばらしい洞察)
まあ、なんて言うか、「営業」って名前がよくないと思うんだよね。
「営業」って、英語ではsalesでしょ？販売と呼ぶべきだよ。
営業って言うのは本来、企業活動全体のことを指す言葉だよね。
販売スタッフをそんな言葉で呼ぶから、勘違いするヤツが増える。
Re:ぼくのかんがえる べすとぷらくてぃす (スコア:1)
新聞社とかだと、「営業」と「販売」は別の部署ですね。
新聞を売る（ための販売店政策など）をするのが「販売」、
広告を取ってくるのが「営業」みたいです。
Re:ぼくのかんがえる べすとぷらくてぃす (スコア:1)
よくある技術部門 vs 営業部門の対立の話にしたいんでしょうけど
見当違いです。販売が重要ではない、なんて話は全然していません。
製造、設計部門なんて事業運営においてはすべてODMかOEMでも成り立つわけで、間接部門みたいなもんです。
本気でそう思うのであれば、商社に業態転換するべきですね。なんでやらないんでしょう？
バリバリの商社と互角に戦えるのか、疑問が残るからでは？
できないことを、できるかのように言うのは、端的に言って嘘つきですよ。
セールス＝営業としても、勘違いでも何でもないと思いますよ
勘違いです。ただし商社の類を除く。
Re:ぼくのかんがえる べすとぷらくてぃす (スコア:1, すばらしい洞察)
間違いなく俺様営業だなw
カネ動かしてるだけで俺のカネだと思っちゃってる勘違い君。
あと、コードが醜いと後々君が頭を下げるハメになる確率が高くなるってことは覚えておいた方がいい。
Re:ぼくのかんがえる べすとぷらくてぃす (スコア:1)
ほとんどすべての会社がそうです。利益=売上*「定数」で計算されている。定数の部分が商品などによって微調整されるだけ。その内の固定割合が歩合になるので、実質「歩合=売上*定数」ですね。
実際には納品後にも調整が続いたりするので、実は利益で計算すると「売上が立ってから3年後に利益が確定」なんてのは、ザラにあります。それから歩合を貰えるようになるのだ、と考えて見れば、あなたが実は利益で評価されていないことがよく判るはずです。
fjの教祖様
Re:ぼくのかんがえる べすとぷらくてぃす (スコア:1)
Re:ぼくのかんがえる べすとぷらくてぃす (スコア:1)
営業活動全体が廉価にできる優秀な営業様はいませんが、飛び込み営業を機械にやらせるシステムならあります。
spam メールって言って…
fjの教祖様
Re:ぼくのかんがえる べすとぷらくてぃす (スコア:1, すばらしい洞察)
あと俺が就職した時はブラックという認識は一般的では無かったな
話が脱線するが、おまえさんみたいに「金と地位」だけで職業を決める人間ばかりになったから世の中がおかしくなったんだよ
例えば昔は学校の先生とか医者とか警察官とかはそれなりに信用される人（肩書き）だったが今ではごらんの通り
Re:ひと言 (スコア:2, すばらしい洞察)
Re:分業 (スコア:1)
仕様レビューが必要なんじゃね？
Re:分業 (スコア:1)
>分業の仕方を見直すだけでもかなり違うのでは？
分業の仕方を見直し続けるというプロセスが追加されることでしょう。
>非効率なレビューのやり方は、止めてほしい。
レビューの効率を計測するプロセスが追加されることでしょう。
>どうして、コードレビューの時に仕様変更が発生するの？
コードレビューにおいての仕様変更発生有無と原因究明のプロセスが追加されることでしょう。
>ある程度の規模のプロジェクトなら、
適切なサイジングかを定期的に見直すプロセスが追加されることでしょう。
...やはり、プロセスって大事ですね...www
Re:まず疑うべきところ (スコア:2, 興味深い)
あえて／いやいやでもサブプライムに回る側になり得る人が居る程度ならいいけど、ベストプラクティスを
突き詰めていくと、サブプライム側が、「人類には不可能なmission impossibleな作業」になってしまって、
実現不可能になるのがおち。
上澄みとサブプライムとトータルで考えて、やっていける開発プロセスならいいかも。
テスト駆動は、仕様の確定をサブプライムにしてうやむやにしようとしている企て以外の何者でも無い！
Re:まず疑うべきところ (スコア:1)
＞内容にもよるがテストを書くのが一番つらい。
たしかに例外的にテストが不向きな分野というのはある。
もしそのような例外的分野で無いとしたら、
「テストを書くのがつらい」
と言ってる人間のスキルをまず疑うべし。
＃テストを書けない理由が、モジュール化できてなかったり、
＃入出力もろくに定義できてなかったりということがあるのよ。
＃他人の書いたレガシーコードが原因の時は。。。orz