【意味】ステップ数ｗ【あるの？】

以前、同じようなスレがあったのですけど、無くなってたので立てました。

自分は今、ステップ数について異様にこだわる顧客と付き合ってます。最終的な納品物の
コードステップ数であれば提示することは普通にありますが、予想ステップ数、ステップ数
からの予想テスト件数、実績テスト件数、バグ予想件数、バグの件数、これらを非常に
細かく聞いてきます。

そこで、

１．ステップ数マニアに対する対応策、回避策。
２．ステップ数マニアが満足するツール。
３．ステップ数マニアの生息地。

などを語り合えればと思います。

　　　　　　　　　　　 　∧..∧
　　　　　　　　　　　. (´･ω･｀)　　 いらないスレは、捨てっブ〜
　　　　　　　　　　 cく_>ｙｃく__）
　　　　　　　　　　　（___,,_,,___,,_）　 ∬
　　　　　　　　　　彡※※※※ミ　旦
￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
　　　＼　どっ！！ 　／　　　＼　ワハハ！　／
　 　　　＼　　　　　／　　　　　　＼　　　　∞
　l||||||||||||||　∩,,∩　∩,,∩　　∩,,∩　ﾐ∩ハ∩彡
　（,　 　　）（,,　　　 ） 　　　,,）（　　　　）（　　　　）

ちなみに私が使用している言語は、主にJava、C#などをつかったWebアプリです。

コボルではステップ数で円/KBなんていう、野菜か魚のような売り方が可能だったと
聞いてますので、多分その名残じゃないかと思います。

正直、非常に迷惑というか、うまい回避策を模索中です。顧客側はステップ数から
目標テスト件数、目標不具合件数を出しているようなのですが、因果関係をどのように
考えているのかは全く不明です。

ステップといえば聞いておくれよ、>>1

うちの爺ちゃんは、年甲斐もなく社交ダンスを踊るんだが、
昨日、爺ちゃんが通っているダンス教室の近くを通りがかっ
た時に爺ちゃんを見かけたんだ。爺ちゃんの隣には上品な
感じの見るからに育ちの良さそうな、メガネをかけた銀髪
のお婆さんがいて、なんだか２人で楽しそうに話してた。
俺、うちの爺ちゃんがあんな楽しそうな顔で笑ってる顔初め
て見たよ。その時俺は、爺ちゃんが社交ダンスに精を出す理
由に納得がいった。そういえば婆ちゃんが死んでからもう１０
年以上たつもんなぁ・・・と思ってふと見ると、２人は手をとり
あって踊りだしたんだ。人目もはばからず、楽しそうに。
普段あんな無口で無骨な爺ちゃんが、一生懸命相手をリード
している。俺、思わず泣いちゃったよ。２人をみてて涙がとま
らなくなった。爺ちゃんがこんなにダンスが上手くなるまで、いっ
たいどれほど練習したのだろう、どれほどのステップを踏んだ
のだろうと考えると、感動して、思わず、爺ちゃんが踏むステッ
プを涙をこぼしながら一つ一つ数えていたよ。

昔々、ある糞外注がステップ数を稼ぐために
1000要素の配列をクリヤする目的で次のようなコードを書いて来やがった。
　array[0] = 0;
　array[1] = 0;
　array[2] = 0;
　（中略）
　array[999] = 0;

確かにこういうやり方だと“生産性”は素晴らしい罠ｗ

array = null;

>>5
>昔々、ある糞外注がステップ数を稼ぐために 
>1000要素の配列をクリヤする目的で次のようなコードを書いて来やがった。 

ステップ数を稼ぐ必要のあるような
発注をするほうが悪い。

Hか？

NE○か？

今いる日立ソフトは、あんまりステップ数を気にしないな。
NTTコムウエアは、かなりステップ数至上主義で、リーダーの人がいつもぼやいてた。

>>10
東戸塚乙

>>10
私は昔H系にもいましたけど、ステップ主義でした。同じH系でも色々なんですね。というか
バラバラなのかｗ。

回避方法とかあるといいんですけどね。集計取った後に、>>5のようなクラスを一個作れば
いいんですかね。本当はユーザー側の前でその話して、「そんなのいらないよ」って言わせ
たいんですが。

顧客に判断させるようでは駄目だ

仕様書をはかりに乗せろ。

>>13
ちょっと言葉足らずでした。自分の場合、ステップ数によって見積り金額に影響が出たりは
しないんですね。そういう経験もありません。そこは救いだと思います。

