家庭用ビデオで撮影したデータからプレイヤーで再生できる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単位で算出してくれればいいし、改修内容の細かいところについてもまだ今の段階では不要で、もうひとつ上位のレベルで検討して欲しいと言われました。
しかしこのレベルまで検討が出来ているなら、メリット・デメリットを明確にして、改修内容のレベルに応じて改修案を２つ提案してもよいかもしれないとも言われました。

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

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

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％くらいを実現させるつもりで作ります。
起動して、ワークスペースとなる１画面が表示されて、終了！っていう一連の処理ができること、それが第一段階の目標です。
そこから第二段階、第三段階…というように成長させていけたらいいなと思います。
ここまでくると夢のようです。
でもやればできる、夢が現実になる、そう思って頑張ります。

アイディア創造のフレームワーク

どうやったらいいアイディアを生み出せるか。
そんなことを考える機会があり、レポートを書くことになりました。
レポートの材料として自分で本を選び、A41枚程度にまとめるというのが課題。

実はそういうレポートを書いたことのない私ですが、あえてここにそのレポートを載せようと思います。


目的を果たすためのアイディアをどう生み出すか



小沢正光氏の著書、「プロフェッショナルアイディア。」についてレポーティングする。
著書で筆者は思いつきではなく、必要なときにニーズを満たすアイディアを生み出すには、3回3ラウンドのプロセスが有効であるとしている。
3回3ラウンドとは「書きだす」「整理する」「チョイスする」という3つのステップを順にこなすことでアイディアを練りあげていき、さらにこれらを3回繰り返すことでアイディアを完成させる、という手法である。

「3回3ラウンド」ではまず最初に「書きだす」作業を行う。この作業で頭の中にあるすべてのことを目に見える形にする。
頭の中で考えているだけでは曖昧だったことも、書き出すことで具体化していくのだ。
この作業では、次の点に気をつける。
・優劣はつけず、思いついた考えをすべて書き出す(中途半端なままにすると心残りになり、アイディアを見極める阻害要因となるため)
・書き出す作業は手書きで行う(手で書くことで脳が活性化するため)
・人目を気にしなくてよい場所で行う(考えることに集中するため)
・書き出す作業は最長でも２時間を限度にする(集中して作業に取り組むため)

次に、書き出したことを「整理する」。
書き出したアイディアを第三者にも理解できるように別の紙に清書する。このことによって、書き出されたアイディアを鮮明にすることができるのだ。
この作業では、次の点に気をつける。
・重複している内容はひとつにまとめる(思いつくままに書き出したものには重複するものが存在するため)
・意味不明なものは書き改めるか削除する(考えながら書き出したものの中には自分でも理解できないものもあるため)
・アイディアの良し悪しを吟味しない(整理することだけに集中するため)
・誤字脱字をなくし、わからない語句を調べて表現を練る(上司やクライアントに提出できるレベルにするため)
・骨子や要点に的を絞り、一目見て理解できる内容にする(シンプルな表現にするため)
・字は丁寧に書く(丁寧に書くことで自分の考えのあらが見えてくるため)
・清書する紙はひとつのアイディアにつき1枚使用する(次の作業で使用するため)

最後に、「チョイスする」。
清書した紙を壁に貼り、少し離れた位置から紙を眺め、良いと思ったものは残し、そうでないものは剥がしていく。
こうすることで客観的な視点に立つことができ、思い入れを排除して正しくアイディアの良し悪しを判断できるようになる。
この作業では、次の点に気をつける。
・以下の3つの視点に立って3つすべての視点を満たすアイディアを選ぶ
・個人の視点:自分の価値観に照らし合わせてそのアイディアが好きか嫌いかを判断する(自分が好きなアイディアでないと第三者を説得することが難しいため)
・相手の視点:クライアントの視点に立って、そのアイディアが受け入れられるかどうか、利益になるかどうかを考える(クライアントに満足してもらうため)
・全体の視点:社会的な視点に立って、業界での評価や社会的影響の観点からアイディアを選ぶ(役割や評価、モラルについて検証するため)

これらの3つの作業を1ラウンドとし、3回繰り返す。
3回繰り返すのには次のような理由がある。
・最初に出たアイディアには自分のおごりや思い込みが強く出ていることが多く、公には通用しない可能性がある
・頭の中にあることをすべて書き出していても、まだアイディアは頭の中に眠っている
・繰り返すことで考えの甘さをなくしていく
また、3ラウンドは必ず締切りを決めて計画を立てて実行する。時間的な制限の中で力を振り絞ることで良いアイディアを生み出すことができるからだ。

