投稿日時:

システム開発などのプロジェクトを進める際に重要なのが、コミュニケーションミスを防ぐことです。
もし、システム開発の途中でコミュニケーションミスが発生してしまうと、既に開発に着手しているにも関わらず、根本的な要件の漏れなどにより設計から見直すことになり、無駄な作業発生やスケジュール遅延などに繋がります。
開発フェーズで気づいた場合は、まだ人員も豊富なためリカバリーが可能かもしれませんが、システムの最終チェックの時に「ここは違う。ここは、こうだと言ったじゃないか。」という話になると、システムの運用開始予定日への影響も危ぶまれます。
そのため、要件や設計に関して「言った、言わない」という話が出る状況を作り出さないように、常に関係者間で認識を合わせる事がとても重要であると言えます。

関係者間での認識を合わせるために重要なツールとして考えられるのは、各フェーズで作成されるドキュメントや各ミーティングの議事録になります。
しかし、多くのプロジェクトが短期開発を求められ、ドキュメント整備が満足にできず、議事録を書く余裕も無いまま、見切りで開発着手してしまうという事があるのではないでしょうか。

そこで、今回のドキュメント整備コラム第5弾は、関係者間で認識を合わせるために重要な役割を担う、QAシートの活用についてお話ししたいと思います。

まずはQAシートについて、イメージを共有しておきたいと思います。本コラムでお話しするQAシートとは、QAに限らずTODOや懸念事項・課題も合わせてプロジェクトに関する情報を1つのドキュメントで一元管理できるシートの事です。

システム開発の各フェーズにおいて、本来ドキュメントがしっかりと作られ、関係者間でのレビューがされており、関係者が納得しながら開発が進められれば、とても幸せなプロジェクトかもしれませんが、実際の現場において、このような理想的なプロジェクトというのは、ほとんどありません。

そのため、各フェーズで作成されるべきドキュメントが不足している場合や、作成されたドキュメントが中途半端な状態のまま次のフェーズに進めなければならない場合に、QAシートが補足ドキュメントとして重要な役割を担います。
QAシートには、関係者間で認識合わせをしなければならない、重要な内容について、必ず記載するようにします。

例えば、最初は○○と話していた内容が、途中で何らかの事由により××にすると方針変更した場合などは、情報が全員に伝わらず、トラブルの元となりがちです。そこで、方針変更があった時には日時を追記し、常に時系列に並べて記録として残すようにし、各フェーズで作られるドキュメントが古いままの状態であったとしても、QAシートを正と位置付けることで、常に最新の情報を関係者間で共有できるようにします。

また、プロジェクトの進捗ミーティングにおいて議事録を都度作成する事は重要ですが、都度作られた議事録は、なかなか振り返って見ることはありません。そこで、進捗ミーティングで議論された内容もQAシートに反映させ、QAシートを常に進捗ミーティングの場で確認することにより、関係者間での情報共有がスムーズにできます。さらにTODOなどを基軸に進捗ミーティングのアジェンダとして利用する事で、ミーティングの準備にかける時間も最少で済み、ミーティング実施の効率化にもつながります。

それでは、QAシート活用のポイントについてまとめましょう。

◆QAシート運用のポイント
 ・QAだけではなく、TODOや懸念事項・課題なども一緒にまとめて管理する
 ・進捗ミーティングの議事録とアジェンダの両方の機能を持たせる
 ・時系列で変化したコミュニケーションのログを残す
 ・各フェーズで作成されるべきドキュメントと相違がある場合QAシートを正として運用する

ここまで読み進めていただくとわかりますように、実はQAシートは補足ドキュメントではなく、主となるドキュメントであると言えるでしょう。プロジェクトを進めるうえで、情報の一元管理による関係者間の認識合わせのツールとして、各フェーズで作成されるドキュメントの補足ドキュメントとして、重要な役割を担うQAシートを有効に活用しましょう。
本コラムが、読者の皆さんの日々の業務に役立てば幸いです。

