スポンサーサイト

上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。

証明写真

証明写真が必要になったが駅前にあるスピード写真機は700円もかかり、高すぎる。
デジカメプリントができれば安くできるだろうと思って探した。
よくCMでやっているフジカラーはどうかというと証明写真はやっていないようだった。コンビニでならどこでもやっているかと言うと、即その場でというわけではなさそう。
セブンイレブンでやっていることがわかり、xDピクチャーカードを持ってGO。200円で、1シートに4枚できるので、かなり安上がり。画面上で写真を選び、顔のサイズ・位置を微調整できる。画質も証明写真でなら全く問題ない。
スポンサーサイト

見積りについて2 (5つの作業世界)

前回、見積りについて、FP法による規模見積り、見かけ上の側面、営業的な側面について考察してみたが、今回は、個々の機能実現にあたってかかる工数について検討してみたい。
見積りには、タイムとコストとあるが、コストはおよそタイム(時間)×リソース単価(スキル単価)に比例する。
ここでは主に、作業にかかる時間について検討してみる。思うに、プログラミング(および設定・構築作業)は次の5つの世界に分類され、それぞれが時間見積りに影響する。

1 力仕事の世界
2 アルゴリズム・ロジックの世界
3 学習を必要とする世界
4 ブラックボックスとの結合の世界
5. 想定外の世界

1 力仕事の世界
 時間に比例して成果が進む世界である。決められた手順で、ソースコードを組み立てて行けば、成果物が完成する。単純な入れポン出しポンのアプリケーションで、フレームワークが確立している場合はこのパターンになる。力仕事なので、キー入力の速さがポイントになる。能力がある人でも一定の時間がかかる。とはいえ、能力のある人はこういうところでも工夫して、コピペ、置換、マクロ、sed、awk等を駆使して、素早く進めることができる。
 もっともこういう部分はもともとインテリジェントな部分がないので、ソースコードの自動生成や共通化等で、作業やソースコードを減らせるはずの部分でもある。IDEの標準の機能でも、この部分の工数をかなり削減できる。
 この世界は、きちんと手順が確立されていれば、人海戦術が通用する世界である。

2 アルゴリズム・ロジックの世界
 時間に比例して成果が出るとは限らない世界である。
 技術はすべて自分の手の内にある。それをどう組み立てるかである。関数内のアルゴリズムからクラス構成にまで及び、最も当人の創造性が発揮されるところでもある。
 そこでのバグや矛盾はすべて自分の責任となる。ここは、能力のあるなしで時間に差が出る。能力が低い場合、全く結果が出ないか、出てもバグを多量に含んでいて使い物にならない。
 ここは仕様がどの程度複雑かで見積もることができるが、詳細までブレークダウンしないと、本当の複雑さが見えてこない場合が多い。そしてそれは実装時に発覚することも多い。
 例えば何かのデータセットを別の場所にあるデータと同期をとるという場合、言葉にしてしまえば一言だが、実際に検討しだすと、物凄く複雑になる。過去に経験があればある程度規模はわかるが、なければ必ず過つ。

3 学習を必要とする世界
 2の世界においては、すべてのアルゴリズムを自前で組むか、既存のライブラリを使うのかで工数は違ってくる。ライブラリに対する知識によって差が出てくる世界だる。知っていれば自前で組む必要がないので時間は一気に短縮する。
 ここではライブラリを学ぶ時間を見積もっておく必要がある。学習時間を見積もりに含めてよいかどうかは難しい。スケジュール的に見れば、すでに知っている人間をそろえればその期間は不要だし、またコスト的に見て、発注側からすればそういうことを熟知している人間が作るのが当たり前ともいえる。もっともコストについては学習済みの人は単価が高くなるから同じといえば同じだが。
 例えば、strutsを初めてやるとなると、学習時間が必要だが、strutsぐらい一般的になっている技術を学ぶ時間をコストにのせていいかどうかである。
 とはいえ、技術の進展が激しく、様々な技術が混在している昨今では全く勉強無しに済まされるプロジェクトなどほとんどない。何らか新しいものが必ず出てくる。

 ここは創造力のない人間でも知識さえ積み上げれば勝てる世界である。知っているか知っていないかという、ただそれだけのこの世界で威張っている人間が世の中いかに多いことか(悲)。