このように3つの局面それぞれでその作業に集中し、それらを繰り返していくことで練り上げる。これが筆者の言う3回3ラウンドであり、そこで生み出されたアイディアは、目的を達成するためのソリューションとなるのである。

参考

レポートなのに書いていると主観的になってきてしまい、視点を遠ざけるのに苦労しました。

自分ではあまり満足していませんが今回はこれで…

理解したことを人に伝えようとすると自分の足りない部分がよく見えてきます。

このアイディアのフレームワークと同じように、とにかく書きだしてみること、これはアイディアを創りだすこと以外にも有効なのかもしれないです。

VBAでHTMLのTableタグ内データを取得する

HTMLファイルからデータを取得するプログラムをVBAで作りました。

具体的にはhtml、body、table、tdタグをキーにしてTableタグ内のデータを取得する仕組みです。
tdタグ内に記述されたデータ(innertext)が取得対象となります。
実行環境はExcel VBA、IE6です。
VBA側の参照設定はデフォルトのままで実行できます。

TDタグ内のデータを取得するプロシージャ

---

Sub getTDinnertext()

    Dim intIndex As Integer
    Dim objTag As Object
    Dim objTagTable As Object
    Dim varTDinner(371) As Variant
  
    intIndex = 0
  
    For Each objTag In objIE.document.body.all
      
        If objTag.tagname = "TABLE" Then
      
            For Each objTagTable In objTag.all
              
                If objTagTable.tagname = "TD" Then
              
                    varTDinner(intIndex) = objTagTable.innertext
                  
                    '取得したデータに対する処理
                    'Debug.Print intIndex &  "::" & varTDinner(intIndex)
                    'Cells(intIndex + 1, 1).Value = intIndex
                    'Cells(intIndex + 1, 2).Value = varTDinner(intIndex)
          
                    intIndex = intIndex + 1
                  
                End If
              
            Next objTagTable
          
        End If
      
    Next objTag
  
End Sub

---

取得した値は配列型の変数に格納しています。

このプログラムではTD要素が371個存在したので371個の要素を持つ配列を宣言しています。

(動的配列を使った方がスマートに書けるのかな)

なのでTD要素の個数が372以上の場合、上記プログラムでは「インデックスが有効範囲にありません」というエラーが発生します。

また、このプログラムは先にIEオブジェクトを生成して取得対象のWebページを開いておく必要があります。

実際には以下のようなプログラムの中で上記プロシージャを呼び出して使っています。

アクセスしたサイトからデータを取得するプロシージャ

---

Sub test110712()

    'IEオブジェクトを作るサブルーチン

    Call CreateIE

    

    objIE.navigate "http://www.shimatetsu.co.jp/bus/busjikoku/bust01.htm"

    

    'ページの読み込みを待機するサブルーチン

    Call WaitIE

    

    objIE.Visible = True

    

    Call getTDinnertext

    Set objTag = Nothing

    Set objTagTable = Nothing

    Set objIE = Nothing

    

End Sub

---

※CreateIEプロシージャとWaitIEプロシージャについてはお手数ですがVBAでJavaScriptが埋め込まれたリンクをクリックするエントリーを参照してください。

例えば長崎空港線（島原港⇔長崎空港）のデータを取得すると次のような結果が返ってきます。

仕事場の環境的な制約でVBAを使ってこんなものを作っていますが、これが意外に役に立っていたりします。

イミディエイトウィンドウの限界

VBE(Visual Basic Editor)を使ったVBAプログラミングのお話です。

テストコードの動作確認のためにDebug.printを使ってイミディエイトウィンドウに取得した値を出力していました。
一度に371行のデータを出力するプログラムなのですが、お？
全てのデータが出力されていません。

※テキストは一部マスキングしています。

プログラムが悪いのかと思ってステップ実行をしてみたところ、ちゃんと1行目から順に出力されていました｡

つまり、イミディエイトウィンドウで一度に出力できるデータ数は

371 - 172 = 199 行？

イミディエイトウィンドウの最終行は常にプログラムが1行入力できる状態にしてあります。

従ってイミディエイトウィンドウで使用できる行数は199 + 1 = 200 行ということです。

199を超えるデータを出力してテストする場合は出力のロジックか出力先を考えてあげないといけないですね。

WARファイルのデプロイ

勉強が進まなすぎて悲しくなってくるので、もうちょっとしたことでもいいからアウトプット。
WARファイルのデプロイについてメモっておく。