ただ、予想ステップ数だとか、そこから割り出したテスト件数を実績であわせないといけなかったり
するのが面倒なんですね。

自分が一番マトモと感じたのは、複雑度を提示する、というものです。これは納品物としては
一定の意味があるかと思いますが、ステップ数ｗ。

今日歩いた漏れのステップも追加ちてくり。

>>14
これ、結構ありませんか？お役所系はドキュメントの重さが大事って聞いたことがありますｗ。
まぁ、でもステップ数よりはマシな考え方ですかねぇ。

複雑度ってどうやって計測するの？
ファンクションポイント法とか？

>>18
分岐を軸にした計算ですね。

http://www.jajakarta.org/turbine/jp/turbine/maven/reference/metrics.html

こんなのは、一定の意味があると思います。

いろいろあるんだねぇ．．．
JavaだったらMaven使えばこういった資料が自動生成されんのかな。
これみていろいろ判断するのはシステムアナリストの仕事っぽい
感じがするけど。

>>15
煽るつもりは無いのだが。
>予想ステップ数だとか、そこから割り出したテスト件数を実績であわせないといけなかったり
>するのが面倒なんですね。
「統計的な数値に実績を合致させる為の作業が発生する」　というわけか。
そういうことをしなくてはならない羽目に陥っているわけか。
品質管理の実施指針の決定権が発注元に握られているわけだ。
ならば貴方がどのようなものがマトモと考えようが無駄ではないか？
発注側を説得するつもりであるならば別だが。
発注側を説得するつもりならばこんなところで愚痴書いている暇なぞ無いだろ？

>>21
> 発注側を説得するつもりならばこんなところで愚痴書いている暇なぞ無いだろ？

いえ、説得するつもりは全くありません。容易な回避方法を考えたいということですね。

ただ、ユーザーサイドのシステム部門と、我々の発注元企業とは基本的にその辺の
やりとりは一切していないようです。ですので、ユーザー側のシステム部門から
「いらない」って言っていただくというのは一つの方法かも知れません。

>>1
基本的に>>21と同じ意見だけど、ある程度回避するならば方法はある。
自分がやった方法だが・・・。

１）ステップ数を測る範囲を限定する。
２）ステップ数を出して、そこから割り出せる予想テスト件数などの定率を自分から提案する。

１）はかなり有効。WebだったらIDEやらが生成するコードを差し引いたり、クラス設計・モジュール
分割の段階で、必要なステップのみカウントする方法。
FP法でまず定量を出してから、ステップ換算するのもあり。（実績値が必要かも）


２）は１）ほどきっちり設計できていない場合にやる。
ちゃんと数字で論理的に説明しないと、突っ込まれるので注意。
　EX)　「ステップ数は○○Kstepでした。内、フレームワークからの転記が○○Kstep、クローンコード
　　　　　として実績のあるコードが○○Kstepでしたので、予想テスト件数は元ステップ数と比べ、○○です。」
もちろん嘘いっちゃいかんよ。

そんなことやる暇ないとつっぱねれ

一応貼っとく
http://capsctrl.que.jp/kdmsnr/wiki/bliki/?CannotMeasureProductivity

>>25
ここで>>1が気にしなければいけないのは「生産性」ではなくて
「成果物の品質」だと思うんだ。
>ビジネスはいつだって計測できないものを扱っているのです。（引用）
この部分が一種の諦めの感情に見えて共感できないんだ。

それからステップ数から予想テスト件数は、どう考えても捻出できないんだ。

>>23
ありがとうございます。

ただ、実装後のステップ数を計測し、それに見合ったテストケースを
提示するのはそれほど困難ではないと思うのですね。テストケースは
どうにでも細分化できますから。

ところが、予想と実績をあわせろ、っていうのに困ってます。現在の
ところ、見積り額との辻褄までは言われてませんが、そのうち言って
くるかも知れません。

思い付くのは、意味の無いクラスを突っ込んで数あわせすることぐらい
ですね。

>>25>>26
ちょっと私自身の考え方を書いてないのがよくないかと思ってきたので
書いてみます。

>>25に記述されているようなことは、私も賛成で、基本的に私は現状の
システム開発を定量的に測定することは不可能だと考えます。理由は
単純で、システム開発が他の製造業などと比較すると、原始的、言い
替えれば個々人の能力に依存した業種だからです。

