2005-01-29 09:55:40

プログラマは社長とのホットラインを確立しておこう

テーマ:ソフトウェア開発
プログラマは、ソフトウェア開発における最終的な責任をなぜか任されることが多い。実際には何も言われないし、本来責任を取る権限はないはずなのだが、プログラムにバグがあると昼夜問わず連絡が来て怒られる。世の中はとかく理不尽である。

そんな弱い立場に追い込まれるプログラマは、会社から見ると飯の種である。プログラムがソフトウェアを作らない限り会社に利益が出ないのだから、経営陣から見るとちゃんとソフトウェアを作るプログラマは確保しておきたい人材なのだ。

ただ、確保しておきたいという話と、内容を理解しているかという話は全然別で、社長ができることは社内の雰囲気とプログラマの顔色を見て判断しているだけ、もしくは部長とかに確認するのだが、部長もわかってなかったりすると、「大丈夫です」としかいえない。

要するに危機的状況が判断できるのは、何を隠そう、プログラムを作っているチームの中だけ、もしくはプログラマだけ、ということは普通にありえる話だ。

そんな状況下においては、下から危険を伝えていけないといけないわけだが、組織的に下からの声は一番上にはなかなか届きにくい。途中で上司が掴みっぱなしにするからだ。

上司が社長や取締役に説明しようとしても、質問に対して答えられないのでうやむやにしようとすることも考えられる。そもそもちゃんと質問に答えられる上司なら、危機的状況かどうかもわかっているので、危機的状況になっても手を打たない時点で、上司に何かを伝えても仕方が無いことを理解しよう。

さて、どうすればいいのだろうか。このままではプロジェクトは破綻しそうで、デスマーチは嫌だ。上司は人も金もないけどなんとかしてくれと言っている。そんな時に、社長に直談判できるホットラインがあれば、とりあえず現場がどういう状況かは伝えられる。

といっても、社長が人を増やしてくれたり納期を延ばしてくれるわけではない。社長が出来るのは社内の人を動かしたり、顧客とのトップ交渉したりということだ。一旦問題を一番上にあげることで、問題をチーム内から社内の問題にスケールアップさせることが大事なのだ。

このホットラインは、使い方を誤るとただの「狼少年回線」になる可能性もあるので注意する必要がある。伝家の宝刀としていつでも使えるようにして、使わないのが理想的な姿なわけで。




AD
いいね!した人  |  コメント(0)  |  リブログ(0)
2005-01-27 15:34:36

デスマーチを減らそうとすると仕事そのものが減る矛盾

テーマ:ソフトウェア開発
デスマーチプロジェクトは、突発的に発生する場合もあるし、最初からデスマーチになる確率がかなり高そうだと思われる場合もある。

前者はまだ言い訳できる余地がある(誰かが突然病気になったとか)が、後者は引き受ける時点で無理を承知で受けているケースが多いため、前提条件が何も変わってないのであれば、引き受けた側でどうにかする以外にない。

今回は後者のケースについてとりあげる。なぜ無理っぽい案件を引き受ける会社があるのかというと、大きく分けて
 1.顧客と関係強化
 2.スタッフに空きがあるため仕事を入れたい
 3.無理だと思っていない
の3つぐらいに分類できそうだ。

1は、他の案件を受けている手前受けざるを得ないとか、新しく取引がしたいから少しきついかもしれないけど引き受けるという場合である。

2は、開発案件が終了して、スタッフが空いたという状態で、何か仕事がないですかという時に、少々赤字でもいいからスタッフを遊ばせておくよりはましといって引き受ける場合である。

3は、優秀なスタッフがいるからあいつに任せれば安心だろうとか、新しく優秀なスタッフを探してきたらなんとかなるだろうという思い込みで引き受ける場合である。

1、2は最初の読みが正しければ、スタッフは少し忙しく、少し赤字ぐらいの状態で難を逃れる事が出来るかもしれないが、ちょっとしたトラブルですぐにデスマーチに突入しそうである。

3については、予算と納期だけ決まって、後からスタッフをあてがうということで、成功するか失敗するかはわりと運任せである。いいスタッフがいればいいが、通常であればひどいデスマーチになることが予想される。

上記のような仕事の受け方では、デスマーチになるであろうことはわかるわけだが、かといって仕事を受けないとどうなるかというと、他の仕事を探すしかないわけだが、探している間は給料を貰えない、というわけにもいかない。