4 ブラックボックスとの結合の世界
 時間がどれだけかかるか読みづらい世界である。
 他人の作ったライブラリ・フレームワーク・製品を使用する。その中身を知らなければ使いこなすことはできない。枯れている技術でない限り、全くのブラックボックス状態である。どんな問題が潜んでいるかわからない。枯れている技術でも、典型的ではない、使い方をするときブラックボックスとなる。またバージョンアップで使い方が変わればその部分でブラックボックス化する。
 なお、十分に枯れて使い方がはっきりとしていて学ぶことができるのは、3の世界に属する。
 このとき頼れるのは、ドキュメント、ソースコード、トラブルシューティングノウハウ(過去のメーリングリスト・掲示板・個人のブログ)となる。
 ここをどれだけ時間をかけずに通過できるかは、そのライブラリや製品の成熟度に依存する。
 例えば、DBでMysqlとOracleがあった場合、Oracleの方がノウハウは充実している(Mysqlもかなり充実してきたが)。
 しかしそういうことはやってみるまでわからない。いいライブラリだと思って使ってみたら、あまり使えないことが判明したり、使いこなすには膨大な時間がかかり、結局自分で一から作るのと時間的には変わらなかったり、余計に時間がかかったりする。
 逆に、問題なく、まさにほしい機能が、数行のソースコードを書くだけで済んだりもする。この場合は実装しようとしていた時間をそれだけでスキップできてしまう。作ろうと思っていたものがすでにあるのだから当然である。これでこの部分の機能の作りこみの代金をもらうのはいささか詐欺っぽい気もするが、全体としてみると、こういうケースは少なく、むしろ、そのライブラリを取り込み、インテグレーションを行うのに膨大な時間を要するのが普通である。
 
 正直、一番辛く、うんざりするのがこの世界でもある。私もSEをやめたくなる一番はここである。訳のわからないエラーメッセージと格闘して、解決するのに数時間、場合によっては丸一日かけても解決しない場合がある。Googleで検索しても解決策が見つからない、あれこれ試行錯誤を繰り返す。ブラックボックスに対してあの手この手でアプローチする。一回の試行錯誤にかかる時間が長いとそれだけ解決の時間も長くなる。

 半日、一日とかけて解決できないとき、見かけ上の生産性は0である。時間をかければ成果が出る1の世界に比べ、ここは散々時間をかけた挙句、実現できたことは微々たるものだったりする。あるいは時間をかけた挙句不可能だと判明したりする。早々に迂回策をやってしまった方がよい場合もある。また知っている人に聞けば一瞬で解決することもある。
 こういうところが多ければ多いほどプロジェクトの遅延を招く。
 知っている人に聞く、という点では、人的ネットワークやそういう体制も重要だ。とはいえ、何でも教えて君では敬遠される。また、効果的な質問をするには、プロジェクトの特殊な背景から一般的な背景に変えて、理解できる質問にする必要がある。ここが結構面倒だったりする。
 
 果たして試行錯誤は見積もりに含められるのか。スケジュールの見積りでは含める必要がある。ただ程度がわからないのが問題だが。コストについては難しい。既存の技術の場合、熟知していれば試行錯誤はないはずだからである。
 
 ただここは効率を高める工夫をすることで、時間を短縮することはできる。トラブルシューティングマニュアルを使い勝手よく作っておくことだ。問題が起きたとき、以前にも同様の問題がなかったか振り返るようにする。
  
 また、この領域を専門に扱うSEもいる。コードはスクリプト程度しか書かず、もっぱら他社製品の評価、インテグレーションを行う人たちである。この人たちは、設定をあれこれいじくり回して、製品と格闘する。
 
 製品を使いこなすとは、そこで発生する様々な問題へのノウハウを熟知することであり、それが技術力の証となったりする。
 しかし、私はここに矛盾を感じる。その製品と格闘しなければならないのは、その製品が未成熟だからだ。わかりにくい構造をとっていたり、腫れ物に触るようにうまくいじらないとすぐに泣き出す製品が多すぎるのだ。
 エラーメッセージは、エラーの本当の原因を示してくれないことが多い。手がかりを与えてくれるだけ。書いてあることを真に受けるとそれが真相究明の妨げになることもある。エラーメッセージの充実度・正確性が、そのライブラリやフレームワークの完成度でもあると思うが、そういうメトリックスは世の中にはないのが残念だ。
 とはいえ、これはライブラリのバグに違いないと決め付けていたら、自分の些細なミスだったりして、それを口に出してしまった日には結構恥ずかしい思いをする。メーリングリストとかに投げなくてよかったと思う。

 製品の未成熟度の話になると、Oracleで以前ロールバックセグメントなるものがあって、そのチューニングは一つのノウハウであり、それを知っていることは技術力の証明だった。が、後のバージョンでundoセグメントとなり、基本的に自動的にチューニング可能となった。そうするとその技術力は一体なんだったのだろうか。
 こういうことは他のサーバ製品でもよくある。

 もっとも、トラブルに対して、方法を駆使して解決するのも一つの大きな能力であるから、そういう意味では技術力といえる。
 
 世界をいろいろ分けてきたが、どの世界に分類されるか難しい場合もある。作成しているアプリケーションの結合、システムテストフェーズになって見つかる問題点への対応は、仮に2で起きている問題であっても、4のパターンに近くなる。簡単に問題を切り分けられるようなつくりにしておく必要がある。
 
