工数出し直してースケジュール策定のための再見積もりー

きっかけ

お客様から、以前見積もり依頼をした案件について、着手してほしいと要請がありました。
もともとの見積もりは２、３年前に出したものだったので、メンバや開発の進め方の変更もあり、当時の工数で開発できるのか保証がなかったため、再見積もりを行うことになりました。

作業内容

見積もりに記載された改修内容については当時のものを信頼する形で、それに必要な工数の算出に着目して作業を行いまいした。
このプロジェクトの開発工程にしたがってWBSを作成し、それぞれに必要な作業時間、作業者の人数を割り当て、工数に換算していきました。
作業時間についてはこれまでの仕様変更で自分がどれだけの時間を要してきたかをベースに算出し、さらに有識者の意見から難易度や試験環境の制約などを加味して増減を行いました。

課題

この案件では、着手後に見積もりで想定していなかった事象が発生しました。
できると思っていたことができなかったのです。
ベテランSEによる方式検討結果からの見積もりだったので、そのようなことになるとは想像さえしておらず、少々戸惑いました。
どういう状況であれ、できると思っていたことができなかったというのはいくらかの可能性で発生することなのかもしれません。
しかし今回は事前に調査することで把握することのできる事象だったので、私が再見積もりを行う段階で、方式についても再検討を行うべきだったのではないかと悩みました。
時間の制約もあるなかで、どこまでやるのか、何を洗い出しておくべきかというところは今後も考えていきたいところです。

改修にどれくらいかかる？ー故障改修見積もりー

きっかけ

お客様からいただいたごく小規模な案件の試験工程で既存故障が検出されたため、改修にどれくらいの時間が必要なのか、見積もり依頼がありました。

作業内容

このプロジェクトではLOCをベースに開発効率や規模を算出しているため、具体的にステップ数を算出する必要がありました(正確に言うと、私の中ではそういう認識でした)。
ステップ数の算出を行うために、変更後の関数を使用してざっくりとコードを書き、そこからステップ数の算出を行いました。

実際に書いたコードから算出してみて、結果としてはその作業は必要ではなかったかなと思いました。
例えば別のアプローチとして、この案件では使用している関数の変更を行うため、変更後の関数を使用しているモジュールを参照して、そのモジュールで関数に使用しているステップ数を計算すればよかったかもしれません。
立て続けに見積もりを行っていて疲れたので、コーディングが楽しくなってしまったのかもしれないです 笑

レビュー

試験観点が不明確であると指摘されました。
また、試験内容の記載は、見積書を見て試験項目書が書けるくらいのレベルで記載すべきだと言われました。
これについては「試験項目書が書けるレベル」というのが私の中では曖昧な状態です。
どんなインプットがあれば試験項目書が起こせるのか、そのあたりの理解が足りないのかもしれません。
ここで言う「試験項目書」とは、受け入れ試験で起こすような業務シナリオのイメージだったのかなと、あとで振り返ってみると思います。

こうして内部レビューを受け、指摘事項を反映させた見積書は「見積書の作成に時間をかけすぎ」とプロジェクトマネージャから評価されました。
そう言われてみると、要点を得ない不要な記述が多いように思えました。
無駄なくスマートにまとめるにはシステムのことはもちろん、業務の理解が必須であることを感じ、今の自分にはそれが不足していることを痛感しました。
業務シナリオが想像できなければ要点を絞った試験内容の記述は難しいと思うのです。
また、試験については試験しすぎ、との指摘がありました。
確かに「故障改修箇所を確認する」という目的からすると不要な試験が多いように見えました。
それまで仕様変更案件ばかりを担当してきた私には「故障」への対応と「仕様変更」への対応とが異なるという認識が全くありませんでした。

これやったら工数いくつ？ー具体的な要求から見積もるー

きっかけ

お客様から具体的な要件の提示と見積もり依頼がありました。

作業内容

仕様変更内容シェル内でのソート順を変更するというもので、要件が明確だったので、改修規模についてはすぐに把握できました。
改修をすることによってどのような影響があるかについては検討がつかず、有識者の意見を参考にあたりをつけ、調査を進めていきました。
懸念事項がいくつかあったので、それを説明する材料を洗い出していきました。
まず該当する範囲をモジュール単位、ジョブフロー単位で抽出し、そこからさらにソース、ファイルレイアウト単位でどのような影響が考えられるのか、に対する答えを揃えていきました。

レビュー

改修箇所は他のモジュールに影響を与えるような内容ではなかったため、どこまで試験をするか、が論点になりました。
改修範囲と試験内容についてはこのシステムだったらどうすべきなのか、整理が必要だと思いました。
一般的に試験工程別に定義される試験内容に沿って試験を想定するのはもちろんですが、そこからさらに一歩踏み込んだところとなると、システムの特性や業務内容を加味していかなければ見積書としては完成させられないのではないかと思いました。

