Software Quality.com

▼

■組織の慣習は重要(2009.10.18)

私は子供のころ（幼稚園～小学校低学年頃）、朝飽きたら歯を磨き、そのあと朝ご飯を食べていました。

どうしてって？それは家族全員がそうしていたから。

子供のころに正しいもの、適切なものの分別を付ける能力などなく、そういうものなんだと何も疑問に思わずにそうしていました。

しかも私はその頃好き嫌いが激しく、食べられるものを数える方が早い状態。

カルシウムを含め栄養状態も最悪。結果、私は虫歯だらけ。

何度も何度も歯医者で泣いていました。

ITシステム関連の組織に入ってくる新人さん達は、当時の私と同じの状態のはずです。

どうするのが正しいのか、適切なのか、それを知っている先輩たちばかりが運営しているんだと。

そう思って組織に入ってくる。

当然周囲がやっていること、上司や先輩がやっている作業方法を、どうしてそうするのがよいのかなんて考えずにただ真似る。

身につけるべきなんだと思って真似る。

その結果、どんな成果が出ようと、どんなロスが出ようと、そんなことは考えずに。

さらにタチが悪いことに、人間が一度身に付いた悪い習慣から脱却するのは簡単ではありません。

そして組織で生き残るためには、おかしなこと、やってはならないのではないかと思うことでさえも、口に出して周囲を調整・説得し、変えていくのはものすごく勇気がいることです。

おそらくほとんどの人たちは黙っている、目立たないようにしているだけでしょうね。

ということで、組織の慣習は非常に重要です。

■どこで終わりとするか(20090811)

久しぶりにコメントを。

最近日本のスイマーの活躍が目立ちますが、ここまでの道のりではいろいろな努力があったようです。

泳ぎは早いのに思うようにタイムが伸びない。そんな状態も続いたそうですが、いろいろと検討した結果、「ゴールタッチをゴールと思うのではなく、ゴールタッチして電光掲示板を見て確認し終えたらゴールとしよう。それまでを全力で！」と改善した結果、成果になってあらわれるようになったのだそうです。

ゴールタッチを最後と思うと、どうしてもゴール前に減速してしまう。

だから、電光掲示板の表示を確認することまでを手を抜かずにやりきる。

それが成果を高める要因になったということですね。

さて、われわれの作業ではどうでしょうか。

システムを納品したら終わり。納期を迎えたらおしまい。

この状態だとしたら、やりっぱなしになっている可能性があります。

その結果、今回のプロジェクトで得られるはずの経験情報や実績データなどが消え去ってしまい、次のプロジェクトに活用できるはずのノウハウやフィードバック事項が何も残らず、またゼロからプロジェクトをスタートすることに・・・。

ということで、プロジェクトでは、納品後のプロジェクト総括や振り返りが終わったら”完了”とするべきではないでしょうか。

そのためにもプロジェクト計画上にプロジェクト総括やふりかえりを明記してからスタートするのがよいと思います。

■なぜ計測するのか(20080921)

先日新聞やTVで大騒ぎしていた学力テストの公開・非公開騒ぎですが、この議論の中にIT業界でも課題になっている”なぜ計測するのか”と同じ内容が含まれているように思いました。

あまり詳しくWatchしていませんが都道府県の平均点の優劣で大騒ぎになっていましたね。

この学力テストっていったい何のために実施されたのかが重要になると思っています。

学力テストでは、それぞれの点数だけではなく、意図的に分類した出題内容に対する出来、不出来の傾向を分析して、その結果と都道府県の優劣を順位で発表していました。

これは一種の計測にあたりますが、さて、この結果は、何のために、どうやって使うことを想定して出したのでしょうか。

もし結果を出して（発表して）おしまい、だとすると、準備から実施、発表に至るすべての努力と工数が無駄（計測することが目的）になってしまいます。

一般的には、子供たちの学力の現状をを把握して、今よりも学力を伸ばすために、現在の制度や教材、授業の方法、教師のスキルをよりよい方向に向かうように改善するため、ということが考えられます。

もしそうであればまだ道の半ばです。

