開発の遅れはプロセスの問題が大きく、開発者の責任は小さい 47
ストーリー by headless
原因 部門より
原因 部門より
本家/.「It's Not Developers Slowing Things Down, It's the Process」より
ソフトウェアエンジニアはコードを書くペースを理解しているが、マネージャーは理解していないことが多い。1行のコードは1分で書けることもあれば、1日かかることもある。それでも全体的に見ればコードを速く書くかどうかよりも、目標が適切に設定されているかどうかの方が目標の達成に重要な役割を果たす。このことについて、プロジェクト管理ツールなどを提供するSprint.lyが開発サイクルに関するデータを分析し、裏付けるデータを公開している。開発者の作業時間は全般に平均的で変動も少ないのに対し、仕様や作業の優先順位の確定にかかる時間は変動が大きい。経験を積んだ開発者が認識しているように、要求仕様がはっきりしないことや、変更されることが作業速度に最も悪影響を与える。作業が遅れるもう一つの大きな要因は、複数の作業を並行して行ったり、切り替えて行ったりすることによる開発作業の中断だ。記事では仕様が過度に漠然としている場合、決定プロセスに開発者をかかわらせ、無理なら無理だと言える状況を作ることをマネージャーに勧めている。他に何か追加しておくべきことはあるだろうか。
開発者の価値 (スコア:2, 興味深い)
開発者の価値は低いと言っていますね。
責任が無いんだから。
安いので十分。
マネージャー向けのマーケティングだよね、これ?
Re: (スコア:0)
責任が無いってのは、責を負う立場じゃないという意味と、責を負うような事態を招いてないという意味とがあるよね。
Re: (スコア:0)
でも、誰を置いても責を負うような事態を招かないということは、
その仕事は難易度が低く、置換可能な人材で構成できるということになるので、
安く買い叩かれますよね。
まあ、sprint.lyのプロジェクト管理ツール買ってね、という宣伝な訳ですけど。
Re: (スコア:0)
外国だと、中間管理職を作る専門学校・大学がありますからね（フランスのゴーン社長はその出身）。
最初からプロセス管理専門の人を雇っていて、未達だとその人の首が飛ぶ。
一方日本だと、就職面接で「課長できます、部長できます」はギャグとして扱われ…。
プロセス管理は「現場からの上がりポスト」になってる
Re: (スコア:0)
開発が遅延さえしなければ品質など問わない、というのであればその通り。
Re:開発者の価値 (スコア:1)
開発が「遅延する原因」はプロセス。
たとえばこれ→ 「要求仕様がはっきりしないことや、変更されることが作業速度に最も悪影響を与える」
その基本となる、開発速度や品質を決めるのが開発者の質。
そういうことじゃね。
＞マネージャー向けのマーケティングだよね、これ?
＞＞このことについて、プロジェクト管理ツールなどを提供するSprint.lyが開発サイクルに関するデータを分析し、裏付けるデータを公開している。
せやな
Re: (スコア:0)
マネージャーが知識や判断力に乏しく開発者のスキルに達していないとも読める。
理解の仕方はお好きにどうぞ。
要件変更と工数見直し (スコア:2)
日本での事情に限定します（外国の状況には詳しくないので）が、記事の分析通り、要件定義を軽視しすぎていると感じます。
要件は開発者側だけで決定できるものではありませんから、利用者側の都合で変更や追加が発生することはやむを得ないとしても、
・十分なヒアリングや検討を行い、変更の可能性を最小限に抑える
・それでも変更が発生してしまった場合は、工数を見直し、納期やコストが変動することに合意いただく
・「なぜこの要件なのか（要件が変更されたのか）」を最前線の開発担当者にも伝え、利用イメージを共有する
といったことが重要になると考えます。
私たちがこの辺を端折ってしまい、後から要件が膨らんでも納期や請負金額が変わらず、最前線の開発担当者にしわ寄せが来て苦労するのは避けたいです。
あるいは、要件変更の合意が取れず元の要件のまま進めるのも、結局使えないものができるだけで、開発者も使えないものを作るモチベーションはありませんから、これも避けるべきです。
価格競争に陥り、極端な安価で受注してしまう開発業者も多いと聞きますし、そういった会社は要件定義の能力に乏しく、また軽視していると思われます（営業担当者が要件定義の決定を下す会社もあるかも）。
要件定義は実務や運用にべったりで、決して「アレゲ」ではないのですが、私たちも要件定義フェーズから積極的に関わる体制を作っていかないといけないでしょう。
Re:要件変更と工数見直し (スコア:1)
日本の企業がITに無知なことも要因かと思います。
転職してIT企業に発注する側になりましたが、安く早く仕上げるのが当たり前と思ってる人が多すぎます。
機械や建物といった製造物・建造物には全然うるさくないのに、ことシステム構築となるとクレーマー並の注文ばかりつけます。
IT企業って低く見られてるのだと思います。
Re:要件変更と工数見直し (スコア:2)
機械や建物といった製造物・建造物には全然うるさくないのに、ことシステム構築となるとクレーマー並の注文ばかりつけます。
ハード重視、ソフト軽視ですね。人件費軽視と考えてもいいかもしれません。
（政治ではハコモノを重視したり、飲食店では原価がこれだけなのに高すぎると感じたりするのと同じかと。）
IT企業って低く見られてるのだと思います。
むしろそれは、私たちIT企業の請負開発のあり方に問題があったわけで、価格を適切な水準に引き上げるか品質悪化を顧客に受け入れさせるかの二択を突きつけるべきでしょう。
IT企業側が自分たちの見積もりを明確な根拠をもって提示し、価格競争をしない心構えが必要だと思います。
Re: (スコア:0)
「私たち」とはどのような立場なのか定義してくれないとイメージが共有できない……
>私たちがこの辺を端折ってしまい
>私たちも要件定義フェーズから
Re:要件変更と工数見直し (スコア:1)
「私たち」とはどのような立場なのか定義してくれないとイメージが共有できない……
イメージしているのは、要件定義担当の開発者です。
本家の原文だと、
(1)要件定義担当者：stakeholder（直訳は「利害関係者」なので、客先も含めた表現です）
(2)プロジェクトマネージャ：manager
(3)開発者：developer, dev
と分けられています。
先の文章では「私たち」で(1)を指しましたが、(3)の人が(1)を敵視するのではなく、開発プロセスの一部として(1)(3)に分かれているだけで、利害相反も上下関係もない立場であってほしいと思っています。
また、(1)と(2)を同一視することもありますが、むしろこれを分離しないと開発プロセスは良くならないのではないかと感じます。スケジュールは(2)の立場で決めますから、(1)に引っ張られて無理なスケジュールを設定してしまうことがないように、顧客を相手にする(1)とチーム内を相手にする(2)は、適度な緊張感をもって活動すべきだと考えます。
Re: (スコア:0)
自社の管理職・上級職だけがネックならまだしも、客も同レベルだから救いようがない。しかも自分たちに問題ないと思ってるから、同じ失敗を何度も繰り返す。
Re:要件変更と工数見直し (スコア:1)
自社の管理職・上級職だけがネックならまだしも、客も同レベルだから救いようがない。
管理職・上級職のどのあたりをネックと思っているのか、ご自身の言葉でもう少し説明してほしいかな。
こちらでも想像はできるのですが、管理職や上級職の立場を理解していないか、少なくとも彼らの立場から問題を捉えようとしていないようにも思えるので。
Re: (スコア:0)
受注側の作成する要件定義もあやふやなのは
発注側の要件定義が不透明なのが原因
当然客に明確な答えがあるわけではないので
要件を物理レベル近くまで具体化しなければいけない、
時間をかけなければいけない。
が、見切り発車の炎上が常。
Re: (スコア:0)
どんなに具体的に説明しても、客に「説明から出来上がりをイメージする力」がないから
見切り発車せざるを得ず、ある程度進んでから「こうじゃない」と言われて要件を調整。
というのが前提で、いかに巻き戻しを少なく見切り発車するかがミソというバッドノウハウ。
末端作業者がパソコンの操作もおぼつかないようだと、出来たモノに「こうじゃない」
「こうしてくれ」という要求をアウトプットする能力すらないことも…
Re:要件変更と工数見直し (スコア:2)
プロトタイプでも紙芝居でもいいので、画面レベルで動きを見せるのが必要だし、実際に行っていると思います。
顧客に出来上がりをイメージする力がないのと同様、開発側には業務の隅々まで察知する力はないので、細部にわたって要件を詰めないといけないのですが、曖昧な部分が残ってしまい問題となるのが実情でしょう。
それを改善するためにどうするかを意識し、バッドノウハウで済まさないことが、要件定義工程に求められるスキルかな、と思います。
Re:要件変更と工数見直し (スコア:2)
＞開発側には業務の隅々まで察知する力はないので、
これが、現状の最大の問題。
最下層までは無理でも、開発側の中流には「顧客の用途」を知っている人間が関わるべき。
何度も言ってるが、プログラマはプログラミングだけじゃなく、ユーザ側の業務知識が無いと無能なんだよ。
言語なんていくつ覚えても、例えば、帳簿の付け方を知らずに会計関連の仕事が出来る筈が無い訳。
「公認会計士の資格を持ったプログラマ」なら、会計関連の仕事を高価に受注可能か思われるけど、如何？
//逆も真なんだけどね。
-- Buy It When You Found It --
Re:要件変更と工数見直し (スコア:1)
＞開発側には業務の隅々まで察知する力はないので、
これが、現状の最大の問題。
最下層までは無理でも、開発側の中流には「顧客の用途」を知っている人間が関わるべき。
何度も言ってるが、プログラマはプログラミングだけじゃなく、ユーザ側の業務知識が無いと無能なんだよ。
無能という表現はどうかと思いますが、おっしゃることはわかりますし、同意できる部分はあります。
要件が曖昧で設計者が業務を理解していないと、往々にして開発者の思い込みで機能が作り込まれ、顧客の要望から食い違ってしまうことがあるので、顧客に近い上流の段階で不明点はつぶしていかないといけないでしょう。
「公認会計士の資格を持ったプログラマ」なら、会計関連の仕事を高価に受注可能か思われるけど、如何？
//逆も真なんだけどね。
どうだろう。
当方、「中小企業診断士の登録を受けた開発担当者」ですが、実感として人月単価（客先常駐です）そのものはそれほど上がっていない印象です。
業務自体は上流をやらせてもらえるようにはなったし、工程が上がることで人月単価は上がりましたが。
Re: (スコア:0)
「公認会計士の資格を持ったプログラマ」なら、会計関連の仕事を高価に受注可能か思われるけど、如何？
//逆も真なんだけどね。
公認会計士の資格を持った中層から下層のプログラマがいれば、曖昧な仕様もカバーできるってこと？
設計者の怠慢の言い訳じゃないの？
相当の知識がないと理解できない仕様じゃ、仕様書とは言わないんじゃない？
Re: (スコア:0)
発注受注どちらでもなくコンサルの立場で間を持てないかと双方に提案したことが
ありますが、いずれにもノーと言われましたねえ。
その前年には発注者側で火消しに入って業務終了時にはずいぶんと持ち上げられも
しましたけど、第三者として間に入るとなると事情も違うようで。
炎上させといて発注元に常駐する他社の技術者に事態収拾を頼みにくるような所なんで、
提案の翌年に「うちのメンバーとして入って欲しい」といわれた時もさすがにお断りしたなあ。
Re:要件変更と工数見直し (スコア:1)
「プログラマ」を語義どおりにとれば設計担当者の怠慢となりますが。
元の人、「開発側の中流」という言い方もしているので、設計も含めた開発側の要員を総じて「プログラマ」と呼んでいるかもしれません。
（元の人の反応待ちです）
いずれにしても、要件や仕様が曖昧なまま実装に入れば、顧客との認識のずれや手戻りも多く、プロジェクトの遅延要因となります。
実装者に業務知識があれば、要件を詰める必要があるとアラートが上がる可能性はありますが、実装者に業務知識にあるという前提に頼るのは危険ですし。
（勉強会などで、十分な業務知識を積ませてあるならリスクは下がりますが）
アラートが上がってもそれを拒否して、不正確な仕様のまま実装を押し付ける要件決定者やPMもありますが、論外ですね。
Re:要件変更と工数見直し (スコア:1)
呼ばれたので追記しておきます。
何事も、100%はありません。
仕様書も100%文言通りに実装して済む様な代物は作成不能です。
それでも、せめて実装可能な程度の仕様書は作成するべきでしょう。これは、上流側の責任だし、特にシステム全体の結合については、下層が把握するのは無理だからです。
（下層には自分の担当範囲がシステムに与える影響を把握する義務が在るが、他チームの分まで担当するんじゃチーム分けの意味が無い）
顧客の要求の汲み出しは、本来は上流の仕事ですが、「実装する下層だから気付く問題」ってのも存在します。
「実装するまで分からない」機能を要件定義の時点で決める事も現実的では無いので、その部分は「下層に任せる」事になります。
で、私の発言は、この状況での下層のレベルへの言及です。
但し、顧客と直接対話するのは上流だけでしょうから、上流側にも十分な能力は必須です。
＞実装者に業務知識にあるという前提に頼るのは危険ですし。
これも、100%を望むから危険なのです。
実装者が失念する可能性は常に在るので、多階層でのチェックは不可欠です。
逆に、多階層でのチェックを有効に実施するには、各階層に業務知識を持った担当が存在する事が前提です。
尚、「プログラマ」の呼称は、「相対的な下位担当」のつもりで使用しています。
ごく小規模な場合を除いて、最終的なシステムの規模から必然的に階層化される筈で、規模に応じて階層が増えるので、上位と下位の作業を固定化するのは問題でしょう。
現在は、作業を固定して運用して事が多いのでトラブルが絶えないと、私は考えます。
-- Buy It When You Found It --
そういう場合もあるのかもしれないけど (スコア:2)
え!?
Re:そういう場合もあるのかもしれないけど (スコア:1)
ソクラテス曰く
ソフトウェアエンジニアはコードを書くペース（を予測し保証することが不可能であること）を理解しているが、
マネージャーは理解していないことが多い。
Re:そういう場合もあるのかもしれないけど (スコア:1)
コードというか「定義」という方がより明確な様な気がします。
ソフトウェアエンジニアは「定義」を書くペースを理解しているが、
マネージャーは「定義」を書く事を忌避している。
マネージャーにプログラムレベルの下位の（細かい）「定義」をさせる
のは、もちろん道理に反していますが、
今のマネージャーは***全ての***「定義」を忌避する事が道理だ
と思い込み、さらに悪い事に「定義」するスキルを忌避する事が
道理だと思い込んでいる面も有るし。
コードと言わず、「定義」と言った方が問題の理解が深まるように
思いますが。。。
Re: (スコア:0)
自分も「ん？」と思いますが、
1行のコードは1分で書けることもあれば、1日かかることもある。
マネージャーはこれを把握できないってことですかね。
ある機能の実装にかかる工数のマネージャーの見積もりは基本的に(エンジニアよりは)的外れである、というか。
ITに限らない部分もあるね (スコア:1)
＞要求仕様がはっきりしないことや、変更されることが作業速度に最も悪影響を与える。
商品開発でも同じ事が言える
現場を知らない営業が開発を遅らせるのはよくあること
最終段階まで進んだ後で話をひっくり返したり
コスト考えずに安易な思いつきで要件追加したり
現場からみるとありえない馬鹿馬鹿しい要求をしてきたり
そういうのは開発段階で言っておけよ
何度も試作を見せて意見を聞いて、最終決定発表のはずの会議で
それまで存在していなかった要件追加とかアホかと
しかも、常識があればその点は問題ないことくらいわかるだろ！というアホなクレームで差し戻されたりする
Re: (スコア:0)
営業が「どこまで技術的に受け止められる範囲か」がわからないように、
技術も「どこまで営業的に受け止められる範囲か」がわからないから、
最後の最後まで営業の参画を許しちゃうんじゃないかな……と思うことはある。
個人的には社内の引き継ぎをもうちょっと濃密にやっていいように思う。
技術営業どちらがどちらへということではなく、お互いに。
それをちゃんと業務負担だと評価するシステムが要るけど。
無理なものは無理 (スコア:1)
現在のリソースでは無理なものは無理と言わないと、最終的に会社のためにならないと、経験上悟りました。
数年前までは超絶技巧で乗りきったりしましたが、結局それは技術的な負債になって、その場しのぎにしかなりませんでした。
人工知能でホワイトカラー従業員を一掃するみたいな、よほどすごいシステムでない限り、
基本的に予算とスケジュールを追加すれば大体のシステムは作ることが出来ます。
足りない場合は足りないと要求すべきです。
Re:無理なものは無理 (スコア:1)
同意。
システム開発もビジネスなので、納期も予算も動かせないことはありますが、できないものはできないと伝える必要はあります。
上流工程では実装規模を過小に見積もったり、開発者の技術力を過大評価したりするものなので。
（経営側が実装担当者を安く使い潰す悪意は、じっさにはほとんどないと感じます）
Re:無理なものは無理 (スコア:1)
陰謀論でいうところの害するための悪意ゆえではなく、お決まりのアレがここでも成り立つというわけですね。
# ハンロンの剃刀
Re:無理なものは無理 (スコア:1)
# ハンロンの剃刀
はい。
工数を過小に見積もる場合、上流工程が「無能な働き者」だからだというのは想定に入れていいと思います。
#「反論のカミソリ」だと思っていたのは内緒。
要件定義やプロジェクトマネジメントは、開発現場の経験だけではなく、座学で基礎をきちんと学ぶ必要があると思います。
silver bullet (スコア:0)
いくつめの銀の弾丸だよ
Re: (スコア:0)
これまでの「銀の弾丸」全て集めて16連射したら結構な効果があるような気もしなくもない
Re:silver bullet (スコア:1)
Re: (スコア:0)
でも銀の弾丸を撃っているのも狼男なんだよね
Re:silver bullet (スコア:1)
銀の弾丸を撃つ者であるなしを問わず狼男を特定して排除、
狼男殲滅後に真人間が銀の弾を行使と問題を分割するならば
テーマの前半パートは過去ストーリー [srad.jp]で人工知能が
近々実現してくれると展望を紹介している
…それで解決だといいんだけどそう簡単にいかないだろうなあ。
Re:silver bullet (スコア:1)
俺は占い師なんだが、そいつじゃなくてその右の奴が狼男だったぞ。
Re: (スコア:0)
自決用かな？
Re: (スコア:0)
Barbie「金の玉はない」
やはり (スコア:0)
コンテクストスイッチは重い処理であるということか
Re: (スコア:0)
「そこでマルチプロセッサですよ」
→ デッドロック
Re:やはり (スコア:1)
「そこでロックフリーですよ」
→変更があったなんて、俺はきいてないよ？！(ABA問題)
並列はダメというのはわかるなあ (スコア:0)
バグ修正と画面の更新を同時にやってるけど、バグフィックスが多いせいで１日で済むはずのところが１週間近くかかってしまっている
マイクロソフトみたいにバグ修正と新規開発で分業するというのが一番いいのかもしれないね
Re: (スコア:0)
画面を更新せずにバグ修正してたら1週間じゃ済まないでしょう。
いろんな計算 (スコア:0)
> ソフトウェアエンジニアはコードを書くペースを理解しているが、マネージャーは理解していないことが多い。
開発は一週間かかるけど、修正は1日でできるだろう！
みたいな人日計算あるよね。
だから修正に時間かかるためにリリースに影響が出るスケジュールになってしまう。