2015年06月29日

提示した書面・資料の内容を変更するなら、理由を説明すべき

今回は「発注者に提示した資料の内容を、受注者が変更するなら、その理由を説明する必要がある」という点について書きます。

システム開発の現場では、発注者と受注者がいます。
発注者と受注者が異なる会社であることもあれば、同じ社内にいる別の人という場合もあるでしょう。
この違いを問わず、システム開発を依頼する側と、請け負う側とでやり取りする書面についてのお話です。


システム開発の現場では、様々な資料・書面が交わされます。
発注書、見積書、要件定義書、設計書、などなど。

これから開発していくシステムの内容を決めたりしていくうえで、これらの書面のやり取りはとても重要な意味を持ちます。
ただ、一度相手方に渡した書面の内容を変更する場合もあるでしょう。しかし、だまって書き換えるのはNGです。変更の理由を相手に伝えて、納得してもらう必要があります。


例えば、記述の内容が間違っていた場合。
書き換えた本人は間違いを訂正したつもりだったかもしれません。
でも相手方は、何も連絡なく勝手に別の内容にすり替えられた、と悪い印象を持つかもしれません。

相手にとって有利になるような書き換えの場合も、問題になる場合があります。
例えば受注側が見積額をあとで下げたり、開発期間を短縮する、などの場合。
受注側がどうしても受注したくて、意図的に値段を下げる場合もあるでしょう。
でも相手方に予告なく金額を下げてしまうと、発注側に「金額を書き間違えているようだが、金額を間違える会社ってそもそも大丈夫か?」「金額が下がるのはありがたいが、最初の見積もりはぼったくり料金なのか?」などと思われる場合もあります。


具体的な例を挙げましたが、これに限った話ではありません。
書面の勝手な書き換えは、相手に不信感を与えてしまうことがありますから、やはり丁寧に変更内容を説明するべきだと思います。

固すぎる発想かもしれませんが、一度出した書面を書き換える場合は、契約書を書き換える場合と同じくらい丁寧な手続きを取ったほうがよい、という考えを持ってもよいと思います。


「発注者に提示した資料の内容を、受注者が変更するなら、その理由を説明する必要がある」と書きましたが、発注者と受注者を入れえた場合でも同じことが言えます。やはり資料の変更においては、黙ってやるべきではなくて、相手方に理由を説明する必要があると考えるべきでしょう。

2015年06月27日

facebookページと、fecebookグループの使い分け

facebookページとfacebookグループ、何がどう違うのかがわかりませんでしたが、調べていくうちにいろいろ違いがあることがわかってきました。

その大きな違いを、ざっくり簡潔に説明すると、次のような感じのようです。

・facebookページ
やり取りをオープンにし、検索エンジンから検索されるようにしたい場合に適している。
facebookをやっていない人も、閲覧することができる。

・facebookグループ
アクセス制限をかけられるので、関係ない人に内容を見られたくない場合に適している。
検索エンジンには検知されないため、PR的用途には不向き。
posted by キヨ at 23:02| Comment(0) | TrackBack(0) | 人脈/交流会/セミナー

2015年06月17日

Excelで、オートフィルタで抽出したデータの合計値を計算したい場合

先日「Excelで、オートフィルタで抽出したデータの合計値を計算する方法を教えてほしい」と質問されて、パッと答えることができませんでした・・・
悔しかったのと、これを実現する方法を知っていると便利だなと思い、ちょこっと調べました。

こういうときは、Subtotal関数を使えばよいですね。
指定範囲の中で、オートフィルタで抽出されたデータだけを計算対象にできます。
抽出された数字の合計を出すこともできますし、データ個数や平均値などいくつかのバリエーションにも対応できますね。
便利な関数を、また一つお勉強できました。
posted by キヨ at 19:59| Comment(0) | TrackBack(0) | 業界ニュース

2015年06月01日

仕様書は、他人が読んで理解できて、初めて意味を持つ

仕様書は、正確な記述も大切ですが、読んだ人が迅速に正確に理解できるものでなければなりません。

たびたび見かける事例ですが、仕様書に沿って作業をする人が「仕様書を読んでも必要な情報が得られない」と訴える場合があります。
その場合、仕様書を作成した人に質問するなどして確認してみると、「仕様書に書いてある」という返事が返ってきます。
改めて仕様書を見てみると、確かに書いてはあるのですが、書いた当人のメモレベルの記述であるため、他の読み手には理解できない記述であることがあります。だから、「仕様書を読んでも必要な情報が得られない」という訴えが生じるのです。

このような状況では、ドキュメントはあっても、それを使って開発プロジェクトをスムーズに進行していくことができません。
仕様書に事実を正確に書くのは大切です。必要なことをもれなく書くことも大切です。
しかし数ある情報を、どのような順序で文章として組み立てれば読み手が理解できるようになるか、そこまで考えて仕様書は作ってほしいと思います。

「仕様書を読め」「仕様書に書いてあるよ」こんな一言で済ませようとするメンバーが多い組織は、たいていプロジェクト内でも情報連携がうまくいっていないことが多いですね。

仕様などの重要な情報は、紙だけでなく人の頭の中にあるものです。
紙があれば何とかなると、思ってはいけませんね。

仕様書は、他人が読んで理解できて、初めて意味を持つのです。
そのことは、いつもいつも、システム開発の上で感じていることではあるのですけれどね。
posted by キヨ at 20:29| Comment(0) | TrackBack(0) | 業界ニュース