このあと必要なことは、出題内容に対する出来不出来の傾向から、目標となる学力に満たない領域を中心に現状の学校運営、教え方や教材の内容、教師や管理者のスキル、家庭環境、自宅での学習方法などの要因のうち、現在の学力を決定づけているものはどこなのか、何なのかを特定すること、どこをどのように見直せば、目指す学力が獲得できるようになるのかをそれぞれの都道府県、市町村、学校単位で、真剣に考え、行動に移すことです。

以上は例ですが、ここまでのシナリオを、学力テストを企画する段階で考えておくべきだと思います。

学力テストではきっとやっていると思いますが、IT業界の計測ではそうではない事例が結構散見されますよね。

学力テストに限らず、計測は大変な努力と工数が必要な、そして強力なツールなんですから、無駄にならないように、いったい何をしたいのか（目的）を具体的に検討してから実施しましょうね。

■問題は定義とその認識共有が先(20080914)

現状をありのまま把握することって、簡単に見えて実は最も難しいことなのかなと感じています。

これは「自分のことは自分が一番よく分かっている」という思い込みや（半分は当たっているけど）、早く解決したい、余計な作業はしたくないなどの考え方が邪魔をしているんじゃないでしょうか。

めんどくさい、問題を明らかにしたくないなども理由に挙がりそうです。

さらに、立場によって問題が異なるということも災いしているように思います。

そうではありますが、実は改善を成功させる上で、そしてよりよい実践を行う上で、問題を適切に定義すること、そしてそのことを関係者で認識共有することが最重要事項だと考えています。

立場によって異なるように見える問題を、可能な限り関係者全員が共有できる共通の問題として定義することが解決への近道になります。

多くの方たちは、解決したい問題ではなく、いきなり改善手段を出してくることが多いですね。

「システム関連のドキュメントを充実させたい」「レビューを徹底することだ」「テストをちゃんとやらなくちゃ」・・・いやいやそれはみんな手段ですよ。

しかも、あまりにも漠然としていてそんな手段を実施したってほしい効果が得られてたかなんてわからないよね。なんていうのが実態だったりします。

これらの回答が出てきた場合は、「それが不足していることで起きている面白くない事って何だろう？」と問いかけてみてくださいね。プロセス面だけではなく、成果面＝本当に解決したい問題に近づいていくことでしょう。

組織内の問題に対する認識があっていない＝組織のポリシーが浸透していない、関係者に同意されていないことにほかなりません。

ですので、適切な問題解決のためには、まず問題を正しく定義して、関係者間で認識を合わせることが重要です。

■技術バカにならないように(20080831)

久しぶりの書き込みですね。

岡野雅行さんってご存じでしょうか。

”痛くない注射針を作った世界一の職人”と言われている方です。

この方が出している書籍「人生は勉強より「世渡り力」だ！」を読みました。

ここでの”世渡り力”とは、へらへらおべっか使い、人だまし、ウソや取り繕い、長いものには巻かれろ、平々凡々的な薄っぺらい世渡り力ではなく、善人ばかりじゃない世の中で、自分の仕事をアピールし、その運命を切り開いていくための「人と情報のマネジメント力」を指しています。

技術ばかりを学んでも、下記のようなことは出来ないわけですね。

・自分のアイデア・ノウハウを（ムダに広げず、変な奴に横取りされないように）守る

・前例がないから、と言い訳しかしない判断者を突き崩す

・ナメてかかってくる相手を返り討ちにする

・権威をカサに攻めてくる人をギャフンと言わせる

技術だけに強くなっても、自分の立場だけを守ろうとする無能な管理者や経営者（そういう人ばかりではありませんが）、余計な既得権利者や腹黒い奴らなどにいろいろと邪魔されておもしろくない仕事になってしまう。

確かにそうですよね。

だから技術やノウハウ、知識も大事だけど、自分の価値あるノウハウを安売りしないように、適切に儲けるように、人と情報をマネジメントするべきだと言っているのだと思います。

ＩＴ業界はとかく技術論に目がいきがちですので、このような視点も忘れないようにすることは重要ですよ。

薄い本なのでちょっとの時間でも読めますから、興味があれば一度手にとってみてはいかがでしょうか。

何がおすすめって、この方の本は（どれを読んでも）おもしろくて、元気が出ます！

それが一番のおすすめです。