じゃあ、見積はどうするか？というと、要求仕様から必要な機能を一覧に
して、各機能の各工程を出し、それぞれ経験から工数を積み上げていき、
一応、必要工数というものを自分なりには出しますが、それは見積り金額
とは直接リンクしないというのが私の考えです。要するに価格というのは
出来上がったモノに対して、客がいくら支払うだろうか？という営業的な
問題だと思います。

要するにシステム開発で定量的に測定するものは全てインチキである。
ただ、定量的にしないとカッコがつかないのでやっているだけ、という
ことですね。そこで、数値の辻褄合わせが発生するわけですが、どうせ
何の役にも立たない、単なる体裁を整えることならば、上手に回避して
買い手/売り手双方が頷きあう方法を探りたい。そういうことです。

お偉いさんというものは仕事のための仕事をこさえるものだよ。
それがプロジェクトにとって有益かどうかなど関係ないのだ。

>>29
わかります。なので、手軽な回避方法を考えたいわけですね。私が
思い付くのは、

・意味の全く無いクラスを指定行数で吐き出すマクロを作る。

というぐらいですかね。これ、実際にやったかたいらっしゃいますか？

素朴な疑問なんだけど、

予想テスト件数と実績テスト件数、
バグ予想件数とバグの件数

結果的にこれらの差が大きかった場合になんか問題あるの？
今度は予想が食い違った原因を究明して報告しろとか言ってくんのかな？
細かい単位のイティレーションではまだしも、最初からシステム全体の
なんてどう考えても正確にはだせないよなぁ。人間業じゃないよ。
もし出すとしたら、

・仕様が凍結されていること
・その仕様と非常に類似した同一環境、同一言語、技術ベースの既存システムがあり、そのステップ数と機能比較可能な資料があること

が最低条件かなぁ。じゃないと俺には無理だな。それこそ職人の勘頼りの
おおざっぱなものしかだせない。

>>31
> 結果的にこれらの差が大きかった場合になんか問題あるの？

ありますね。多分、その理由を報告しろとか面倒なことになります。

相手はどことは言いませんが、よくあるシステム子会社、やっていることはITゼネコンです。
基本的にシステムのことは全く分からないですし、ユーザーサイドの業務についても全く
知りません。完全丸投げですね。

ですので、ユーザーサイドから「何しているの？」と聞かれたときに答える資料が
欲しいわけですが、それがコード行数とテスト件数、というか、それ以外はできない
のです。他にもアナライズする方法は色々ありますが、彼らはその名前すら
知りませんからねw。

私としては、彼らとのやりとりを極限まで減らしたい、つまり、実質いないのと同じ
状況まで持っていきたいわけです。ま、コード放りこんで奴らの必要情報を提示し、
且つ、コード自体も辻褄をあわせるように改編する、っていうのを目指してます。

>>1
基本的な認識が違う。判っていると思うが再確認。
予想ステップ数
　なんの役に立つか。見積もり時の工数積算にしか役に立たない。
　それも「開発工数はステップ数に比例する」という前提が成立していればの話だ
ステップ数からの予想テスト件数
　テスト件数の予想は少なくとも仕様の定量化が出来ないと不可能だ。
　仕様の定量化を行うには「ステップ数を基にすることが正しい」という前提がないと成り立たない
実績テスト件数
　これも仕様の定量化
バグ予想件数
　「バグ数はステップ数に比例する」という前提が必要だ
バグの件数
　これも「バグ数はステップ数に比例する」という前提が必要
　#しかしながらバグの件数はメトリクス値として最重要

沢山書かれた「前提」そのものがどれひとつとして正しくない。だが、
ステップ数マニアにとって定量化の全ての基盤はステップ数なのだ。
御愁傷様。
貴方はその顧客に対する役に立たない情報を報告する義務があるようだね。
進捗報告と品質計測の一環として。
回避の方法？自分はお役には立てないよ

