「見える化」で陥りやすいこと
経営やITマネジメントの分野で「見える化」が注目され始めて，もう2～3年経つ。いまだに大きな関心を集めているようだ。 先週，「見える化」「現場力を鍛える」などの著書で知られる遠藤功氏（早稲田大学ビジネススクール教授，ローランド・ベルガー日本法人会長）の講演を聞きに出かけた。400人ほど収容できる会場は満杯。現場力や見える化をテーマにした講演に，参加者が熱心に耳を傾けていたのが印象的だった。 講演で興味深かったのは，「間違った見える化」として取り上げられた，あるソフトウエア会社の事例である。このソフトウエア会社では社長が旗振り役となり，熱心に見える化に取り組んだという。最初に手掛けたのは，個人の負荷状況の見える化だ。ある人が仕事を抱え込んでパンクしそうになっているのを，タイムリーに助けてあげるための仕組み作りである。ここで大きな成果を上げ，この会社は見える化の取り組みを広げていった。 ところ
ドキュメントとして何を書くか？
僕の考えは、以下のような感じ。 (1) ドキュメント（設計書だろうが仕様書だろうが）は、「誰に何をどう伝えるべきか」を考えれば、何を揃えればいいかは自然と決まってくる。そして、誰が読んでも意味がないと判断されるドキュメントは意味がないので書かない。 (2) 「基本設計書」や「詳細設計書」や「外部設計書」や「内部設計書」という言葉があるが、肝心なのは「誰に何を伝えるか」であり、伝えたいことや認識あわせの単位でドキュメントが作られればそれでいい。それらをまとめて「○○設計書」とするかどうかは、顧客がそうしたければ好きにすれば良い（そこまでやる義務は開発側にはないと思う）。 (3) アーキテクトの仕事は、各作業者が何をしたらいいか迷うことなく作業ができるように「決めごとをしていくこと」。その決めごとは、すべてドキュメント化されるべきであり、そのためには「誰に何をどう伝えるべきか」を考えていけば、
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