サンプルプログラムをインポートして参照するためにはWARファイルをデプロイしてEclipseで使えるようにする必要がありますよ、ということで以下デプロイ手順。

1.[ファイル]→[インポート]
ファイルをインポートする、っていうところが入り口。

2.インポート対象を選択

[Web]フォルダの中にある[WARファイル]を選択して次へ進む。

3.インポートするWARファイルを選択する

4.選択したファイルが表示されたら完了！

…これでデプロイは完了。

ここからインポートしたソースを見ながら勉強していくことになります。

Sample通りに構成できない〜JavaとJDBCで奮闘中〜

一向に進まないJavaの勉強。
JDBCを使ったMySQLDBへのアクセスがどうにもこうにも行き詰ってしまったので一旦離れてみることに。
で、Sampleとして提供されたプロジェクトをそっくりそのまま真似してクローンを作ってみることにした。
Sampleがやっていることはログインログアウトの実装、StrutsとMySQLなDBを使っている。

コピーするだけとは言ってもコードは全部自分で入力した。
必要なライブラリのインポートも一個一個確認しながら遂行。
どうにかこうにかできあがったので実行してみたけど動かない。

こんなエラーが出ている。

 The server encountered an internal error () that prevented it from fulfilling this request.

気になっているのは真似できていない箇所。
ライブラリの構成がSampleプロジェクトとは違っている。しかし同じにする方法がわからない。
Sampleのライブラリ

私が作ったプロジェクトのライブラリ

うーむ。

「Web Apps ライブラリー」フォルダの下にどうしても配置できない。

どうやったらいいんだろう。

これをSampleどおりに配置したところで問題が解決できるかどうかはわからないが、とりあえず同じにして間違いの可能性を検証したいところ。

もうひと踏ん張り調べてきますかぁ。

その2:MySQLへJDBCを使って接続する〜ドライバのインストール〜

2.MySQLドライバのインストール


その前に、やさしいJavaさんを読んでみると「共通するファイルの設定」というのがある。

Tomcatで共通して使用するファイルをTomcatがインストールされたディレクトリのlibディレクトリ内に配置する必要があるらしい。

で、その共通して使用するファイルというのは「derby.jar」でｍこれはJDKに添付されているJavaDBなんだそうだ。

私の環境ではこのファイルが

「/Users/Anri/eclipse/plugins/com.aptana.ide.libraries_2.0.0.1253913567」

っていうところにあった。

勢いでインストールしたAptanaのプラグインの中?!

他には見当たらず。よくわからないけどこのまま続けてみよう。

というわけでこのファイルをコピーしてTomcatの下に配置する。

「/usr/local/lib」

がその場所みたい。このディレクトリには他に「tomcat-coyote.jar」とかっていう「tomcat〜」っていうjarのファイルが存在している。

※メモ:そもそも「Tomcat〜」っていうディレクトリが存在していない状態のTomcatのインストール状況には問題ないのかな?!

それと問題のMySQL用のドライバもここと同じ場所にコピーしておくらしい。

これは別のWebサイトを参考にしたもの。

"今回はサーブレットでの利用を前提としていますので"と書いてあるのが気になるんだけど（サーブレットの使用が前提ではなかったらここにコピーしないの?!）、ひとまず試してみることに。

※参考

JDBCドライバの取得(MySQL用)

http://www.javadrive.jp/servlet/database/index1.html

インストールはこれでおしまいみたい。

次は何をするんだ?

やさしいJavaの記載を参考にすると「web.xml」を編集するらしい。

Eclipseを使っているとどこまで自動でやってくれていて、どこは自分で設定してあげないといけないのかよくわからない。

この本はEclipseの使用を前提にしてはいないので、Eclipseを使用した場合にこの本にあることすべてをやる必要はないのかもしれない。

ま、わかんないことはやってみるしかない！ということで。

3.web.xmlの編集(※次のページへリンク予定)

その1:MySQLへJDBCを使って接続する〜ドライバの入手〜

やさしいJava活用編を参考にしながらEclipseを使ってMySQLへの接続を試みているが成功しない。
The requested resource () is not available.
というわけでエラーが返ってくる。
・MySQLのドライバがちゃんと設定出来ていないのか？
・URLが間違っているのか？
・クラスパスのところを見ればいいのか？

