顛末書作成マニュアル
顛末書（てんまつしょ）とはトラブルの一部始終…ことの顛末を報告するための文書のことを言います。
かみ砕いていうと、仕事上においてミスや不始末、不祥事あるいはトラブルが発生したときに自らの会社（社内）、職場、勤務先、取引先等に対して問題やトラブルの一部始終を報告するための文書。 あるいはトラブル報告書のことを指します。
私の在籍しているＩＴ業界…なかでもＢ２Ｂでシステム開発を行うＳＩｅｒと呼ばれる企業では、毎年のように何かしら問題を起こしています。企業側としてみれば赤字化する／しないで判断することも多いようですが、お客さまの業務を切り出して替わりに開発サービスを行うＳＩ事業においてはインパクトの大小にかかわらず計画外の問題を起こせば、本来はトラブルと判断すべきです。
それこそが誠実な姿となり、お客さまに真摯な企業と認識されるようになるからです。
トラブルが発生するとすぐに責任の所在ばかり気にする人がいますが、これは最悪の愚策です。ビジネスであることを忘れないでください。
顧客との間でトラブルが発生した場合、まずに考えなくてはならないことはトラブルの早期解決方法です。これを疎かにして他のことばかり気にしている人は、対策チームから一旦除外しましょう。相手がどんなに上役でもかまいません。話が先にすすまないので邪魔です。
責任の所在は、活動開始前に決めておくものです。
プロジェクト当初であれば、むしろ責任の所在をハッキリとさせておくべきでしょう。しかし問題が起きてからいきなり後出しジャンケンのように責任の所在を問い始めるとその気のない人まで巻き込んで他責合戦が始まったり、スケープゴート作りに勤しむだけで何１つ生産的な進展ができなくなってしまいます。ビジネスとしても、人生としてもただの無駄です。
責任が０になることはないと思え
ここで「責任」について簡単に説明しておきましょう。
ビジネスにおける責任とは、刑事責任を問われるような問題でもない限り１０対０と一方的になるようなケースは決して多くありません。ビジネスにはそれぞれ善管注意義務というものがありますから、通常はいかなる理由があったとしてもMAXで９対１あるいは１対９となるようになっています。よって大抵の場合は、自社側に全く責任がない状態ということにはなりません。
仮に
お客さまが言ったとおりに作ったのに、
最後の最後に「こんなのじゃない」と言われた
と言うことがあったとしましょう。
お客さまが言ったことで確かにその通り忠実に作り上げたのかもしれませんが、それは本当にお客さまが運用上望む形になっているのでしょうか？
お客さまが我々よりもＩＴに精通していて、言っていることのすべてが正しいのであれば何も考えずに鵜呑みにして作り上げるのも良いでしょう。
しかし、大抵の場合は逆です。
お客さまの方が我々よりも専門性に長けているということはまずありません。ほぼ100%疎いはずです。でなければ、お客さま自身が内製で作り上げた方がよほどいいものになるはずです。それができないから外部委託しているわけです。
であれば、我々はその事情を踏まえ、お客さまが本当に求めているものと異なる要求を提示してきた場合は訂正させる努力が必要になります。その努力を怠った責任を忘れてはいけません。
これをＰＭ義務（プロジェクトマネジメント義務）といいます。
このように、私たちが改善すべき責任はどんな問題にも存在しているのです。だからこそ責任の擦り付け合いというのはただただ不毛でしかありません。
顛末書の意味と果たすべき３つの役割
根本的な問題を特定する
トラブルを早期解決するために必要な情報は「根本的原因がどこにあったか？」「どうして混入したか？」を明確にする過程でハッキリしてきます。特に”技術的な原因”と”業務的な原因”の２つの側面から検討しましょう。
ここから先は
¥ 1,000
いただいたサポートは、全額本noteへの執筆…記載活動、およびそのための情報収集活動に使わせていただきます。