中小企業に最適なITソリューションって何？

さて、私がリーダーとメンバーのコミュニケーション不全に取り組む一方で もう一点、別の課題にも取り組まなくてはいけませんでした。 それはユーザーとのコミュニケーションでした。 これも社内SEとしての必須能力として語った一つです。 【あわせて読みたい】 社内SEに必要な能力：コミュニケーション能力 システム屋さんっていうのは 結構癖の強い人が多くて、とっつきにくいという世間の評価は 概ね当たっています(笑) しかし、現場の職人気質の人たちも 別の方向でとっつきにくいケースが往々にしてあります。 この方向性の違うとっつきにくさが、すれ違いや認識誤りを起こして プロジェクトを難航させたりするのですが、 具体的にどういう風に方向性が違うかというと システム屋さんは なんでもかんでも理屈で整理をつけようとする 職人さんは 大体の事を経験で整理をつけようとする この双方のズレが、 システム屋さんは 「あの人は全然会話になりません。理由を聞いてもまともな返事返ってこないし。あんなんじゃ要件を固めるなんてできませんよ。」 となり、職人さんからすると 「あいつはだめだ。なんでも理屈でうまく行くと思っていて。それでうまく行けば誰も苦労しねぇっつうの」 となってしまい、お互いが「あいつには言っても無駄だ」となってしまい 致命的な認識ズレ（方向性のズレ）などを起こしたりするわけです。 これが当時、工場側のシステム担当者と、 本社側のシステム担当者で起きていました。 先に述べているように本社システム側のAチームの仕事は、 他システム（この場合、工場のシステム）から渡されているデータを取り込んで処理をするのですが、そのデータに誤りがあって、エラーを起こしてしまうと 本社システム担当者は、工場側のシステム担当者に問い合わせを行います。 まず、ここで問題の一つ目が発生していました。 Aチームのメンバーの工場側への問い合わせの内容は 「こういうエラーが起きているので、改善してください。明後日までにお願いします。」 という、まぁまぁぶっきらぼうな内容でした。 普通は締め切りにせよ、改善の方向性にせよ、軽く打ち合わせでもして、すり合わせをするべきですが、いきなりポーンとこんなメールを送ってしまうあたり、揉める予感しかしません。 ただ、これも理由がなかったわけではなく 先の記事に書いたように本社システムのメ

システムの運用保守って、難しい割に評価されにくい仕事だ と、思っている社内SEは多いかと思います。 その思いは間違っていません。 ともすればシステム導入ばかり脚光が当たって その後の運用保守は「できて当たり前」みたいな空気も流れがちですし 運用保守のフェーズに入った途端、リソースを必要以上に削り取られることも多々あります。 転職するときにも 運用保守しかやっていないんですか？ みたいにいう人もいますが、これは素人感がまるだしになるので、口にしない方がいいです。 逆に「この人経験少ないんだなぁ」と思われてしまいます。 経営者側によく考えてもらいたいのは システムって 導入期間よりも運用保守している期間の方が圧倒的に長い という事です。 経営に与えるインパクトも、導入チームよりも、運用保守チームの方が大きいことが忘れられがちです。 システム導入におけるプロジェクトリーディングも大変難しい仕事ですが 運用保守におけるチームリーディングも質が違うだけで、同等に難しい仕事であるという事を理解するべきだと思います。 システムを導入するまでがコストで、運用に入ってから効果を刈り取るフェーズという考え自体は間違っていませんが、 刈り取りの時期に入ったら、コストが圧倒的に安くなるかというと実はそんなことは決してありません。 それは お店をオープンしたら、あとはお金が自動で入ってくる と考えているのとほぼ同義です。 お店をオープンしたら、むしろそれからが本番、商品を仕入れたり、宣伝をしたり、軌道に乗せるまでにもコストがかかるし、軌道に乗った後もコストは掛かり続けます。 これと同じことがシステムにも言えますので、そこは経営側にもぜひ理解をしておいてもらいたいところです。 さて、運用保守における難しさというのは様々なのですが、ぱっと思いつくものでも システム導入直後の難しさ ・導入メンバー離脱によるノウハウの喪失 ・保守を意識していないシステム構築による運用手法の再構築 運用保守していく中での大規模案件との保守コントロール ・保守における改修と大規模案件による改修内容の整合性の担保 システム切り替えの際の新システムへの移行作業 ・新システムを理解した上での、移行データの作成 などが挙げられます。 どれも表に出にくいですし、訴えても何故か「泣き言」という風に取られがちなのですが、 これらの作

