詳細はあとで整形します。とりあえずメモっておく。現在の仕事の親分の問題点。
- 作業の丸投げをするが、どこまでをやればいいか、何をもって終わりかということを指示しないため、投げ切れていない。
- 関係者が複数いても、個別に指示を出すので関係者同士の情報連携や協業ができない。逆に、同じことを複数チームでやっていたりする羽目になっている。
- 個別指示を出してうまく行くのは、各メンバーの作業分担や付加分担を上層がきちんとコントロールしている場合のみ。
- 上層に複数のリーダーがいる状態で、相手リーダー配下のメンバーまで勝手に（事前調整無しで）指示を出したならば、それは必然的に主作業の進捗遅れや混乱につながる。
- ましてや下層メンバーが主体的に（しかたなく自律的に）動いている状況であれば、そういう状況での実態を無視/理解しない指示や作業オーバーライドは遅延のみならず感情的な反感や、チーム同士の衝突、作業の押し付け合いにつながる。
- VB6.0の基本的なありがちな不具合で出るエラーをみても、どういう場合に出るエラーかすら推測できない（たとえば、存在しない配列要素への参照で発生するエラーなど…）。某オブジェクト指向言語をやっていたという噂はあるが、それにしてはあまりにお粗末な理解度。
- それなのに、詳細な障害に対する対応策を自分で決めようとする。
- プログラミング経験のあるベテラン陣の「それは危険」という意見にも耳を貸さない。
- バグを生みがちなポイントが判っていないため、修正がさらなるバグを生む危険性を常にはらんでいる。
- 障害対応を行う主幹なのに
- 根本原因を突き止めようとする努力を全く行わない。
- 原因分析結果を報告されて、逆に「何？もしかして根本原因をしらべたいの？」などと言う。
- 基本の対応策は「リトライ」。リトライは根本解決ではない。大半の場合、問題は解決しない。
- プロジェクトメンバーの組織を変え、増員したにもかかわらず、増員メンバーがいる新チームの役割、作業範囲、メンバーについて既存プロジェクトメンバーに十分な説明を行わない。
- 結果、新メンバーは既存メンバーにとって「何をしに来たの？」という扱い。
- 新メンバーの役割と「やらない、出来ないこと」を明示しないため、既存メンバーとの間に軋轢が生じる。
- 「連携」「水平展開」といった言葉はよく使うが、何を持って連携なのか、どこまでどの層での水平展開か判らないケースが多い。
- 新メンバーの作業に対する直接の質問や抗議（要するに納得していないという生の声）に対し、協力して欲しいという姿勢ではなく「あなたたちはこうすればいいのです。事前に説明したはずですが、伝わっていないようなので再度言います」的な高飛車な姿勢で対応する。結果、さらに反感を買う。
- 報告をするための作業、が主体になっている。お客さんは報告が欲しいのではないはず（もちろん、やるべきことをやって、報告をするのは当然ですが）。
- その割には報告書が誤字脱字だらけ。
- 日本語として破綻している文章。
- 報告書としての体をなしていない（いきなり詳細なログを数ページ記載する、タイトルが「＊＊日発生の障害につきまして」だったり）。