自分の所属する会社がデスマーチに陥りそうな仕事は全部拒否しても、どこかの会社(もしくは個人)が受けてしまうので、期間が延びたり、金額があがったりということもカルテルでも結ばない限りないだろう。デスマーチな仕事を回避していると仕事がなくなっていくのである。

要は顧客主体な仕事をしている限り、デスマーチな仕事を受けざるを得ない状態になりやすいし、デスマーチになると余計資金繰りが悪化するという悪循環にはまっていく。

そうならないようにするために、会社は人だけ派遣してプロジェクトに関与しない方向に向かっていくという選択肢を取るわけだが、派遣される側の人にとっては、派遣先がデスマーチの場合も当然あるわけで・・。

今日の結論:デスマーチが回避できるかどうかは、会社の戦略によるところが大きい。デスマーチな選択をしがちな会社に入ったら、その後相当の努力と運がないと回避できそうにない。そんな苦労をするぐらいなら、入る会社を慎重に選択する方がよい。どこに入ってもなんとかなる、というのは幻想だと思う。
AD
いいね!した人  |  コメント(0)  |  リブログ(0)
2005-01-25 23:25:29

ソフトウェア開発はアイデア出しの連続

テーマ:ソフトウェア開発
著者: 高橋 誠
タイトル: アイデアが面白いほど出てくる本―これだけは身につけたい16の手法

---
問題解決には、基本として4つの手順・ステップがあります。「問題設定」、「問題把握」、「課題決定」、「課題解決」の4つです。
問題設定とは、何が問題なのかを明確にして絞り込むことです。次に問題把握とは、問題に関係するさまざまな情報を集めて、問題点を探し出して、解決するべき問題点では何が重要かを絞り込むことです。そして課題決定とは、絞り込んだ重要な問題点を元に解決すべき課題を決めること。最後の課題解決とは、さまざまなアイデアを出して課題の解決を考える。それが4つのステップです。
---

アイデアを引っ張り出してまとめる、というのはソフトウェアを開発するにおいて、避けては通れない話である。あるアイデアが劇的な速度向上を生んだり、劇的なコスト削減に結びつくこともある。言われたことだけをこなすという意識では、なかなか生き残れない。

もちろん、プログラムを実際に組む時ではなくて、もっと前の企画段階から設計段階までの各段階において、多種多様なアイデアが必要になるのである。逆に言うと、世の中に出回っているソフトウェアを追い抜くために、アイデアを出して、類似ソフトウェアを出し抜く必要がある。

そして、このアイデア出しという概念は、ソフトウェア開発をする会社には決定的に欠けているといっても過言では無い。ソフトウェア開発会社は提案力が弱いとかいろいろ書かれていることがあるが、それもそのはず、仕事を割り当てられたSEやプログラマが、過去の経験や思いつきで提案しているというような状態だからだ。

チームでまとまって、この本にあるような方法論を使ってアイデアを引っ張り出すということを行うと、仕様の抜けも減るし、より高度な提案も可能になるかもしれない。1人ではなかなか思いつかないようなことがチームなら出てきやすい。出てきやすくするための方法論でもある。

また、コミュニケーションツールとしても当然利用可能である。開発における疑問点や問題点も、どう質問したらいいかわからない場合等に、発言を引っ張り出すような使い方も効果的だ。

職業柄、コミュニケーション下手というか、なかなか仕事上の質問もできないというような人も多いのだが、どうコミュニケーションを取るか、というのもアイデア出しの方法論で解決できるのではないだろうか。

こういうのはあんまり学校で習わないので、慣れてない人は最初は思いっきり戸惑うかもしれないが、慣れてくると脳みそが活性化してくるだろう。いろいろ試してみると、チーム全体のレベルアップが簡単に出来るかもしれない。変にセミナーとかに出席させるより、費用対効果が高そうである。

AD
いいね!した人  |  コメント(0)  |  リブログ(0)
2005-01-21 07:47:12

ソフトウェア開発業界では括りが粗すぎる

テーマ:ソフトウェア開発
ソフトウェアとは、仕事で使うと限定すると、ほとんどがコンピュータと人がコミュニケーションするための道具であるといえよう。ソフトウェアはコミュニケーションツールなのだ、とここでは言い切ってしまおう。

人と人は会話する。同じ言語で同じ地方にいれば、間に通訳を挟まなくてもまぁだいたいコミュニケーションが取れるだろう。言語が違えば通訳を雇うことになるが、当然のことながら、両者の言語を専門に扱う人が必要になる。