最終的にこうしたいので宜しくー漠然とした要求から見積もるー

きっかけ

お客様からざっくりとした要件の提示と見積もり依頼がありました。

作業内容

いつ、何をしたいのかというような具体的な業務イメージもまだなく、実現したい最終的な形だけをお客様から提示していただいた状態で見積もり依頼をいただきました。
つまり業務フローから考えていく必要のある案件でした。
まず、どうしたいのかというお客様の要件の理解ができなかったため、有識者から説明を受け、大枠を理解しました。
有識者の頭の中にはざっくりとした改修案がありましたが、その意図はあまり理解できなかったので、案の実現に必要な要素(DBレイアウト、業務フロー、他サブシステムへのインターフェース仕様など)を揃えながら、曖昧だった疑問点を明確にしていきました。
明確になってきた疑問点について有識者に改めて質問し、自分なりの考えを提案しました。
疑問点を洗いだしてから質問、提案をすることで、各々の改修案のメリット・デメリット、影響範囲、影響箇所への対処方法など具体的なところまでどんどん話が広がっていきました。

開発規模については既存の似たような機能をもつモジュールからステップ数を算出し、工数についてはプロジェクト内で使用されているステップ数に対する工数の目安マトリクスを使用し、換算ました。

レビュー

この案件はまだ見積もり第一弾、という位置づけで、お客様としては「こんなことしたいんだけどどれくらいお金がかかるのかな〜」というレベルのものでした。
それに対して、私が出した見積もりの内容は細かすぎると指摘がありました。
もっとざっくり、だいたいこれくらいの工数がかかりますよ〜ということが分かればよかったのです。
開発規模の見積についても、100Step単位で算出してくれればいいし、改修内容の細かいところについてもまだ今の段階では不要で、もうひとつ上位のレベルで検討して欲しいと言われました。
しかしこのレベルまで検討が出来ているなら、メリット・デメリットを明確にして、改修内容のレベルに応じて改修案を２つ提案してもよいかもしれないとも言われました。

確かに、おおよその工数を知るには細かすぎる見積もりだったかもしれません。
しかしそのレベルの粒度で考えていなければ、私には工数の算出ができなかったようにも思います。
感覚的にこの画面数ならこれくらいだとか、このバッチ処理ならこれくらいだろうなとか、そういう経験ベースのものさしは私にはないのです。

振り返ってみればわかりますが、見積もり着手時点でリーダーやプロマネからどれくらいのことを要求されているのかははっきりとわかっていなかったと思います。
どのくらいの成果物を出せばよいのか、そのさじ加減を決めるにはある程度の経験が必要な気もしました(「さじ加減がわからない」という私に、リーダーは「この業界、明確な根拠や理論も必要だけど、感覚って結構大事だよ」というコメントをくれました)。
また、「もうひとつ上位のレベルで記載」というのは当然、雑な仕事をしていいというわけではなくて、その程度の粗さでいいよということだと解釈しています。
要点を、要求レベルに合わせてアウトプットしていくことの難しさを感じました。

JSTQB認定テスト技術者資格

2012年2月に受けた資格試験について、紹介したいと思います。
私が取得したのはJapan Software Testing Qualifications Boardという組織が認定するテスト技術者の資格です。
レベルが2段階、Foundation Level(FL)とAdvanced Level(AL)とがあります。

JSTQBのサイト
http://jstqb.jp/

私が受けたのはFLの方で、ソフトウェアテストの基礎知識を問うものです。
内容は
・用語の定義
・テスト技法の名称、内容（いつどんなテストにそれを使うか）
・単体テスト、結合テストなど、テストのフェーズによってどのような観点が必要か、目的は何か
・レビュー（静的技法）
など。

受けようと思ったきっかけは、前のプロジェクトで受け入れ試験をすることになったところから始まります。
「テスト」ってどんなふうに考えたらいいんだろう？と思いながら本屋さんを覗いていて、とてもわかりやすくまとめてあったのがこのJSTQBの本でした。




目前の問題解決ができればよかったはずが、読むうちにどんどん興味がわき、資格取得に至りました。
別にテスターでなくても、テストのことを考えらるというのは大事だと思っています。
どう設計するか、どういうロジックで問題を解決するか、どんなドキュメントを残すか…
テストの観点からテスト以前のフェーズについてもアプローチを取ることができると、テストというミクロな世界から、開発効率やシステム全体の品質というマクロなところまでカバーできてしまうのではないかという淡い考察を抱いているところです。

テンションを上げるためのCording