予想テスト件数ってのも激しく意味不明なんだが(´・ω・`)
テスト件数って仕様の種類(ブラックボックス)+分岐の数(ホワイトボックス)で
出る訳だから、実績のみあれば十分じゃね？
テスト工数見積もり用データとかに使う？

そういえば、オブジェクト指向で有名wな某Oへ面接行った時に
時間辺りのステップ数聞かれたな。
いくらでも増やせます♪って答えといた(ﾟ∀ﾟ)
営業が必死でフォローしてたがなwww

おまいらそうは言うがなあ。
ソフトウェアの規模をさっくり表す指標としてはなんだかんだで
行数・ステップ数が使いやすいと思うぞ。第ゼロ近似くらいにはなる。
規模の計測や工数の予想を一応仮にもやらなきゃならないなら
そんな感じでやるしかないじゃん。
ステップ数がいやならファンクションポイントなりなんなりで
きちんとやってみてくれ。

その分の工数くれるんならやりまんがな
それと正確にはだせないよ。前後50%ぐらいのブレは大目に見てくれ。

ソフトウェアの規模をさっくり表す指標としては
ステップ数より仕様書の文字数のほうがまだマシ

いっそオブジェクトコードのバイト数でどうだろ。
コメント関係なくなるしいいじゃん。

見積もりが無理だ。

そうだな、掛ける10 するところを、足し算10回して膨らませるか

色々御意見ありがとうございます。

やはり現場サイドの人間としては、ステップ数に拘るのは下らないというのは
共通認識、常識だろうと思います。ただ、自分がここで考えたいのは、意味は
無いが、それしか親会社、或は上位部署に自分達が提示するネタがない人々
にいかに関わっていくか、という点です。

つまり、自分としては、そういう人々を真正面から考えを改めるよう説得するなど
ということは微塵も考えてません。そういう人々はそういう人々で勝手に間違った
発想で仕事してもらって構わない。但し、こちらがその影響で害を被るのを極限
まで避けたいということです。

ちなみに、現状私が出している「ステップ予想」と「テスト予想」の出しかたですが、単純に
同様のシステムでの過去の実績値から出してます。例えば、ある程度まとまった機能を
持つ画面を新規で作成した場合にどれぐらいのステップ数が追加されているか。或は、
既存機能で一部見直しをした場合に、どれぐらいステップ数の変更が発生したか、その
過去実績から概算で出してます。

ただ、これは当然結果として全く違う数値になる可能性がありますので、辻褄合わせが
必要ですので、上にどなたか書いているように、不要なプログラムコードを追加するなど
をしようと思ってます。

>>32,41
理不尽な相手を説得するか、システム側を直してつじつま合わせるか。
後者を選ぶのは了見が間違ってると思うがなあ。
どうしてもそうするというのなら勝手にすれば？

実績を予想に無理矢理合わせることがまかり通ったら、
その時点で「予想」の意味がないじゃないか。
過去の実績も「予想」に合わせて調整された値かもしれん。

>>43
ステップ予想がそもそも現状にそぐわない無意味な手法なんだか
らいいんだよ。
「理不尽な相手を説得」するために不毛な時間を費やしたくない
って>>1は言ってるじゃん。神様には適当に愛想ふっとけばいいん
だよ。

問題は二つ。

(1)ソフトウェアの規模の指標としてステップ数を使うことの是非
　規模の測定が本質的に不可能だというなら、だったら逆に行数でもいいじゃん。

(2)実績が予想と食い違ったときに誤魔化すか説明するか
　ここで誤魔化すべきじゃない。正直が最良の戦略のはずだ。
政治的な問題でシステム実装におかしな要素が入るなんて駄目だろ。
実績と予想が食い違う->その理由はこれこれ、を何回か繰り返せば
「ああ、そういうものなのか」とじきに慣れて文句言わなくなる。

>>45
> 　規模の測定が本質的に不可能だというなら、だったら逆に行数でもいいじゃん。

不可能なら行数、というのなら、最初から出さなければいいだけですね、本当は。逆に行数を
規模測定の値として、それが意味の無いものだという注釈付きだとしても、出してしまうという
のは面倒なことになります。

これは次のことにつながります。

> 実績と予想が食い違う->その理由はこれこれ、を何回か繰り返せば
> 「ああ、そういうものなのか」とじきに慣れて文句言わなくなる。

このことは、ステップ数を出せと言っているゼネコン企業の担当は分かっている、というか、何も
分からないというかｗ。つまり、ステップ数が意味があるか無いかは、彼らにとっては最初から
どうでもいいのです。どうでもいいが、金を支払うユーザーに対して、規模の根拠を何も示せない
のでは示しがつかない、だからやっているということです。

そして、出してしまうならば、その数値が適当です、なんてことはいくらトンネル企業でも言えませんよ。
なので、彼らとしては、自分たちが知らないところで勝手につじつま合わせをしてもらえればよろしい、
そう考えているはずです。

結局、見積り面倒だから全部>>1に投げてるような感じか？

意味はあるが価値はない。

>>1
お前は、プログラムを
作る人なの？
作らせる人なの？
どっち？

少しでも気を引きたい
純情な乙女心

>>50
ﾜﾛｽ

開発する時の複雑さを表しているとは思えないが、
メンテする時の複雑さとは関係が有ると思うな。
特に、ドキュメントが無いときには。

ところで、ファンクションポイントって、本当に使っているところあるの？

っていうか、「ファンクションポイント」でググってみると
結構な数の HP が引っかかる癖に、
不思議なことに、そのどのページもが
肝心の「具体的な計測方法・測定例」を記述していないんですが・・・

「日本ファンクションポイントユーザ会」なんていう
ご大層な名前のページですら同様の状況だし。

もしかしてこれ、「鮫島事件」みたいなものなの？

書籍でてるよ。
そもそもFPの計測まではまあ出来る。
ただ、それと工数との紐付けが、各企業なりで蓄積・評価するノウハウになるから、結局即使えるわけじゃない。

規模を測るには、FPとかオブジェクトP法とかがステップより合ってる。

ステップなんぞ、過去の遺物。技術者が限定されていて、言語が少なかった時代なら、スキルも記述形式も均一だから出来たこと。

俺、リーマン時代からフリーの今まで、コード行数の統計取ってるけど
（もちろん見積りのデータになどしない）
コードを誠実に書いて、シェイプアップもちゃんとやって、なら工数や複雑さの指標としては
有効だと思うけどなあ。客先からはＸＸさんの作るコードは小さいがそのつもりで他所に出すと
エラくでかいのが出てくるとか言われる。実際石のダウングレードこちらから提案とかもあった。

>>55

ある同じ人が書くコードの評価としては参考になるが、いろいろな人の
同じステップ数のコードの比較とは違うってことかな。

まあそういうことかな。そんでコードの水増しが横行した結果、
「大きさは\の額に関する評価は対象外」ってのが定着してるから、
一般的な働き方としては「一度しか書かない」ことが殆どでしょ。
これで品質の良いコードが書けるのかと常々思ってる。
いろんな書き方があったらそれらを比較して、性能・リーダビリティ・短さなど何らかの基準で
評価・取捨選択して用いるぐらいのことしなきゃいいもの作れないと思うんだけど、
今の作業標準ってそういう働き方は「工数の無駄」にしかならないんだよね。

仕様がコーディングの段階で完全に固まってたりデバッグが自分の仕事じゃなかったりするなら
一度しか書かないつもりで思う存分に書き散らせる気がする。
だが現実にそううまい話はないため自己防衛策としていろいろ工夫しないとね。

俺なんか、製品になるのが5K行としたら15K行は書いてるな。
文章に関しては潤一郎あたりが言ってるけど、コードでも同じだと思う。
シェイプアップした姿は美しいが、贅肉ついた姿は醜い。

価値あるコードはステップ数も多い。
ゴミコードはステップ数も少ない。

なんでこんな当たり前のことに疑問を抱く奴がいるのかわからん。

増やすのが簡単で減らすのが難しいのは体重と同じか

>>60
こんな
ttp://www.gnu.org/fun/jokes/helloworld.html

>>62
>Senior Manager
> % zmail jim
> I need a "Hello, world." program by this afternoon.
ﾜﾗﾀ

>>62
CUIだとメールも出せない最高責任者、ｶﾜｲｿｽ・・・

まぁ何かしら予想しないと見積もり出来ないわけで、そこはさておきとして以下私見。

・予想ステップ数と現在のステップ数の比較
まぁ現在の進捗率を表すのには有効かもしれない。

・予想テスト件数とテスト件数の比較
何これ。
意味が分からない・・・。

・予想バグ件数とバグ件数の比較
品質管理の観点から良くやる。
信頼度曲線とか。
予想バグ件数はテストしてくと変わって行くけどね。

予想テスト件数と予想バグ件数を予想ソースコード量から出すのはナンセンスだと思う。
さらに、予想と実績を無理矢理合わせるなんて無駄以外の何物でもない。

客先が納得するような「〜〜の結果、コード量が削減出来ました」
とかいう理由捻り出す方が良いんじゃない？

>>62
Chief Executive

% letter
letter: Command not found.
% mail
To: ^X ^F ^C
% help mail
help: Command not found.
% damn!
!: Event unrecognized
% logout


くそわろたｗｗ

ブックマークにいれたよwwwwwwww