日本語を扱う医者と中国語を扱う医者が会話をする場合、日本語と中国語の通訳ができて、医学の専門用語を知っている人が必要になるということだ。

ソフトウェアは、人とコンピュータをコミュニケーションさせるツールであると冒頭で述べたが、コミュニケーションを円滑に行うためには、同じようにその人(会社)の業務を知っていて、コンピュータをコントロールするための言語が知らないと話にならない。

しかし、ソフトウェア開発業界というのは、コンピュータ用の言語には詳しいが、業務知識の方はさっぱりというお寒い状態でもなんとかなっているのが現状である。

なぜそうなるのかというと、「ソフトウェア開発業界」といつまでも一括りだからである。業種が違えばソフトウェア開発内容も全く異なる。仕様の漏れがなくならないのは、業種によるノウハウの蓄積も何もなく、別の会社がまた1から考えるからである。

違うことをやっているのに、ソフトウェア開発というグルーピングですませてしまっていることが大問題なのだ。ソフトウェア開発会社毎に何かの業種に特化する必要はないが、せめて業種毎にノウハウを共有できる体制にしないと、よりよいものをより安く提供することはないだろう。

今はどの会社がどの業種に強いのかすら、誰もわからない。わからないから大手ベンダーに相談してしまい、大手ベンダーでは自社で対応できないと、下請けに出すしかない。そんな業界構造は21世紀には似合わない。
いいね!した人  |  コメント(0)  |  リブログ(0)
2005-01-13 12:56:02

仕様書にやらないことを書かないから後で喧嘩になる

テーマ:ソフトウェア開発
どんなソフトウェアを作るのか、を紙にしたものが仕様書である。一般的には顧客がソフトウェア開発会社側に示すものが仕様書であるが、現実的に中小企業では顧客側が書くことはほとんどなく、ソフトウェア開発会社側が仕様書を書くところから参加している。

要は自分で作るものを自分で決めているわけだが、仕様書作成過程において、顧客と何を作るかについて延々と話し合う事になる。この時点(まだ何を作るのかすら決まってない時点)で、予算と納期が決まっている事がよくある。

予算と納期が決まっているということは、仕様を作成する段階で、仕様から落とす項目が当然出てくる。「今回はこの機能はやめておきましょう」とかなんとか言って、顧客も「予算的に無理ということであれば、稼働してから考えましょう」と同意する。

ところが、予算と納期に合わせていい感じに仕様が決まり、いざ開発となって中盤から終盤に差し掛かった頃、急に顧客の偉い人が「この機能が足りないと使い物にならない」とか言い始めるのである。

ここで、「仕様書に書いてないじゃないですか!」と言っても、「この機能は必須である。仕様書から抜け落ちているのはそちらの不備である」とか言いかねない。さすがにそこまで責任転嫁するところはないと思いたいが、少なくとも顧客側は不満に思うだろう。不満はそのうち別の所で爆発したりするので無いに越した事は無い。

問題は、落とした項目について営業担当者レベルでは同意していても、仕様書には一切「今回やらないこと」として記載されていないということだ。書いてあっても機能追加になりそうな気もするが、その場合は顧客側の責任ということで、金額と納期の交渉は出来るだろう。

やらないことを書いたほうがいいと言うと、膨大になるから無理という議論になりそうだが、そうでもない。予算と時間があれば追加したい機能一覧と思えば、書きやすいのではないだろうか。

そういう意味では、最初から予算と時間に合わせて仕様を決める前に、一回り大きな仕様を用意して、そのうちこの部分を今回のシステム化範囲とする、としたほうが後々の仕事にも繋がるのではないだろうか。

書いてあることを全部満たすようにソフトウェアを作るという前提だと、とにかく俎上に載せたものは全部作らなければならないという感覚に陥りやすくなってしまう。

顧客も最後になって、今言わないともう作ってもらえない!と思うと機能を追加したくなるので、そういう心理に追い込まないことが結果的に予算も納期も守れることに繋がるのではないかと思う。

技術的に遜色ないなら、あとは心理戦である。同じ作るならどういうアプローチにすれば効果的かを考えていかないと、無駄に損をしてしまう。仕事を円滑にするためのパターンというのが、プログラマにはもっと必要なのかもしれない。
いいね!した人  |  コメント(1)  |  リブログ(0)
2005-01-12 09:55:34

プログラムが設計書だとすると設計という工程はプログラミングになるはずだが?

