デスマーチ(1)
デスマーチ 第2版 ソフトウエア開発プロジェクトはなぜ混乱するのか
先日本屋で見かけた際に捕獲しておいた本。
ざっと呼んだ感じではデスマーチの定義と分類、要素の分析から始まって
巻き込まれた、もしくは自ら進んで乗り込んだ際の立ち回りの指針や
プロジェクトにおける「無駄」とは何か、また何を計画すべきかという話を
経由し、どのような手法やツールが根本的な助けになるのかといった話まで
といった感じでした。
しっかりとは読んでないので、ゆっくり読み返しながら気になった点を
ピックアップしていってみたいと思います。
まず序文から
米国では、アウトソーシングの「脅威」が原因で、企業内部のIT部門で
デスマーチ・プロジェクトが生まれている。
(略)
米国のサプライヤは、海外の低賃金サプライヤよりも5倍から10倍高い給料を
もらっており、最新技術を導入しても生産性は少ししか改善できないため
(改善できても海外のサプライヤが同じ技術を使い始めるまでの期間だけ)、
低価格を実現する唯一の戦略は、IT技術者に膨大な無給の残業を強いることだ。
これは世界的アウトソーシングに対するアメリカの対応であることを断っておく。
日本や他の高コスト国でも起こるかどうかは、不明である。
日本でも無給の残業ってやつはよくみる風景ですが、それが活発な
アウトソーシングの為かどうかは不明。
少なくともアウトソーシングすれば安くなる(はず)だからもっと安くしろ
っていう話はよく言われていますね。
本当に安くなるのかどうかはさておいてですが。
人は再利用可能か?
d:id:mkusunok:20060504のエントリより。
企業が人を育てる気になるか否かは、将来的な計画を
どこまで立てているのかに依存するんじゃあないかと思う。
たとえば、この業界ではまだまだ稼ぐことができる、もしくは今後もずっと稼いで行きたいと
考えるならば、売上に対する他社への依存を下げるべくはてなやmixiのように
自前のサービス/商材を売上の基本としていく必要がある。
ただ、それには研究開発のための資金も掛かるし、サービス維持の為にシステムに
精通した社内生え抜きの人材が必要になる。
また、サービスを開始してから軌道に載るまで我慢強く資金繰りを行い、時には
見切りを付け他のサービスを考案しないといけなくなるかもしれない。
一方、下請け孫請けの人貸し商売は実に簡単です。(多分)
少なくとも今は人が足りないといわれている現場だけはたくさんあるし
進捗が捗らなくなったので人を追加した制で人が足りなくなった現場もたくさんあるようには見える。
そこにさらに人を突っ込むだけで月幾らかの金が入ってくるのですから、他に考えるべきことは
辞める人以上の人間を確保しつづけること以外には特に何もないでしょう。
ただし、そんな現場がいつまでもありつづけるとは限らない。
現場がなくなったらどうするかと聞いたら「それまでに十分に稼いで廃業する」という解答が予想できるようでしたら、その企業はd:id:mkusunok:20060504で言われて入る鉱石の採掘業者と同じでしょう。
被雇用者は、今勤めている会社がいつにフォーカスを合わせて計画を立てているかを考えてみるもの一興かと思われます。
■
http://d.hatena.ne.jp/heppokoprogram/20060503
某カードゲームの世界で感じた構成は↓の通り。
[突き抜けてプロと呼ばれるようになった人々]
>>> [自由になる多少の金と膨大な時間を持った人々(例:大学生)]
> [金は無いが時間はある人々(例:高校生)]
> [金はあるが時間がない人々(例:日曜プレイヤーなサラリーマン)]
プログラミングが趣味じゃないプログラマといういのは、プログラミングを趣味レベルでしか
考えていない(なぜか一周してしまった)リーマンってことですね。
業務屋で食っていこうと言うのならば、(開発に関わらない限り)それでもいいのかも知れませんが
プロとしてどうよ？って感じですね。
ネットワークゲームにおけるRMTの是非？
http://www.4gamer.net/specials/060426_rmt/060426_rmt_001.shtml
ネタ元は上。
RMTの業者さんと運営側の責任者との対談という形で
お互いがフォーカスしている点の確認を行ったように見える。
とりあえず、独断と偏見でそれぞれの意見を抜き出してみると
- RMT業者側
- 現実問題として、ゲーム内通貨の現金トレードへの要求は存在する
- 現在のRMT市場には詐欺、専業の生産者による迷惑な行為、外国人プレイヤーの出稼ぎと納税の関係、などといった問題が積まれている
- マネージドな市場を作る事で、RMTに付随する様々な問題の解決を目指せるとともに、プレイヤーの快適さの向上も満たすことが出来る(RMTは運営側にとっても益はあるんだよ派)
- 運営側
- 規約では禁止しているが、取引そのものはゲーム外の出来事なので取り締まることは出来ない
- ゲームが提供しているのは価値観であって価値そのものではない(ゲーム内通貨やアイテムはたとえどれだけレアであっても、それとリアルマネーで換算するだけの裏づけはない、ってことかな？)
- ゲーム内のアイテムは決して資産とはいえない。なぜならばそれは運営側の一存でどうとでも出来てしまうようなものであるから(読み間違えがあるかも)
- 人の庭で勝手に商売するな
- もし業者と協力するとしても、価値の恒常性を保障することはできない
それなりに長い内容なので、目についた当たりだけ。
業者側の意見は実に分かり安いのですが、対談のなかで出てきた「でもそれって詐欺師の理論
(確かに悪いことをしているが他のもっと悪い奴にだまされるよりはましだよ?、
ってやつ)ですよね?」って意見には現状では反論が難しそう。
まあ、新しい商売なんて既得権者から見ればよくて必要悪以上のものではないのは良くある話なのでこんなものかもしれません。
運営側の意見はどこに焦点を絞って読めばいいのは良く分からない。
メーカー・運営側として提供出来るのは価値観のみって点を強調して、それを持ってRMT反対を唱えているように読めるのですが、なぜそれがRMT反対の論拠となるのでしょうか？
運営から提供された価値観がコロコロ変わることによって、ゲーム内通貨の価値と現金の価値の間に安定したマッピングが行えないと言う問題はそのマッピングを行っているのが
運営側そのものであるときのみ問題になるものであって、ユーザなり業者なりが勝手にマッピングしている限り特に問題ではないと思うのですが。
出来たら「RMTが行われることでメーカー・運営側にはどんな不具合が発生するのか」って点を十分に語ってほしかった
■
エクセルで書かれたよくあるテーブル設計書からDBアクセスを
行うクラスとデータ格納用のクラスを生成するツールを作くりながら思ったこと。
生成されたコードは
- 完成品を生成して、手を加えないで使用する
- 作成されるのはあくまでテンプレート扱いで、必要に応じて手を入れる
のどちらが良いアプローチなのだろうか？
前者の方針は
メリット
前提としては生成されたコードにはバグは含まれていないことになっているので、開発効率はだいぶ上がる
(生成されるコード量:全体のコード量の比に依存)
定義書が更新されてももう一度ツールを使うだけでよいので後の変更にも対応が楽になる
デメリット
融通が利かない(流儀を強制される)
要求を完全に満たす生成ツールが必要
後者の方針
メリット
必要に応じて柔軟なコードが書ける
デメリット
定義書が変更になった際に、変更後の定義書から生成されたテンプレートに
対してもう一度変更を反映させなければならない
生成後の加えた変更のログを取っておくなりなんなりして
変更をマージできるような仕組みが作れればいいのですが…
(CVSとかでリポジトリとローカルのファイルをがんばってマージするって
意見は却下です。)
