基本設計お客様レビュー

システム開発はなんとなくわかるけど、ちゃんとやったことはないからやってみたい。
・・・そんな思いを胸に転職し、プロジェクトに配属されて10ヶ月、気づけば私は基本設計書を片手に、お客様の前に座っていました。

「基本設計レビューでお客さんとこいってきて」
「え？は、はい」…何すればいいんだろ(・∀・;)

という状態だった私の基本設計レビューDone!!までのプロセスを振り返りたいと思います。

基本設計着手までの経緯

ことの発端はシステム開発の工数見積もりでした。
新規業務追加に伴うシステムの拡張要求があり、そのための仕様変更見積もりを行いました。

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


この見積もりを行った時点ではまだ受注するかどうかも曖昧な状態でしたが、結果的に受注が決定し、すぐに着手指示が出ました。

準備

見積もりを行った流れから私が基本設計を行うことになり、以下のドキュメントを作成しました。

• 業務フロー図
• 機能一覧
• 画面レイアウト
• 業務ルール定義書
• メッセージ一覧(詳細設計書だけど、想定できる部分について先に作成した。)

見積もりの段階で細かい調査を行っており、ほぼ基本設計に近い状態まで構想が描けていたこともあって、基本設計書の作成は思ったよりもスムーズに進みました。

逆に言うと見積もり時点で少し仕事をしすぎていたともとれますが、今回は結果オーライ。
着手指示から基本設計書の提示まで、初心者の私には短いと思われる期間しか与えられなかったため、見積もり時点で少々行き過ぎなまでに調査・検討を行っていたことがその後の工数を減らしてくれました。
結果、お客様へ提示するまでに必要な資料をすべて作成することができました。


お客様レビューに際し、どのようなことを考えておけばよいのか、自分だけの考えでは不安だったので、自社の有識者にアドバイスを求めました。

把握しておくこと

• 業務フローはどうなるのか
• 業務のタイミング、時期や時間による制約
• 業務の前提条件
• お客様レビューでのアジェンダ(同席するメンバと認識を合わせておく)

スタンス

• 自分が作った資料や説明に自信をもつ
• 間違いや指摘事項があれば素直に認める
• わからないことがあったら素直に聞く(わかった風にしない)
• そんな大したことじゃないから大丈夫！(構えずに、失敗を恐れずに)

本番

そしていざお客様のもとへ。
お客様は九州にいらっしゃるため、東京から九州までの出張となりました。
(出張は人生初！)



まずお客様の要件について、現在の問題点を挙げた上で説明しました。
そしてその要件を実現する方式として、基本設計の内容を説明していきました。

1.業務フローの説明

新しく追加する業務に関連する部分について、
現状どうなっているか→仕様変更後はどうなるか
という対比形式で説明をしました。

この案件で対応する業務は時期や前後の処理の流れに左右されるものなので、全体的な流れをしっかりと把握してもらうことが大切だと思い、このような説明の仕方をしました。

2.画面レイアウトの説明

画面レイアウトについてはいくつかの案を作成しており、それぞれの案についてどのような意図があるのかを説明しました。

ここではお客様の視点に近い案を選び出し、そこからさらにお客様の意図に案を近づけるというようなやりとりを行いました。
具体的にはメニューの配置や表示する項目について、どこがいいのか、何が必要なのかなどを細かく話をしました。

お客様が考える業務の視点を生で聞き取ることのできる機会として、この場はとても刺激的でした。
私が設計をしていたときには考えつかなかったことを次々と発言してもらい、そのひとつひとつを設計書へ反映させていきました。

3.制限事項の説明

新しい業務の中で「できること」と「できないこと」の説明を行いました。

当初、私は「できること」ばかり考えていました。
しかし「できること」、つまり「要件」については(よっぽどの齟齬がなければ)お客様も開発者側も把握していることであって、むしろ「できないこと」を明確にする方が大事な気がしました。
「できないこと」を明確にすることによって、「できること」の輪郭がより一層際立っていったように思います。

また、制限事項の中で、アクセス権についてもヒアリングを行い、この機能のユーザを明確にしました。

制限事項について擦り合わせをした上で、画面操作時にどのようなエラーチェックを行うのか、そしてどのようなエラーメッセージを表示するのかの詳細を話し合いました。

4.Done!!

こうしておよそ40分間の基本設計お客様レビューは終わり、この場で決まったことを基本設計書へ反映させれば次の行程へ進むことができる、という状態まで持ち込むことができました。

私が考えもしなかったようなことを聞かれたらどうしよう、なんて不安もあったのですが、説明や質問に対する答えは作成していた設計書と持ち合わせていた知識で間に合い、ほっとしました。





案ずるより産むが易し、といった具合ではありましたが、それも事前の準備がしっかりできていたおかげだと思います。
また、周囲の人にアドバイスを受け、短い時間の中で心構えができたことも成功の要因だったと思います。
(アドバイスくださったみなさんに感謝します。)



次は詳細設計。
今回ほっと一息ついて詳細設計に進むことができたように、安心してコーディング作業に進めるようにがんばりたいものです。