テーマ:ソフトウェア開発
最近のソフトウェア開発業界の風潮で、プログラムは設計書であり、プログラミングは設計工程という考え方がある。

今までは、プログラマがブルーカラー、いわゆる製造業でいうところのライン作業者みたいなイメージが蔓延していた。製造工程なんだから、部品を作り上げるまでの時間は的確に見積もれるし、完成までのスケジュールも把握できるという考え方だ。

プログラミング作業は製造工程だとすると、その上に設計工程が存在するはずである。ソフトウェア開発には、一般的にプログラム開発チームと設計チームが分かれていて、設計チームが設計書(非プログラム)を書き上げてプログラマに渡すのである。

ここでハードウェアの世界を見ると、ハードウェアでは設計者とライン作業者は完全に分断されている。設計者が設計書を書いて、工場に渡す(正確には直接ではないが)というのが一般的なのだと思う。

設計書(図)というものは、その通り作れば確実に動くという状態になっているはずのものである。なぜ矛盾がないと言えるかというと、実際に作って試したり、実際に作れない場合はミニチュアを作ったりして、試すからである。実際に作って試して問題なく動くことがわかってから、設計書を作るのである。

それでもハードウェアの場合、実物の部品というのは精度の誤差が積み重なって動かなかったりする。電子部品の場合は部品の質にばらつきがあることもある。それを最後のテストでチェックするということになる。

ところが、ソフトウェアは大きく異なる。プログラマに渡される設計書というのは、精度の差こそあれ矛盾無く記述されているということはない。なぜか?

逆説的に言えば、プログラムが最終的な設計書なので、プログラム以外の設計書が矛盾無く書かれていることはありえないということになる。矛盾がない非プログラムな設計書は、自動でプログラムに変換可能である。

さて、非プログラムな設計書は曖昧(何かが欠けているか矛盾がある)だとすると、ソフトウェアにおける非プログラマである設計者の存在とはなんなのだろうか。

プログラムはわからくても、設計はできるというような話をたまに耳にするが、設計という言葉の定義が少し異なるのだろう。最終的な設計書はプログラムだとすると、プログラムを見て検証しない限り、設計上正しいかどうかは解らないはずだが、それを無視してテストに頼っていたのが現状ではないだろうか。

ソフトウェア開発における設計者とプログラマの分離の弊害を指摘したのが、XPやスクラム等のアジャイル開発手法である。設計者という曖昧な存在を排除して、プログラマが設計してプログラマがプログラムを書くという、いたってシンプルな考え方だ。

ソフトウェア開発業界は、他業界のモデルをそのまま引っ張ってくるのではなくて、もう少しソフトウェアの持つ特性を意識した開発モデルを考えないといけないのではないだろうか。

いいね!した人  |  コメント(0)  |  リブログ(0)
2005-01-08 23:42:31

ソフトウェア開発会社の生きる道

テーマ:ソフトウェア開発
PM見習いの読書日記 ソフトウェアの値段 より
--
ただ、ソフトウェア開発専業のベンダーとしては、
・誠実に仕事をすることを約束して、かかった分の費用を請求する(人月清算ってことですね)
・あいまいな仕様書からの見積もり精度を高めて、一括で受注する
という選択肢しか残らないのかな?

--

ソフトウェア開発専業ベンダーというのは、営業や企画やマーケティングを他社に依存した会社のことだとすると、会社としては売るための仕組みが備わっていないので、口コミや誰か(ほとんど社長)のトップセールスで仕事を取ってくるような場合がほとんどではないだろうか。

とすると、いくら高尚なことを口にしようとも、やりたくない仕事でも引き受けざるを得ない。得意分野だけで勝負したくても、そもそも仕事選べないのであれば、毎回業務も異なり客も異なり開発言語も異なりコスト見積の算出方法も相手に合わせて用意する必要があるということだ。

そのような状態では、会社としての特徴はもちようがない。ソフトウェア開発業界が俗人的で、仕事は会社ではなくて人につくとなるのも当然の結果である。会社としての特徴を持つということはどの仕事を受けてどの仕事を断るのかはっきりさせるということだ。

なので、アジャイル的にかかった分だけのコストを請求していいのかどうか、という以前に、どうやって仕事取って来るのか、営業をどうするのか、である。営業をどうするのかを決めるには、どこに集中するのかである。

「Javaできます」は「英語できます」と同じぐらい、顧客から見ると意味が無くて、それは個人のスキルの宣伝でしかない。そんな宣伝をしている会社は、「弊社の社員をお貸ししますので使ってやってください」と暗に言っているということだ。