最近はSEらしい仕事を試行錯誤しながら、リーダーに色々と指導されながらこなしている。
そうすると頭の中が日中の仕事のことでいっぱいになって、眠ろうにも眠れない。
ぼーっとしてるといつの間にか仕事のことを考えている。

これじゃいかん！
というわけで気持ちを切り替えるために仕事とは全く関係の無いCordingをすることにした。
題材はRuby。

で、早速今日からスタートし、とりあえずFizzBuzzを書いた。


# RubyでFizzBuzzをかいてみよう！
# 3の倍数でFizz 5の倍数でBuzz 15の倍数でFizzBuzzね


for num1 in 1 .. 55 do
    if num1 % 15 == 0 then
        print(num1)
        print("  ")
        puts("FizzBuzz")
    end


    if num1 % 5 == 0 then
        print(num1)
        print("  ")
        puts("Buzz")
    end
    
    if num1 % 3 == 0 then
        print(num1)
        print("  ")
        puts("Fizz")
    end
end

こんな感じ。
今までやってきた言語（といっても数少ないｗ）だと「else if」で条件をさらに指定できていたのだけど、そういうふうにはかけなかった。
endが足りないよ！って怒られるのだ。
まだ始めたばかりでよくわかっていないけど、条件文1つずつに対してendが必要？

・・・そんな感じで仕事のことを忘れてちょっと没頭できるので楽しい。
とりあえず、何か動くものを作るのを目標に、ちょいちょいやっていこうかなと思う。

やっぱりCordingは楽しいのだ。

作りたい、だったら作ればいい〜iPhoneアプリ製作を始めました〜

やりたいやりたいと思っていたiPhoneアプリの開発をやってみることにしました。
始めないことには何も進展しない！ということでXcodeをダウンロードし、インストール。
本屋さんで物色してほしい物リストに入れていた本をAmazonで購入し、最初の画面が出来上がりました。

実際に動かしてみると「私、iPhoneアプリデベロッパの仲間入りしようとしてる！」という単純な事実がとても嬉しくて、わくわくして、この気持ちをいつかまた思い出したいと思い、この記事を書きました。

Start
本に書いてあったようにテンプレートを使って新規プロジェクを作成し、画面にラベルを配置して文字を入力し、シミュレータで再生しました。
はい、Hello worldの出来上がり。

素晴らしい！(ここまでは開発らしいことは何もしていません 笑)
でもiPhoneアプリ開発の入り口が簡単だとわかったのは実際にやってみたからだなと思います。
10日でできるアプリ開発入門、というような見出しはよくみかけますが、実際はそんなに簡単に出来ないだろうと思っていました。
まだまだ本当に入り口に立っただけですが、こんなに簡単にアプリ開発の入り口を見せてもらえたことは次の作業への動力になりました。

きっかけ
AndroidかiPhoneか、どちらでもいいから自分でアプリを作ってみたいなという考えはしばらく前からずっとありました。
単純にアプリケーションを作りたい、という気持ちです。
もともとモノを作ることは好きで、今はソフトウェア業界で仕事をしているので、それなら作るのはソフトだなと思うわけです。
それにTwitterでみかけるデベロッパさんのつぶやきを、同じように自分もやりたいという気持ちもありました。
この仕様をどうしようかとか、ここのバグがどうしても解消できないとか、リリースしました！！というツイートが出来ることがかっこ良く見えるのです 笑
また、身近にもiPhoneやAndroidのアプリを開発している人がいらっしゃり、そういう人たちから直接話しを聞くことで大いに刺激されました。

さて、何をつくるか
では何をつくろうかという話になるわけですが、そこはやはり自分が使って便利だと思えるものを作りたいです。
とにかく作りたいから、簡単で動かせるものにしようかとか、お世話になっている人のお仕事をお手伝いできるようなものにしようかとか色々考えましたが、自分の為に開発するという答えに落ち着きました。
要件を詰めるのも、アイディアを出すのも、折り合いをつけるのも、自分が欲しいものだったら自分と相談すればいいだけですしね。

ちなみにこのアイディアを出すにあたっては前回の記事に書いた3回3ラウンドのフレームワークを使いました。
「アイディア創造のフレームワーク」
作りたいな、こんなのどうかな？というネタをとにかく吐き出して、整理して練りあげてはまた吐き出すという作業の繰り返し。
でもそれをすることで作りたいアプリの要件が具体的に想像できるようになりました。

目標
自分が使いたいアプリの構想は結構具体的になってきました。
とりあえずはその構想の30％くらいを実現させるつもりで作ります。
起動して、ワークスペースとなる１画面が表示されて、終了！っていう一連の処理ができること、それが第一段階の目標です。
そこから第二段階、第三段階…というように成長させていけたらいいなと思います。
ここまでくると夢のようです。
でもやればできる、夢が現実になる、そう思って頑張ります。