初めてのシステム開発工数見積もり

プロジェクトに配属されてから6ヶ月が経過しました。
その間、仕様変更の対応で詳細設計から製造、単体試験、結合試験、総合試験という一連の作業をいくつか担当してきました。
こうしてシステムのことも、開発のことも、少しずつわかってきたなぁというところで、新しい仕事がやってきました。

「見積もり」

5月上旬から6月下旬にかけて、合計7機能の仕様変更・故障改修見積もりを行ったのですが、システム改修の見積もりは初めてのことでした。
そこで今回は、初めての見積もりで私が何をしたか、そして今度見積もりをするときはどんなことをしたらいいのか、経験をベースにしてまとめたいと思います。

■初めての見積もりを振り返る

見積もり着手から最終レビューを通るまでの過程を案件ごとに振り返ってみました。

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

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

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

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

■見積もりのポイントって何？

いくつかの見積もりをしていく中で得た見積もりのポイントを整理したいと思います。
あくまで今の私が思ったポイントですが、敢えてこれ以上のインプットをしないまま書きだしていきたいと思います。

①要件を明確にする

この見積もりは何を目的にしているのか。
何をするにも目的は大事ですね。
見積もりの際の目的は今回のケースでいうと3つあると思います。
    1.できるのか、できないのかを知るためのもの（工数とおおまかな実現方式）
    2.内部資料（故障の改修など、要員確保や他チームとの調整を行うベースとなる）
    3.スケジュールに落とし込むことができる精度の高いもの

目的別に、時間をかける場所がどこか、どの部分にどのくらいの根拠が必要かが変わってきます。
例えば、1のようにお客様もまだやるかやらないかわからないような状況で、おおまかに工数や改修内容を把握したい場合に細かな分析をする必要はありません。
逆に3のような細かな見積もりを行い、スケジュールに落としこむ場合には、見積もりの誤差によってはリスケが必要になってしまします。
見積もり時点で工数に影響すると思われる箇所があり、かつそれを数値化できないのであれば、懸案事項としてとりあげ、リスク管理をしておかなければあとで残業まみれの大変な状況になってしまうかもしれません。

②試験は観点を明確にする

どのような試験を行うかは直接試験工数に影響します。
試験観点が不明確な見積もりは、試験内容と工数とに乖離を招き、意味不明なものになってしまいます。
試験内容と工数の関係性が明確な記述をすべきです。
試験内容を記述する際に注意すべきは次のような内容です。
    ・結合試験、総合試験でどのような観点で試験を行うのかがわかる記述にする
    ・開発対象と試験のかかわりがわかるようになっていなければ、客観的に理解できる見積もりではない
    （なんでそんなことするの？と思われないような内容になっているか）
    ・工数が妥当であると判断できるレベルで記載する（工数がかかるポイント、軽くできるポイント）
例えば、試験工数が大きくなる要素として「改修箇所以外の業務に使用する試験データも準備が必要である」というような記述をしておけば、工数の妥当性を訴えることができます。
他にも「定期的なイベントに合わせて試験を実施することで工数削減ができる」というような記載があれば、さらに検討の余地があることを提示できます。
また、試験観点、試験内容を明確にすることは、影響範囲を明確にすることにもなります。

③自分以外の人がその見積書を説明できるか、の観点で見直してみる

見積書をお客様に提示するような場合、その見積書を持ってお客様と会話をするのは見積もりを行った人ではなく営業担当者かもしれません。
実際には営業担当者である場合がほとんどだと思われます(明確に役割を定めているようなプロジェクトであれば)。
つまり営業担当者が見てお客様に説明できる内容になっていなければ、お客様の同意を得るのは難しくなってしまいます。
そこで、「システムの中の人」から一歩離れて、お客様の立場になってもう一度見積書を見直すことが必要です。
客観的に評価することはなかなか難しくもありますが、チーム内外のレビューを通すなどして、より客観的な文書にしていくことで、わかりやすく明確な見積もりにすることが可能だと思います。
もちろん、どの程度文書として整理していくかの度合いも①で述べた目的によりけりかとは思いますが。

あとがき

こうして私の初めての見積もりは終わりました。
ベースとなるような知識もないままにがむしゃらに取り組んだわけですが、まだここから、というところです。
今度はまとまった知識をインプットするなり、過去の事例を見るなしりて、次の見積もりでどう考えられるか、何をアウトプットできるかという段階に移って行きたいと思います。
Go to The Next Door.

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

きっかけ

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

作業内容

見積もりに記載された改修内容については当時のものを信頼する形で、それに必要な工数の算出に着目して作業を行いまいした。
このプロジェクトの開発工程にしたがって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％くらいを実現させるつもりで作ります。
起動して、ワークスペースとなる１画面が表示されて、終了！っていう一連の処理ができること、それが第一段階の目標です。
そこから第二段階、第三段階…というように成長させていけたらいいなと思います。
ここまでくると夢のようです。
でもやればできる、夢が現実になる、そう思って頑張ります。