顧客は何を望むのか?「どうやったら利益がでるか(経費が減るか/売上が増えるか)」である。そのために「御社のこの部分をこうするとこれくらい利益がでます(経費が減ります/売上が増えます)」と言える何かが会社にないといけない。

そして、顧客に提案した内容の一部分がソフトウェアなのである。自ら提案するから、自分の会社の得意分野で勝負できて、開発言語も自前で選択でき、最適化することが可能なのである。ここまでこないと技術がコストダウンに結びつかない。

ソフトウェア開発会社は、顧客の仕様に合わせて作り、最終的に顧客の著作物となってしまう仕事ばかりしているのではないか。お金を貰っても自社には何も残らない仕事ばかりしてきていないだろうか。

プログラマは誰の金で仕事をしているのかわからなくなるのである。受託開発ならほとんどが顧客の金である。自社で働いているのではなく、顧客の会社で働いているようなものである。

会社は少しの間儲かるが、プログラマの磨り減り具合を考えると、本当にそのやりかたでいいのかどうかは疑問である。本当にいい仕事をしようと思ったら、自社にプログラム資産が蓄積されていき、どんどん仕事の質をあげていけるような、そんな状態にしないと、この先続けていくのは難しいのではないだろうか。

プログラマのやったことが蓄積されていき、その中からまた新しいものが生まれていく、というような好循環になってこそ、コストダウンにつながり、ソフトウェア開発専業会社として社会に貢献できるのではないかなという気がする。
いいね!した人  |  コメント(0)  |  リブログ(0)
2005-01-07 00:11:22

受託開発は客から見ると投資である

テーマ:ソフトウェア開発
IT Pro 不透明なソフト開発の価格,解決への第一歩は“相場”を示すこと
から

--
では,こうした数値が実際にソフトの適正価格を判断する指標になり得るのかを,少し考えたい。データの分析結果で明らかにされるのは,ソフトの規模に対する平均工数,平均不具合数,平均納期などである。調査が十分なサンプル数を集めれられば,ある程度の指標になると思う。
--

引用のような方法で適正価格が得られるかどうかは、正直ばらつきが大きすぎるし、顧客側が開発工程のどの期間に仕様を確定したのかとか最後にちゃぶ台返しをしたのかとかで、工数や期間は著しく変わってくるため、無意味なように思う。

後からソフトウェアを見て、これならいくらですね、と言うのはそれほど難しくない。仕様が決まっているソフトウェアならわりと正確な見積が出せるだろう。それで見積が出るから、他の同程度の規模(規模の軸も不明だが)のソフトウェアが似たような金額で納品できるかというと、そんなことはない。

なぜうまくいかないのかというと、仕様(契約)を満たしているかどうかの判定に、顧客の主観が大きなウェイトを占めているということがあげられる。顧客が完成したソフトウェアを見てから駄目出しをしているようでは、コストがいくらあっても足りない。

仕様の煮詰めが甘いだけといわれるかもしれないが、顧客もうまく説明できないようなものを作る際に、見ないとイメージできないという場合も多々ある。モックやプロトタイプを作りながらイメージを固めて、こつこつソフトウェアを構築していく場合の見積は、後からソフトウェアを見ても当然わからない。

よって、ソフトウェアの値段の相場という概念がそもそも間違いであるように思う。会社にとってソフトウェアを利用することで、経費が削減される/より儲けることができるという場合に、投資としてソフトウェアを発注するのであって、その際に投資金額も費用対効果で決めるわけである。先に予算ありきであり、ソフトウェアありきではない。

当然、その予算にはどのようなソフトウェアを作るべきかという企画段階からの予算も含まれる。ソフトウェア単体の値段の相場を出すことに何か意味はあるのだろうか。

他社が導入したからうちも、そしてそのソフトウェアはいくらなのかというような考え方では、SIベンダーにいいようにされるだけなので、辞めておいた方がよいだろう。相場を決めて得をするのは当然SIベンダーなのだから。
いいね!した人  |  コメント(0)  |  リブログ(0)
2005-01-05 21:58:50

弛緩と集中

テーマ:雑記



著者: 山本 真司
タイトル: 30歳からの成長戦略 「ほんとうの仕事術」を学ぼうより