原因を探りつつあれこれ挑戦してみるも、出続けるのは同じエラー。
嫌になってやる気も失せてしまったり…しかしそれでは先に進めないので手順をひとつひとつ追いかけながらどうにかこうにか解決に導きたいと思う。
いろんなソースにあたればそのうち原因がわかるかもしれない…よね…（とてもとても淡い希望）

1.JDBCドライバの取得

MySQLのサイトから当該ドライバをもらってくる。
http://dev.mysql.com/downloads/

Java用のドライバはここ

http://dev.mysql.com/downloads/connector/j/

で、私はMacを使って勉強しているので拡張子tar.gzの方をダウンロードする。

アカウントは作りませんよ、を選択してミラーサイトからダウンロード。

解凍するとファイルがざざっと出現。

「mysql-connector-java-5.1.16-bin.jar」ってのがそのドライバらしい。

【Berak Point】

…多分ここまでは手順（準備）として間違っていないと思う。

で、ダウンロードしたら次の課題はこれだよね？

2.MySQLドライバのインストール(※次の記事へリンク予定)

勉強が進まない〜Java〜

Javaの勉強をしていますがなんだかやる気がわかず、しかし時間ばかり過ぎて何も習得出来ていないことに焦りを覚える…

どうしてやる気が出ないんだろう、と思って色々考えてみました。

とりあえず、遠くを見る。

今月勉強したいと思っていることをざっとマインドマップにしてみました。

※基本情報技術者のところは読んでいる参考書の目次をマッピングしただけなので必ずしも7月にやるってわけではないです（そこもちゃんと計画しましょう>私）。

主にJavaの勉強について遅々として進まない状況にストレスを感じているのですが、マインドマップにしてみるとよくわかります。

みえているものの少なさ。

つまり何をしたらいいのかよくわかっていないんでしょうね。

一応課題は与えられていますが、課題と自分ができることとの間には隔たりがあるわけです。

勉強しているんだから当然のことですが、その隔たりの埋め方がわからない。

ひとつひとつ、構成要素を埋めつつ進んでいくしかないんでしょうが、焦燥感と不安（これでいいのかな、っていう）がやる気を奪ってしまうのです。

仕事をする上でのメンタルな部分のコントロールが私は苦手だなと思います。

感情の起伏が激しいし、自分が納得したことでないとすごくストレスを感じます。

こんなふうに不安な要素があるとやる気までなくなってしまったり…

そのたびにまたこうやって何が悪いのか、何をすべきなのか考えるわけですが、悩むたびに少しは強くなっていっててほしいものです。

自己と意義

合宿を通して、自己実現を図りながら仕事をしていく過程において、仕事の意義とは大変重要なものであることを再認識した。
何に意義を感じて仕事をしていくのかというのは自分がどんな人であるのかを表すものでもあると感じ、自信がそれを把握しておくことが今後の仕事の仕方にも大きく影響するのではないかと思った。

ここでは私がどのように仕事に向き合っているのかを振り返り、同じような場面に遭遇したときにどうすればよいのかを考える。そして意義を明確にするという手段によって自分がどうであるかを把握する機会を日々の生活の中で設けられるようにしていきたいと思う。



仕事と意義

私にとってその仕事がどんな意義を持つかということはとても重要なことだ。
それは私が取り組んでいるものにある意義を原動力として仕事を推進し、学習の動機を得ているからだ。
その仕事にどんな意義があるのかわからないと原動力は失われ､勉強しようにも何を勉強すべきなのかわからなくなる。
とはいえ、仕事をしていれば意義がどうであろうとやらなければいけないことがある。しかし体が動かない、仕事が進まない。そうなると、やらなければいけないことに対して行動することができない自分に嫌悪感を抱き、負のスパイラルに陥ってしまう。

このままの状態で考え続けることが現実的でないことは明らかだ。では一体どうすればいいのだろうか。


意義の再発見―第1のステップ

抱えている仕事に意義を感じられないとき、その仕事に対して何らかの疑問が生じている場合が多い。
その疑問は自分がどんなことに意義を感じるのかということと関係している。
例えば私は「自分の作っているものがユーザの役に立ち、喜んでもらえる」ということに意義を感じるが、意義を感じられない状況では「この成果物は本当にユーザに使ってもらえるのだろうか、必要とされているのだろうか」という疑問を感じていたりする。
このような場合、疑問を解決することで再び仕事の意義を見つけることが出来る。
関係する人に質問をしたり、自分が思っていることを提案してみたりして疑問をひとつずつクリアしてくことでぼやけていた意義が鮮明になってくるのだ。