・条件付の見積り
 この4の世界の見積りを考える場合、やってみないとわからないところだから正確なものは難しい。
 こういうことができれば、この部分はこれだけの工数で済む。しかし、それができるかどうかわからない。といった、条件付の見積りになるだろう。

5. 想定外の世界
 これは、作業見積りに漏れてしまった世界である。
 これは独立した世界としていいかどうか迷う。2や4にも登場する。2の世界で、実装あるいはテスト段階になって、様々なケースがあることが判明するのは、設計ミスである。
 異常系を考えていない。他システムが常に正常稼動していることを当然の前提としている、なども含む。仕様から漏らしてはいけないものが漏れている。
 ユーザの片言に含まれる、暗黙的仕様もある。
 これをどっちが責任を取るのかは難しい。日本では開発側が責任を取らされる。インドであれば仕様にないと突っぱねるだろう。
 もしきちんとやるのであればシステムの前提条件として、明確に定義しておく必要がある。
 とはいえ、細かいレベルまでは、概算見積りの段階では掘り下げられない。
 PMPでは段階的詳細化というように、詳細設計まで踏み込まない限り正確な見積りなどできない。ところが現実では、概要レベルでしかない要件定義で正確な見積りを要求される。
 仮に完璧な詳細設計ができて仕様が完璧に明確になったとしても、4の問題は避けられない。特にホストの時代ではなく、様々な製品を組み合わせる環境にあっては。

 想定外は必ず発生するものだと捉えて、その分バッファとして積み増ししておく必要があるだろう。

テーマ : ソフトウェア開発
ジャンル : コンピュータ

ソフトウエア開発の見積りについて

見積りは簡単で正確にできるなんて言う人もいるが、私にとって、未だに不可解で難解なテーマでもある。

この間、デブサミで、Jacky氏の「私のコスト見積り20年史から~ファンクションポイントと共に~」を聞いてきた。
最初、ソフトウェア見積り・評価の難しさ について語られ、非常にうなずくところが多かった。90%=50%の法則というのは確かにその通り。90%できたと思っても、後から振り返ると実際には50%しかできていないというもの。バグは次から次へと出てくる。
プロジェクトの混乱の第一原因は、プロジェクトの規模の把握ミス。
ホストの時代では、やることも環境も同じようなものなので、経験者のカンというのはかなり正しかった。ところが、マルチベンダ/CSS化で、環境はそれぞれ異なり、初めてのことばかりという状況になった。こうなると、過去の経験だけでは推察できない。

といった展開で、FP法の推奨へとつながっていく。
ただFP法は、規模の把握だけで、実際の工数を算出してくれるわけではない。工数は実際の本数・行数が関係してくる。いわばFP法では、入出力×データで面積を出すことに当たり、工数はさらに縦軸に品質・非機能要件・複雑さを持った体積となる。
とはいえ、FP法はだれがやっても誤差は少ないので、規模把握に役立つという話。