■管理ってなんだ(2008.7.14)

発生した問題の原因分析結果を確認すると、多くの場合「管理不足」という言葉が出てきます。

実はこの「○○不足」という言葉は、対策型表現として相応しくない原因分析結果でもありますが、この件は別件で取り上げましょう。（私が忘れなければですが（＾＾；；）

話を元に戻して、もし”管理”、という言葉が出てきたら、是非「具体的にどんなことなのか？」をつきつめてみましょう。

管理、の具体的な中身、意味、はひとによって異なる可能性があります。

その中には、計画（いや、ときに”見積”も）、進捗状況の確認、フェーズの完了判定、業務完了判定、実績評価、振り返り、などなど様々なものがこの”管理”には含まれています。

これらの中で、どこのことなのかがわからないと、適切な手が打てません。

また、もしも具体的な場所が分かったとしても、そこがどのようにまずいのかが分からないと的確な手段が出てきません。

ということで、管理不足、という分析結果が出てきたら、まだまだ原因分析不足だと思ってください。

■よくある再発防止（是正）処置から分かること(2008.6.30)

これまた私だけそう感じているのかもしれませんが、納品後障害などの不具合事象の再発を防止する場合、よく見かけることと、それらから言えること、分かることを記載しておきます。

■改善、と称して製品やサービス自体を改善すること

→これは再発防止でも、目先の不具合が再発しなくなることなので意味（対象）の違う再発防止です。

本来の再発防止は、目先の不具合を直すことではなく、同様の案件が来た際に同じ不具合を発生させないようにということです。

製品やサービスを改善（あるいは訂正）しても（すること自体は悪いことではありませんが）、次の製品・サービスを作り上げる過程で、同様の不具合を作り込み、かつそれを流出させる可能性が高く、再発しやすいわけです。

この対応は、あくまでも現物処置であり、是正処置・再発防止処置ではありません。

製品、サービスの改善と是正処置を混同している（気がついていない）組織や管理者が多いのは非常に残念です。

自分たちが何をしているのかくらいは把握してもらいたいものですね。

特に管理する立場の方は、このことを使い分ける能力が必須でしょうね。

■再発防止の処置が”チェックの強化”にのみ終始すること

→最低限はクリアなのかもしれませんが、この対応を続けていくと、どんどん作業量が増えていきます。

なぜまずいのかと言えば、いい加減な作業や精度の悪い作業は放置して、それをあとの確認でひっかかったら直せばよい＝確認して引っかからなければ直さなくて良い、という最も生産性の悪い作業を意図することになるからです。

このようになる原因は、原因分析が甘いことにつきます。

自分たちの作業の意図、しくみ、それぞれの作業の連携など本質的な意味を把握せずに作業を行っている証だともいえます。

少なくとも、その欠陥を作り込んだ原因と、作り込んだ欠陥を検出できずに市場へ送り出してしまった原因の両面を把握し、可能な限り”欠陥を作り込んでしまった原因”を、そして”欠陥をそのまま流出させてしまった原因”の両面を除去する処置を実施してください。

欠陥を手直しする工数＝ムダ工数を除去できると、作業全体の生産性が向上するはずです。

そのような対応を通じて、本当の意味で自らの作業の内容や意図を理解しながら、どんどん欲しい成果を上げていけるようになっていきます。

自分たちの作業方法、作業内容、その意図やつながり、基本的な原理を十分理解することなくして、上記のような状況から脱却することは出来ません。・・・というお話でした。

▼よくあるテスト完了基準から分かること(2008.6.29)

私だけそう感じているのかもしれませんが、多くの組織で使われている”テスト完了基準”の一つは、以下のような内容です。

　設定したテスト項目を100%実施してすべてOKになっていること

ここではテスト完了基準が明示されている場合に限っていません。

どこかに明示されてはいないけど、実際どうやってテストが完了したと判断しているかを注意深く聞き取っていくと、上記のような基準を採用している（のと同じ）、という場合も含んでいます。

一般的には質問：「開発において品質に関する基準を採用している」にYesと回答している組織の方が、No回答の組織より品質、生産性が高いということだそうですが、さて、上記の基準は本当に品質維持、向上のために有効でしょうか？

