家庭用ビデオで撮影したデータからプレイヤーで再生できるDVDを制作する（Windows10）

 手順（Windows10使用）

使用したDVD：DVD-R for General Ver.2.1/16X-SPEED DVD-R Revision6.0

メーカーI・Oデータ機器　「バーベイタム」

（データ用DVD-R）

1. 標準ソフトの「ビデオエディター」で動画を編集する。
1. チャプターごとに分割して表示させるためにはチャプター単位でファイルを別にする必要がある。
2. エディタ内の「分割」を使って動画を分割し、それぞれ出力していく。
2. 編集した動画を出力する（この時点では出力ファイルはMP4）
1. 次工程でDVDの再生メニューを作成する際、ソフト側の自動生成メニューでは動画のファイル名がそのままメニュー名となって表示される。
2. 編集の手間を省くなら、ファイル名をメニューで表示したい名称に変更しておくと良い。
3. DVDfabを起動（書き込み3回までは無料で使える）
4. DVDfab内の「作成」に必要なファイルをドラッグ＆ドロップしていく
5. ファイルの順番を指定して再生順に並び替える
6. メニュー画面を作成する場合、「メニュー設定」から作成する
7. 出力先を指定して書き出す
1. 片面1層DVD：DVD5　を選択
2. 片面2層DVD：DVD9　を選択
3. 必要なDVDの枚数を同時に指定できるので、失敗しないことが確定しているならここで必要枚数を指定して出力する（1回のエンコードで枚数分書き出すので時間短縮になる。1回ずつ出力するとそのたびにエンコードが発生する）
4. 一旦ISOデータとして書き出す場合は出力先選択はDVDドライブのまま、「ISO」アイコンをクリックしてこちらで出力先アドレスとファイル名を指定する
   （ドロップダウンリストのほうでアドレスを指定して出力するとISOデータ（拡張子.iso）ではなくビデオファイル形式のファイル一式が出力された。）

注意点その１

この方法で作成したDVDはSHARP製DVDレコーダーでの再生ができなかった。

メニュー画面の表示まではできるが、再生を開始すると最初の動画ファイルのみ再生されて異常終了する、または2番目以降の動画ファイルを指定して再生すると、再生されず異常終了する事象が発生（エラーメッセージ等の表示はなく、再生中の画面からいきなりテレビの画面に切り替わる）。

20名に配布したDVDでこの事象がでたのは3人、いずれもSHARP製プレイヤーを使用。

確認した機種はBD-HDW75（SHARP 2011年製　BD/DVDレコーダー）

• SHARPでは使用を推奨するDVDを設定しており、今回使用したDVDは推奨対象外。また、推奨されたDVDであってもきちんと動作することを保証するものではない旨の記載があった。
• 色々と調べた結果、再生できない原因は以下にあるようだ。
• DVDディスクと再生機器との互換性、相性が悪い
• ビデオファイルを作成する際に使用しているオーサリングソフトと再生機器の相性が悪い

解決策は以下の３つ（検証中）

• オーサリングソフトから出力する際、ビデオファイルを直接ディスクに出力せず、一旦ISOデータで出力し、ISOデータを専用の書き込みソフトでDVDに出力する（今回はImgBurnを使用）。
• MPEG-4のファイルのまま、Windowsに標準のDVD書き込み機能を使って、「このディスクをDVDプレイヤーで再生するために使用する」オプションを選択し、出力する。
• この場合メニュー画面等をつくることはできないが再生できないよりはましだろうという苦肉の策
• オーサリングソフトを経由しないことでオーサリングソフトとの兼ね合いを断ち切る狙い
• 使用するDVDをメーカーが推奨するものに変更する
• DVDを買って他の人に検証してもらう必要があり未実施

注意点その２

DVD出力の際にボリュームラベル名称を日本語で指定した場合、再生時にラベル名が正しく表示されない（文字化けする）。

英名で指定すれば文字化けしないのではないかと思われるが実践していないので不明。

基本設計お客様レビュー

システム開発はなんとなくわかるけど、ちゃんとやったことはないからやってみたい。
・・・そんな思いを胸に転職し、プロジェクトに配属されて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単位で算出してくれればいいし、改修内容の細かいところについてもまだ今の段階では不要で、もうひとつ上位のレベルで検討して欲しいと言われました。
しかしこのレベルまで検討が出来ているなら、メリット・デメリットを明確にして、改修内容のレベルに応じて改修案を２つ提案してもよいかもしれないとも言われました。

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

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