--
ある先輩が語ってくれたことがある。その先輩は二十代に弛緩→集中の習慣をつけたという。その先輩は大学卒業後、外資系の大手銀行に就職した。その銀行では、夏休みは三週間と決められていた。日本人の先輩は、そんな非常識な長さの夏休みは取れないと上司に申し出たらしい。その上司(外人)が答えた。「我が社では休みを三週間取らないと首である」と。先輩は驚いて聞いた。「なぜですか?」と。その答えがふるっている。「休みの最初の一週間は疲れを取るだけで終わる。二週間目に英気が養われる。三週間目に仕事をしたくなる。そこまで休んではじめて、凄まじい集中力で仕事できるようになるもんだ。」と。
--

情報産業は8時間毎日こつこつ働けばいいというものではない、と頭でわかっていたが、こうストレートに表現する上司には当然ながら出会ったことがない。

集中力が大事だ大事だ大事だと、念仏のように皆語っているが、逆に弛緩(休息)について語る人はほとんど見かけない。なぜだろうか。弛緩=さぼりという認識がまだまだ根強いからだろうか。

脳を酷使するということについて、経験がないということなのかもしれない。改善しないといけないのはまず労働基準法だろうと思うが。

(参考)
--
労働基準法 第4章 第34条
使用者は、労働時間が6時間を超える場合においては少くとも45分、8時間を超える場合においては少くとも1時間の休憩時間を労働時間の途中に与えなければならない。

--

本当にソフトウェアに対して責任を持たせるのであれば、昼寝しようが何しようがどうでもいいように思うが、契約社員や派遣社員は時間による契約がほとんどであり、正社員もそれに引きずられてしまうのである。

いい加減に、時間による契約はやめるべきだと思うのだが、わかりやすい指標がないという理由からかなくなる気配すら感じない。弛緩ということを考慮すると、とても時間契約なんてできそうにない。

効率を上げるという目標を掲げるのであれば、集中させるための弛緩についても気を配るべきであろう。今年のキーワードは、弛緩と集中でどうだろうか。まずは昼寝からである。昼ご飯食べた後は眠いので、寝るところから開始しよう。




いいね!した人  |  コメント(0)  |  リブログ(0)
2005-01-04 23:10:29

映画とプログラミング

テーマ:ソフトウェア開発
あけましておめでとうございます。
今年もよろしくお願い致します。

---------
くろねこ亭-ハウルの動く城のページより

ハウルの動く城についてのインタビュー中の宮崎監督のコメント。

宮:スタッフと討議して映画を作るのは不可能です。僕は「こういうふうにします」としかできません。

この言葉を見て、まだ世の中にないものを作るという行為は、討議とか会議とかで決めるものではないのだと実感した。

見えないものをどうにかして形にする、このどうにかする部分は積み上げではなかなか作り出せない。個人の発想や直感に頼る部分が多い、俗人的な部分であるが、俗人性を排除してしまっては、世の中にまだない新しいものを作り上げることはできないと思う。

システム設計も、コアとなる部分はやはり何人かで決めるというよりは、1人がきちっと決めた方が上手くいくことが多い。逆に言うとある程度設計できるような人が1人以上いないようなプロジェクトは初めから危なそうということでもあるが。

オープンソースなプロジェクトでも、企業内の開発プロジェクトでもそうだと思うが、最初からチームでどのように作るかを話合うということをやってもうまくいかないのである。

ベースなりフレームワークなりがある場合はまた違うだろうが、何もないところから全員であぁだこうだいうよりは、まずは個人を走らせてみるのが大事ではないだろうか。

余裕があれば、2~3人をそれぞれ別々に走らせて、プロトタイプ開発をさせてもいいかもしれない。無駄と思われるかもしれないが、同じ仕様で違った生成物を見て、違うアイディアからお互いに触発されるだろう。

チーム開発は、個人のアイディアを平均化させすぎてしまう傾向にあるように思うので、もう少し俗人性をいい方向に発揮させてみることも考えてもいいのではないだろうか。

もっとも、評価する人間が価値を評価できなければまったく意味がないのだが。
いいね!した人  |  コメント(0)  |  リブログ(0)

AD

ブログをはじめる

たくさんの芸能人・有名人が
書いているAmebaブログを
無料で簡単にはじめることができます。

公式トップブロガーへ応募

多くの方にご紹介したいブログを
執筆する方を「公式トップブロガー」
として認定しております。

芸能人・有名人ブログを開設

Amebaブログでは、芸能人・有名人ブログを
ご希望される著名人の方/事務所様を
随時募集しております。