また、この基準が有効になるためには何が必要でしょうか。

もうおわかりだと思いますがこの基準が有効になる条件は、”テスト項目が適切であること”です。

極端なことを言えば、テスト項目が１件だけ設定され、それがOKになればテスト完了になってしまいますからね。（そんなお馬鹿なことをしている訳ではないと思いますが、）

で、テスト項目を適切にするために何をしているかといえば、これまた多くの組織が

　担当者が設定したテスト項目を、リーダや管理者が（事前or事後に）確認する

　不足等があればフィードバックして適切にしている

などの対応を行っているようです。

ここまで来るとようやく、リーダや管理者（いや、担当者も）”どのような切り口でテスト項目を（作成し、）確認しているのか？”が最も重要な要因になることが分かりますね。

ここが肝なんですが、この件、皆さんはいかがでしょうか。

どのような切り口でテスト項目を設定し、確認していらっしゃいますか？

私の経験では、ここが最も曖昧で、経験則や慣習で行われているところであり、明確化するべき、改善するべき、スキルを持つべき対象領域になります。

▼節目を設ける(2008.6.10)

うまくいかないIT開発プロジェクトの特徴の一つに、「節目が分からない」というのがあります。

五月雨的に、徐々に変わっていく特性を持つIT開発プロジェクト進捗の原因は、揺れ動く要求事項にありますが、その特性をそのまま受け入れてしまうと節目がなくなってしまうのです。

節目を設けるのが難しい・・・だからこそ、節目をあえて、意図的に設けることが重要だと言えるのではないでしょうか。

対応手段としては、計画書上で設けておき、終了基準を満たしたら節目と決める方法が一般的ですね。

でも、それでうまくいかないことも多いようですから、私のお薦めは「これにて節目と呼んでおこう」という時が来たら、関係者全員を一堂に会して”これこれこういう状態（こんな未解決事項や対応過程のものもあるけどね・・・を含む）なので、節目とします。」と宣言する場を設けることです。

例えば、そのことを明確にするための儀式として、”皆で一本締めをする”、なんてベタなことでもいいのです。

今一つの節目を迎えたんだ、ということを関係者で明確に認識すること。

その際に、終わったこと＋一部未完了事項や未解決事項があれば合わせて明確にしておくことがさらに重要です。

バカみたいに思われる方もいるかも知れませんが、プロジェクトは所詮人間が行うことです。

関係者が気持ち的にスッキリして、明日からの仕事にハリが出るならそれがいいわけです。

▼知っている・やれる人の人間性(2008.6.1)

IT開発に限らず、日常生活においても同じことが言えると感じたことを忘れないうちに書いておきます。

設計でもレビューでも、ものごとをまとめ上げることでも、何でもかまいませんが、ある時点で何かに秀でた人、知っていてやれる人が、そのことを他者にどうやって伝えていくのか。そのアプローチの仕方に、人間性が深く関わってくるように思います。

ここでは、あることに秀でた人を”育成者”、これからあることをできるようになる人を”育成対象者”と呼びましょう。

もっとも相応しいアプローチは、育成者が、今はできないけどやってみようとトライしている育成対象者の失敗を許容しつつ、むしろその失敗を通じて、育成対象者がひとりで対応できるように育て上げることです。

最終的には、育成者よりも秀でた人をたくさん育て上げることが、育成者の成果になります。

自分が出来ることを誇示し、目立つのではなく、一人前に育て上げること（企業ではその人数）が育成者のすごさなんです。

はじめのうちは、（時に厳しい対応を取ることもあると思いますが、）おおむねはポイントを伝え、やってみてもらい、良いところをほめて、うまくないところを修正しつつ励ます、など、自分でもできそうだと感じてもらう、自信を深める（深めてもらう）アプローチが中心になるでしょう。

力がつくに従って、育成対象者に関わる時間が減り、こちらから切り出すのではなく任せる、ちょっと出来るようになったときにその気になるのはよいとしても、いい気になることを叱る、そして、その人を認めるようになっていきます。自立と自律を促すわけです。

＃　自然の世界でも、子供にえさ取りや行動の仕方を教え、自分で出来るようになったら

＃　わざと突き放す（例えば、突っつきまくって追い出す）ことをしますよね。