知り合いから、質問を受けたのでそれについて書いてみます。 資料作成の技術とか、プレゼン力ってどうやって身につけたらいいんでしょうか？  社内SEってどうしても世界が閉ざされがちなので、 洗練されている会社に入れればいいけど、旧態依然とした会社に入ってしまったら 自分もそれが当たり前だと思うから、ろくな資料も作れないし、喋りも上達しない というのが悩みというか最近気づいたことみたいです。 さて、これの回答ですが プレゼン力はある程度、意識することで改善できるが、プレゼン資料の作り方に絶対解はなく、会社毎の最適解に合わせる必要がある。しかし、それで一向に構わない となります。 プレゼン、資料の作り方に悩む人は多いと思いますが、結論を書くと上のようになります。何故か？というと 資料の作り方は会社ごと、そして受け取り手によって求められるものが変わる からです。 それは内容もそうですし、見せ方もそうです。 例え同じ内容でも いわゆるコンサルが持ってくるような形で資料を作った場合に それを受け手が求めていなければ、あまり意味がない というか、下手すると評価が一変したりします。 コンサル的な資料を見せて 「おぉ、すごい！」って言ってくれる人もいれば 「小難しく言ってるけど、結局何が言いたいの？」って一刀両断する人もいますし、 わかりやすいようにと、かなりシンプルに仕上げたら 「なんか・・・・簡単な資料だね」と落胆されることもあれば 「いいじゃん、わかりやすいね」といってもらえる事もある。 皆さんにも経験があると思います。 プレゼンの本番前に課長に見せて、「ここはこうした方がいい」と何度かダメ出しを受けて せっせと直した挙句、本番で部長に見せたらコテンパンにダメだしされたとか、結局最初に自分が作った資料の形に戻ったとか(笑) しかもその時、課長は無言を貫き通しているとか(笑) ただ、これはもう、つきものなのでしょうがないですね。 直属の上司である課長の意向を無視して資料は作れないけど、そもそも課長は部長の志向を理解していないので、課長の言うとおりに作ったら、間違いなく部長に怒られるという。 これは組織にいる以上、逃れられない事実なので、ここはもうあきらめましょう・・・。 しかし、かといって、ダメ出し前提で毎回適当に作っていると、 「こいつ、毎回同じこと繰り返すな」と思われるので、ち

さて、チーム内で発生していたコミュニケーション不全は改善の糸口を見つけることが出来ました。 相変わらずリーダーに聞くのは憚られるようですが、 私を仲介して聞いたり、別の人に聞いてみたり、自分で資料を漁ってみたり という事は自分たちで出来るようになったので、プロジェクトの現状を考えれば上出来だと思います。 私が次に直面したのはプロジェクト全体の問題でした。 それは、 4月にカットオーバーを控えているにもかかわらず 1月の段階で新たなテスト環境を用意しようとしている ことでした。 新たなテスト環境を用意するという事は、新たにテストを行おうとしているわけですが（当たり前ですが）、問題は今は1月という事です。 4月カットオーバーを見込んでいるプロジェクトの。。。 正直、狂気の沙汰だと思いました(笑) 今まで、火消ししてきたどの炎上プロジェクトでも聞いたことがありません。 そもそもプロジェクトの全体スケジュールとして、 1月にテストをするという事が決まっていたのであれば テスト環境の準備は11月には着手しているはずです。 それを1月からテストするからその環境を用意しないといけない という話を12月の終わりにし始めている時点で、 完全に思いつき、もしくはプロジェクトリーディングできていない。という事がわかります。 私が他の記事でも書いた プロジェクトリーダーがやるべき2つのタスクができていないことが露骨にわかる事例です。【あわせて読みたい】 プロジェクトを管理するって要はどういうこと？ テスト環境を用意するというのも大変ですが、現時点で既にAチームの作業は逼迫しているので これは自殺行為に近いと考え、入社して一か月にもかかわらず、決裁者に提案をしました。 あまりそういう、変に目立った動きは取りたくない人なのですが、そうもいっていられない事態だと判断しました。 ・そもそも今からテストをねじ込む時間的猶予がない ・テスト環境を準備する時間もない ・テスト環境を用意するとそれに伴う、予定にない作業が大量に発生し、それを受け入れるチームもない という点と 上記のデメリットを考慮した上で、どうしてもテストをやりたければ、現行の環境を代替して、理論値で計測した方が現実的だ という話です。 つまりテストをやりたいのであれば、現行の環境を利用して理論値でやるべきという提案です。 結論はというと

私が転職してまず着手したのは メンバーのやっている作業を一緒にやる でしたが、この作業自体もそう簡単ではありませんでした。 メンバーがやっている作業を一言でいうと 他システムからインターフェースされてくるデータに問題がないかチェックし、問題があればその是正を行う でした。 ただ、そもそもシステム配置が複雑怪奇になっている上、知識の属人化が起きている為、 ・起きているエラーが対処を必要とするものかどうかの判断がつかない ・業務上どうしても起きてしまう事象で、放っておいても翌日には是正されるetc ・エラーの対処をするべき環境が、他システムなのか、自システムなのか判断がつかない ・ 受け入れる側の問題で起きているエラーなのか、発生源システムで起きているエラーなのか判別できていない ・他システム起因のエラーだとして、誰に聞けばいいのかよくわからない という状況でした。 更にそれに加え、プロジェクトの進捗を遅らせない為にリーダーは目の前のタスクをこなすことに夢中になってしまい、メンバーのコミュニケーションは取れておらず、メンバーも 「忙しそうなリーダーには、なんだか質問するのも憚られる・・・」 という状況が発生していました。 コミュニケーション不全に陥っていた。という状況です。 ※今回のリーダーのように作業者として優秀で、かつ自分がハイスペックであることを自覚していない人にありがちなのですが、自分が特別な事をしている自覚がないため 「自分にだってできるんだからみんなできるでしょ？」 という思いで動いてしまうことにより、発生しがちな状況です。 リーダーからするとそんなに難しいことをしているつもりはないので、 すべてのノウハウを口伝で伝えようとし、 簡易なドキュメントにもしないので、メンバーは一回聞いたことを一回で理解しないといけません。 これは普通の人にとってはそう簡単なことではありません。 結果的に、リーダーは同じことを何度も聞かれることになりますし、メンバーも同じことを何度も聞くことに抵抗感を覚えるようになります。 これは私も過去、色んなプロジェクトで見てきましたが 相当やばい状況です。 メンバーがこういう思考になると何が起こるかというと できる限り、質問しないで済むようにするため 起きている事象を、無理やり過去の事象と同一化して、同じ対処をとろうとする というアクション