しかし疑問の解消が意義の発見に結びつかないこともある。期待する答えが得られなかったり、そもそも関心を持ってもらえないこともあるのだ。


意義の再発見―第2のステップ

仕事とそれに付随する疑問や課題の解決によって意義を見いだせないとき、目の前にある仕事よりももっと先にある目的を再度見直すことが有効だと思う。
意義を見いだせず、行き詰まってしまったときの私は目の前のことで頭がいっぱいになり、広い視野で物事を考えることができなくなっている。
そこで意図的に遠くを見、自分が何をしたいのか、どこに向かいたいのかを自問自答する。
そうすることでまず目の前の問題の重さが変わってくる。
それまでは頭の中の大半を占領していた問題が、取るに足りない些細な問題であると思えてくる。そして今目の前にある課題よりももっと考えるべきことがあるということに気づく。
個々のタスクがどうであるかというより、そのタスクを包括しているプロジェクトがどうあるか、どうであるべきかを考えるという具合だ。

このような考え方をするのは当たり前のことかもしれないが、ある目標からブレークダウンされたタスクに取り組んでいるともとの目標に立ち返った視点を忘れてしまいがちだ。
思い描く成果をあげるためにも、こうして広い視野がもてる場所に立ち返ることが必要だ。


意義の再発見―第3のステップ

取り戻した広い視野の中でさえも意義が見いだせないことがある。そもそも進むべき方向は正しいのか、という疑問があったり、自分のしていることに自信がなくなったりするのだ。
意識して遠くを見つめることができても納得する答えが得られない、もはや何がいけなくて何に悩んでいるのかもよくわからない。

こうして一生懸命考えても先へ進めなくなったとき、自分の中にある知識や経験からではアウトプットできない次元のことをしようとしているのだと思う。
今までにない次元のことをアウトプットしたいができないもどかしさに苦しんでいる状態だ。
それを解決するには自分にはない情報に触れることが必要だと思う。書籍やインターネットなどで得られる新しい知識や考え方、誰かの経験談や意見、あるいはアウトプットの手法などがそれに当たると思う。
こうして自分の中には存在しない要素を取り込むことでどこに目標を置くのか、その意義は何かを形にできるはずだ。


発見の繰り返しで見つかる自分

意義を見いだし意欲的にものごとに取り組む、その意義を見失ってしまった時には新たな意義を見いだすための行動をする。
このサイクルによって意義とそれによる動機を得ながら仕事を進められる。また、ひとつひとつの仕事に対して意義を明確にしていく行為は自分がどんな人であるのかを明らかにしていく。

こうして何によって意義を感じられるのかを把握していくことで「自分」という存在をいろんな側面から見つめることができると思う。そして自分を把握することで今後自分が関わっていく仕事や、それを一緒に進めて行くメンバーとの関わり方をより実りあるものにしていきたい。

500時間の行方

8時間。

私が平日仕事に費やしている時間です。
残業はなし、業務改善と題してマクロを使ったツールを作ったり、業務要件をまとめたり、業務マニュアルを作ったりしています。
メインの仕事はマクロの作成になっている今日この頃。
少し前まではそれでもやりがいを感じていたし、実際プログラミングする時に浮上する課題の解決が楽しくもありました。
しかし最近、このメインの仕事がどうにも楽しめなくなってきました。
ストレートに言うとつまんないのです。

同じようなプログラムの流用でだいたいやりたいことができるようになってしまいました。
ずっと同じ部署で仕事をしているので案件も似たり寄ったり。
だからといってその流用しているプログラムをパッケージ化しようとか、クラスにしようとか、そこまでは思えない・・・これは単にやる気の問題なのかもしれませんがね。

そして残念なことに、今の仕事場には今かかえている以上の仕事はありません。
今でも私は時間を持て余しているのであちこちの業務をつついてみては仕事を拾ってくる、そんなやりかたをしています。
つまりやろうと思わなければ何も仕事が無いのです。

今の仕事は契約で行っており、今年9月一杯までがその期間です。
今が6月、つまりあと3ヶ月ちょっとこの仕事を続けることになります。
1日8時間、1ヶ月160時間、3ヶ月ちょっとで500時間ぐらいでしょうか。


仕事があるだけでも幸せな世の中なのかもしれませんが、お金がもらえるってことの前にお金では買えない自分の時間を提供しています。
有限な私の時間ですから、私はもっと有意義な時間の使い方をしたいと思うのです。
さて、どうしたらいいのでしょう。


まだ次のステップはみえていません。
次の扉はどこに？