一方、もっとも相応しくないアプローチは、ちょっとでもできないことがあればあれこれと小うるさくガミガミ言いすぎる。しまいには取り上げて自分でやってしまう。

そして”このことは自分にしかできない、だから自分は忙しい、何で周囲はちゃんとやってくれないのか、どうしてあなたたちはそうなの、まったくもうっ”的な対応です。

こういう人は、自分は有能、自分が考えていることはまっとうで、周囲の人たちの考え方や価値観は全然理解できない。あーホントに私は迷惑だよ。なんて考えているかもしれません。

視野が狭く、自分勝手で、チームで成果を上げるには邪魔な存在になりがちです。

あることを”ひとり”で行う面では能力が高いのに、チームで協調しながら皆で成果を上げるための対人能力が著しく低いんですね。独りよがりってことでしょうか。

周囲はできるだけこの人を避けようとするでしょう。

育成対象者はガミガミ言われるために失敗をおそれ、新しいことにチャレンジする意欲も失せていきます。

結果、育成対象者は育たない。いつまでたっても育成者の負担は変わらない。

その原因は自分にある。そのことに気がつかない限り、同じ境遇から逃れることは出来ない。

もっと視野を広くして、周囲に感謝の気持ちを持ちながら対応してもらいたいものです。

こういう人の対応に周囲は大迷惑だってことも、そして自分が一人で成果を上げているのではなく､周囲の人達が影ながら協力してくれているおかげで成果が上がっていることを、この人は分からないとね。

こういう人は「感謝の気持ちを持つ」など謙虚さを学ぶなど、考え方を変える、視野を広くするだけで、チームにとってかけがえのない人に変わる可能性があるんです。

両極端を書きましたが、皆さんの身近にはどちらのタイプの育成者がいますか？

育成者→親　育成対象者→子供　と置き換えれば、家庭生活でも同じことが言えますよね。

▼データを価値のある”情報”に変える(2008.5.27)

IT開発で様々なデータを活用して状況を把握したり、判断をしたりするわけですが、様々なデータから価値のある”情報”（＝それはこういうことだ）に変えるのは人間です。

取得したデータをただすらりと並べてみても、そこからは何も分からない。

いや、意味のある、価値のある情報とする、変換することはできないでしょう。

データに意味や価値を与えるのは、それを見る人間の考えや仮定、仮説、経験からにじみ出るその人の深い思考や思い、ものごとを深く見つめる目だと思います。

仮定や、仮説、理解しているものごとの本質、などを持たない人が同じデータを見ても、意味のある情報に変換することはできない。

もし何かの情報に変えることができたとしても、それは一般的な、そして表面的な見方でしかない。

そんな結果は役に立たない。そのまま鵜呑みにすると怪我をします。

特にIT開発は、その過程に多くの人間の思考と行動が絡まってのデータが多い。

機械がやったことや誰がやっても同じ事務処理ではないので、一つ一つのデータ（値）が持つ意味は多くのバラツキやバイアスをも含んでいます。

そんな中で取得するデータは、ないよりはマシ、でもあったとしても額面通りに受け取ることはできない。

では、これらのデータをどのように受け取るべきか。

そこで重要なことは、いかに普段から現場の状況を客観的に見ているか、そしてそれらから深い本質を見抜いているか、ということです。

ただ現場にいて、見ているだけでは不足です。

その状況を（あたかも部屋の上部から）客観視しなければならない。

現状に隠された真実や本質を見抜いていなければならない。

データを情報に変えるには、そういうことが必要になると思います。

▼コミュニケーション力って何だ？(2008.5.17)

IT開発は一見テクニカルなスキルさえ獲得していれば成り立つように思えるわけですが、何が大事ってコミュニケーション力ほど大事なものはないでしょう。

（他にもネゴシエーション力・リーダーシップなど、ヒューマンスキル領域は、IT開発にとってとても大事なものなんです。）

これらの話はよく聞くことではありますが、そのスキル向上に対して的確な対策がなかなかない・・・というのが実情じゃないでしょうか。

その原因は、コミュニケーション力っていったいどんなものなのか？　が分からないことに起因していると思われます。