前半は実際のプロジェクトの現場での問題列挙で、いちいち納得したが、後半はFP法の宣伝に終始した。

とはいえ、私にとって見積りが難しいなと思うのは、FP法による規模の把握よりも、その縦軸の部分が大きい。様々な技術的障壁があって、そこで余計な時間をとられるところである。ここについては別途改めて議論を展開したい。

また、人によって、見積りがまるで違うのも気になる。ここからはどちらかというと営業的な視点になるのだが。

これまで経験してわかったことは、人は自分が関与しないプロジェクトについては低い見積りを出す、ということである。
十分に経験あるSEですら、こんなのすぐに終わるでしょとか、1ヶ月あれば物凄くいいものが作れるとか言う。他人のことになると、あっさりと簡単に言う。ところがその人たちのプロジェクトを見ると十分な工数が見積もられている。
その一方、下請け会社とかに見積もらせると、たいがい想定以上の工数が出てくる。

以前、私が作ったアプリケーションを知人らに見せてどのくらいの工数を見積もるか聞いたところ、ほとんどが、私が実際にかけたよりも低い工数を言ってきた。これについては、自分の能力を否定されたような気がしてがっかりした。

ただ言えることは、見掛けは重要だということ。
見かけがしょぼいと実際にかかった工数では評価されない。
500万の工数をかけたアプリケーションも、50万でもいいからデザイナを使って見栄えを向上させれば、1000万でも十分通用する。
ところが、画面がしょぼければ、200万にも見られない。

画面がしょぼいくらいなら、ない方がいい。むしろない方が、バックグラウンドで高度なことをやってそうな感じがするため、高く評価されるかもしれない。

また、一見機能が貧弱でも、バックでは様々なケースに対応するような処理、異常系処理をほどこしていても表面には見えないので、全く評価対象にはならない。そのくせユーザは、ちょっとでもエラーが起きると大騒ぎするのだが。

名前がツールというだけで低く評価されてしまったこともある。フリーソフトで使われているような名前は使ってはならない。

これは、経験のあるほとんどのSEもそう見てしまう。なので、プログラミングの経験のないユーザはなおさらだ。

だから、見栄えに気を遣い、見積りの明細には、見かけ以外いかに工数がかかるか、技術的な難易度が高いかを列挙する必要があるだろう。何か一つ、一般的ではない用語が登場したら、それを過度に強調して難しく見せる必要もある。

こうやるのはいかにも詐欺的な感じだが、見掛けしかわからないバカにわからせるために必要なことだ。ユーザ企業は見かけよりも高いと感じたら、見かけで工数を見積もる別の企業に発注するだろうから。

見積りの際に重要なのは、非機能要件やWBSベースでの全作業を含めること、技術的なリスクを考慮することだが、見掛けでしか判断できない周りの雑音を消すことだろう。
自分がやったこともなく、詳細も知らないのに、ざっくりこのぐらいだという、経験あるSEの言う工数の2倍がおそらく正しい数字だと思う。
自分だったらこれぐらいのこと、これだけでできるなどと過信してはならないし、周りから能無しのレッテルが貼られることを恐れてはならない。

また、顧客の予算がないという言葉に恩情を持ってもいけない。予算がなければ機能を削るのみ。こんなんじゃ使い物にならないだろうから、この機能もサービスでつけてやれというのは危険である。非難を受け、地獄を見るのは自分である。よかれと思ってやったのに裏切られるかたちで返ってくる。

テーマ : ソフトウェア開発
ジャンル : コンピュータ

プロフィール

dayan

Author:dayan
小職は、SE(システムエンジニア)を専門としておりますが、技術的な情報を中心に、それ以外に経済関連の日記、たわいもない日記も載せていきます。
[公式HPもよろしく!]

天気予報

-天気予報コム- -FC2-
リンク
ブロとも申請フォーム

この人とブロともになる

カテゴリー
最近の記事
ブログ内検索
最近のコメント
最近のトラックバック
RSSフィード
月別アーカイブ


上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。