(担当:小口 真己

投稿日時:

前回ご紹介したマクロを利用して「操作をメニューから選択する」場合は、ファイルを開いた時に、探さなくてもそのメニューが表示されている状態が便利です。
そこで今回は、ファイルを開いた際の表示や画面を設定する「起動時の設定」機能をご紹介いたします。

◆起動時の設定

設定方法は以下の通りです。

(2003)メニューバーの[ツール]→[起動時の設定]
(2007)Officeボタン→[カレントデータベース]
(2010)[ファイル]タブ→[カレントデータベース]

 ・「フォームの表示」 …起動時に表示したいフォームを選択
 ・「ナビゲーションウィンドウを表示する」または「データベースウィンドウの表示」 …チェックを外すと表示されなくなる
 ・「すべてのメニューを表示する」 …チェックを外すと表示ボタン(ビューボタン)など一部機能が表示されなくなる

起動時の設定

また、マクロに「AutoExec」という名前を付けて保存すると、当該Accessファイルを開いた時、自動的にそのマクロが実行されます。起動時の設定とAutoExecマクロの両方が設定されている時は、起動時の設定が実行された後にAutoExecマクロが実行されます。

◆起動時の設定およびAutoExecマクロの回避

管理者がメンテナンスを行いたい場合、上記の設定がされていると必要な操作ができないことがあります。
そのような時には、[Shift]キーを押しながらファイルを開くと、起動時の設定およびAutoExecマクロが無効になります。

このようにメニュー化することは「使う人」にとっての便利さと共に、危険な操作を防ぐことでセキュリティ強化にもつながります。
業務にお役立ていただければ幸いです。

(担当:瀧川 仁子

投稿日時:

ドキュメント整備に関するコラム第4弾は、ドキュメント作成に対する意識についてお話しします。
前回のコラムではテンプレート整備の重要性についてお話ししましたが、今回はテンプレートに頼りすぎることの問題点に触れながら、ドキュメントはどの様に作成されるべきなのか、考えてみたいと思います。

前回のおさらいになりますが、テンプレート整備は、ドキュメントの誤読を防ぎ、作成にかける時間の効率化に繋がり、品質を一定にし、最低限の必要なドキュメントがあらかじめ見えてくることがポイントとなります。

しかし、テンプレートがしっかりと整備されてしまえばしまうほど、テンプレートに頼りすぎたドキュメント作成になってしまい、本来伝えなければならない要件や設計が伝わらないドキュメントとなってしまう事があります。

具体的な例を挙げながらお話しましょう。
画面設計を示す設計ドキュメントをテンプレート化するときに、画面上のボタンの表示/非表示に関する条件式の記載場所はテンプレート化できますが、画面上に表示されるボタンの条件が1つや2つではなく複数の要因による複雑な条件となってしまった時に、無理にテンプレート上で記載しようとして、わかりにくいドキュメントになってしまう事があります。
本来であれば、別にページを設けてマトリックス表などを作成すると、わかりやすい内容になるところですが、テンプレートに合わせなければいけない、という考えに囚われすぎると、本来伝えるべき内容が伝わらなくなってしまうのです。

また、あらかじめテンプレートを決めてしまう事で、テンプレートとして準備されたドキュメントだけ作ればよいという勘違いをしてしまうのも問題です。システム開発のプロジェクトに同じプロジェクトは2つとありません。そのため、他のプロジェクトのテンプレートやドキュメントは、最初にテンプレート展開するときには、とても重要な参考資料となりますが、プロジェクト別に必ずテンプレートでは表せないドキュメント作成が必要となります。

そのため、テンプレートを展開することで、作業効率化や最低限の品質を保つことはできますが、テンプレートは意思疎通のための共通言語となる土台と考え、テンプレート上に表すドキュメントは「誰に何を伝えなければならない」のかを常に考えながら書くべきものです。

「誰に何を伝えなければならない」ドキュメントなのかを考えるときに、漠然としてしまって難しいと思うのであれば、チームメンバーの誰に伝えるべきものなのか、クライアントの誰に伝えるべきものなのか、具体的な人を考えながら記載するだけでも違ってきます。その伝えるべき相手をイメージしながら書く事で、何を伝えなければならないのかが明確になる事でしょう。

明確な誰かをイメージする事から、ステップアップすると、多数の人に対するわかりやすいドキュメント作成に繋がります。

これまでのお話からも考えられるように、テンプレートというのは、常に変化していくべきものになると思います。もちろん1つのプロジェクトや1つのフェーズの中でテンプレートを変えていくのは、本来のテンプレート整備のメリットを無くしてしまうので、問題ですが、プロジェクトやフェーズが進むタイミングにテンプレートを変更させるのは、チーム全体のドキュメント品質の強化に繋がります。

テンプレートの改善までは難しくても、これまでのテンプレートを使った良い事例をチーム内で展開するだけで、ドキュメント品質の強化に貢献できます。この様にプロジェクト実施中における、ドキュメント整備にかける時間を少しだけ意識することで、より良いドキュメントを残すことができるでしょう。

◆ドキュメント作成に対する意識
 ・テンプレートに頼りすぎない
 ・テンプレートは意思疎通のための共通言語
 ・誰に何を伝えるべきドキュメントなのかを意識にする
 ・テンプレートは改善していくべき

今回は、前回のテンプレート整備に関する重要性の背後に潜む、システム開発の現場における落とし穴についてお話ししました。プロジェクトを進めるうえで、テンプレート整備をする時には、テンプレートに対するチームメンバーの意識づけも重要なポイントとなる事が、おわかりいただけたのではないでしょうか。

本コラムが、読者の皆さんの日々の業務に役立てば幸いです。

(担当:小口 真己

投稿日時:

ドキュメント整備に関するコラムの第3弾として、ドキュメントのテンプレート整備に関するお話をします。システム開発の現場では、いろいろな会社やプロジェクト現場に初めて参画する際に、まずはプロジェクトの基本的な知識を得るため、過去のドキュメントを参照するのではないでしょうか。次に、ドキュメントを自分が書く時に、今度は同じ会社の他のプロジェクトなどから、自分が書こうとしているドキュメントと似たようなドキュメントが無いか、探そうとすると思います。

同じ外部設計書であっても、会社やプロジェクトによって、いろいろな形式のドキュメントが作られています。そして、それぞれの会社やプロジェクトの文化によって、ドキュメントへの記載レベルが異なっている事でしょう。そのため、新しくドキュメントを作成するときには、まず、「過去の良い例を探し、流用する」事によって、ドキュメント作成にかける時間をなるべく少なくしようとすると思います。

しかし、実際に過去の良い例を探そうとしても良い例が無い、探す人によって良い例の定義が異なる、記載レベルが中途半端なドキュメントしかなく参考にはできるが、どの様に書けば良いのかは結局、記載する本人任せ、などの例が少なくありません。

本来、ドキュメント整備をするにあたって、最も重要なのは書いた人の意図が、他の誰が読んでも正確に伝わる事ですが、結局ドキュメント作成する人のレベルによって、ドキュメントレベルが異なってきてしまう事は、よくあるお話しだと思います。

そこで、あらかじめ主要な(重要な)ドキュメントに関しては、プロジェクト開始時に、どのテンプレート(過去プロジェクトの良いサンプルを整理しておくだけでも違います。)を使うのか、どの様な書き方をするのか、メンバー間でテンプレートについて話をしてみる事をお奨めいたします。
メンバー間で同じテンプレートを使うことで、個人に依存したドキュメントの記載レベルにならずに、最低限のレベルは確保できるでしょうし、同じ書き方で書く事で、読み手の読解に関する効率化に繋がります。

もちろん、ドキュメント作成時にレビュー会を実施し、対面での説明なども重要になりますが、各フェーズの担当者間でドキュメントのテンプレートを共有しておくだけで、あらかじめドキュメントに記載されている内容以外の部分に注力した説明が可能となり、プロジェクト推進における効率化に繋がります。

隣に座っている人や設計者自身が開発する場合は、設計ドキュメントに頼らずに密な連携ができるので問題は少ないのですが、開発拠点が離れていたり、同じビルで開発フロアが異なるだけでも、誤読に繋がる事は多いと思います。テンプレートをあらかじめ共有しておくことで、誤記・誤読に関するリスクが減り、障害発生や再作業などの削減に繋がり、余裕を持ったプロジェクト推進に繋がります。

また、あらかじめテンプレートを準備することにより、最低限の必要なドキュメントが見えてくると思います。前回のコラム(見落としがちなドキュメント一覧)でもお話ししましたように、ドキュメント一覧作成は重要なポイントですが、ドキュメント一覧を作るときに、テンプレートが整備されているものか、新しくドキュメントを作らなければならないのかを一緒に整理しておくと、作成されたドキュメントのレベル感がわかって良いでしょう。

◆テンプレート整備のポイント
 ・ドキュメントの誤読を防ぐ
 ・ドキュメント作成にかける時間を短縮できる
 ・ドキュメントの記載レベルが一定となる
 ・最低限の必要なドキュメントが見えてくる

今回は意味のあるドキュメント整備に繋がるよう、誤読・誤記を防ぎ、ドキュメントのレベル感を統一するためのポイントとしてテンプレート整備の重要性についてお話ししました。最初にテンプレートについて話をする場を少し持つだけで、その後行程におけるプロジェクト推進の効率化に大きく貢献する事が、おわかりいただけたのではないでしょうか。

本コラムが、読者の皆さんの日々の業務に役立てば幸いです。

(担当:小口 真己

投稿日時:

前回は、Accessでのマクロの作成方法について説明いたしました。
では今回は実際に使われるマクロの例をご紹介いたします。

◎新規入力画面を開く
入力用のフォームを開いた際に、「新しい(空の)レコード」ボタンを押さなくても最初から新規レコード入力として開くように設定します。

まず、「フォーム全体のプロパティ」を選択し、[イベント]タブ→[開く時]にマクロを設定

 アクション = レコードの移動
 オブジェクト名 = (フォーム名)
 レコード = 新しいレコード

(参考:フォーム全体のプロパティ

◎操作をメニューから選択する
1)フォーム上に「ボタン」コントロールを作成
2)ボタンのプロパティの[イベント]タブ→[クリック時]にマクロを設定

 アクション = フォームを開く
 ビュー = フォームビュー

今回はオブジェクトを開くマクロのみご紹介いたしましたが、他にも連続して操作を行ったり条件によって開くオブジェクトを選択するマクロなども作成できます。
マクロを活用することにより、業務の効率化につながれば幸いです。

(担当:瀧川 仁子