皆さんはコミュニケーション力とはこういうことだ、具体的に何ができるとコミュニケーション力があるというのかに答えのある方はいらっしゃいますか？

（＾＾）　もしいたら、是非私に教えてください。　（＾＾）

私なりに感じているコミュニケーション力とは、こんなことです。

-----------------------------------------------------------------------------------

□様々な手段を駆使して、自分の言いたいこと、思っていること、考えていることを、相手にできるだけ、ありのまま伝えることができること

□様々な手段を駆使して、相手が言っていること、思っていること、考えていることを、ありのまま把握することができること

------------------------------------------------------------------------------------

まずはこの内容が腑に落ちているかどうかが鍵だと思います。

ここがクリアできれば、次に「様々な手段って何があるんだ？」「それをどんなときに、どうやって活用すればいいんだ？」「注意するべきことはなんだ？」などなど、具体的な対応手段が明確になってくると思います。

さてさて、皆さんの答えは何でしょうか。

・・・と、ここまで記載してみてこの領域は「トレーニング」に関することだと気づきました。

次回以降、「トレーニング」領域に続きとして記載していきます。

まずは自分の言いたいこと、思っていること、考えていることを相手にありのまま伝えるための手段とその手段をどのようにして使いこなしていくようにするか＝訓練内容や訓練方法について、私が思うものを書きつづっていこうと思います。

▼不便は見方によっては味方かも(2008.5.11)

不便さや、自分にとっておもしろくない境遇などは、自分にとって邪魔な存在、うっとうしい存在に思えますよね。反面、不便さやおもしろくない境遇をバネに成果を出している人たちもいます。

例えとしてよくないかもしれないけど、私がこの業界に入った時に存在していたインフラや道具立ては現状と比較して一方的に劣悪でした。

しかし、不便な状況だからこそ、いろいろな工夫を凝らして、先々で手戻り対応を減らす努力をしていたわけです。

→机上デバッグ、などはその最たるモノでしょう。

不便だからこそ活動面で様々な工夫をしていたわけですが、それらの活動を楽にするべく便利な環境がどんどんできあがってきました。つまり、不便さをバネに、何とかならないか・・・工夫を凝らしてきたわけです。

不便さがあったからこそ、活動したし、実現したんですよね。

つまり、自分たちの能力をフルに活用するきっかけは、”不便さ”だったといわけです。

一方、そういう便利な状況ができあがった現状ではどうなったかなぁというと、私が見ている範疇では、それぞれの作業上で本質が欠落している、そして工夫が少ないように感じています。

画面上ですぐにSTEP単位の実行と結果の確認が可能になった環境（昔に比べるとなんて贅沢な環境！）が災いして、目先の動作確認だけが先行し、網羅的な確認事項とポイントの絞り込み検討（テスト設計）をまったくしていなかったり、作業者自身がまず行うべき机上での十分な確認なしで多くの関係者が集うレビューに持ち込まれたり。

人間の活動を楽にするための”便利さ”が、人間を怠惰にしているのではないかと思うところが多いわけです。

（もちろん、そんな人たちばかりではありませんので念のため）

不便・おもしろくない境遇は、ぐちぐちとマイナスに捉えることもできるし、自分の能力をフル稼働させるきっかけになる。

一方で、便利さは、さらに自らの能力をとぎすますために利用することもできるし、自分たちを甘えさせ、怠惰にさせる可能性を持っている。

要は、各自の”物事の捉え方”によって成果は大きく異なる、ということになりそうです。

自分の周囲の状況（一見、良いことも、悪いことも）は、捉え方一つで”自分の力に変える力（＝味方）にできる”ということを心にとめて、日々活動していきましょう。

▼成果物はその作り手を語る(2008.5.3)

報告書には、書き記した人が何をどのように考えて作業しているのかが分かるヒントが盛りだくさんです。

確かに文章表現的なテクニックもあるのだとは思いますが、それだけでごまかせるモノではありません。

整然と記載してあっても、実際に行った作業やその結果が並んでいるだけの報告書は、組織のために、いやその人のために役立たないことでしょうし、作業自体がやりっ放しになっている可能性すらあります。

何も考えずに報告書をただ事務的に作るような対応をする人の実作業は、いつも同じで工夫のない、おもしろくないものになっているのではないかとも思われます。

しっかり物事の本質を捉え、いろいろと工夫して作業している方の報告書は読んでいて感心します。

作業として行ったことはもちろんのこと、独自の視点で考察した”今回の対応で学んだこと”や”今後の対応について”など実績の評価＋フィードバックが明確になっていることが多いです。

仕事をやりっぱなしにしない姿勢が、そんなところにも出てくるわけです。

製品はその作り手を語る、いや、成果物もその作り手を語る、ということでしょうか。

▼文章表現(2008.4.6)

私は学生の時に、国語がダメダメでしたので、文章表現にはまったくといって良いほど自信がありません。

そんな私が、様々な文面をレビューしているのですから、いやはや困ったものです。

今日は「報告書」につい一言。

報告書は、何か調査したり、自ら取り組んだ事項の内容を第三者にありのまま伝える役割があるはずです。

そこで重要になるのは、ありのままの事実をありのまま伝える内容になっていること、そして、自分が感じたこと、考えたこと、推測したことなどを織り交ぜることがあります。

最も困る報告書内容は、何が事実で、何がその人の意見・推測、考えなのかがよく分からなくなっているものです。これらの要素が混在していて、何が本当なのかが分からない報告書はその役割を果たしません。

・・・という社内報告書が多いのです。

なので何かの分析結果を報告書に示す場合、事実情報・自分で推測したこと・結論などのように記載すべき要素を分けて書くことを奨めています。

様式もそれらの要素を欄として分けておくだけでも、かなり改善されます。

・・・でも、多くの技術者・管理者が（いや、私も）報告書を含めた文章表現に難がありますね。

また、記載欄をいくら分けても的を外して書いてくる人が跡を絶ちません。

この状態では、設計書・仕様書・操作説明書などを執筆するときに、こちらが伝えたいことを読み手に伝えられない・・・それが原因になって考慮が不足する、異なる解釈をしてしまう、欠陥を作り込んでしまう、誤って操作してしまう、という事態を招くことになります。

技術的なスキル向上も必要ですが、文章表現のスキル向上も必要ですよね。・・・→自分！

▼権限(2008.3.26)

組織の中で様々な取り組みを行っていると、いろいろな考え方や行動に出会います。

組織横断的な取り組みを行う際によく目にするのは、現場の人たちにちょっと抵抗を受けただけで尻込みしてしまい、その先に進められず身動きが取れなくなっている姿です。

そういう人たちが口をそろえて言う言葉は「私には権限がないから（何もできない・何もしない）」です。

このような方達は、自分の言うことを何の抵抗なく聞き入れ対応してくれることを”権限”として捉えているようです。

しかも、権限は誰かが与えてくれるもの、という考え方が根底にあるようです。

もちろん、時には上司や上長が、部下であるあなたにある日突然権限を与えてくれることもあるかもしれません。

しかし、あえて言わせていただくとしたら、権限というのは、自らの行動で最終的に勝ち取るモノではないかと思うのです。しかも、しょうがなく提供してもらうのではなく、これだけのことをやってきたおまえに相応しいから、という理由で信頼して提供されるモノが本当の（実力が伴った）権限ではないかと思うのです。

今は亡き恩師は、私がまだ若い頃「自分の役職より一つ上の役職であるつもりでいつも考え、行動することが大事だぞ」と教えてくれました。今になってふと、このことは周囲に信頼され、自分に相応しい権限を勝ち取るための考え方と行動の指針だったのではないかと思うのです。

ちょっとくらいうまくいかないからといって言い訳を並べるのではなく、自分に向き合い逃げずに対応しつずけること、毎日の仕事で手を抜かずに目的・目標の実現に邁進することで最終的には欲しい成果を上げること、それらを積み重ねることで、周りに信頼され、自分に相応しい権限が自然とやってくる。

そして付与された権限に寄りかからずに、いい気にならずに、高慢な態度で対応しない。

権限をむやみやたらに、いたずらに振り回さない。

法規制に抵触する場合や顧客に迷惑がかかる局面での判断など、どうしても譲れない、譲るわけにはいかないところでは正々堂々と行使する。

そういう取り組み、姿が理想だと思います。