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

社内SEとして働いている人にとって、頭を悩ませる一つの大きな問題が シャドーITといわれるものです。 【シャドーITとは】 企業の情報システム部門が管理していないITの事です。 主に小粒なものが多く、例えば経費精算システムなどの規模以上になると情報システム部門が知らないうちに導入されることなどはないと思うのでこれは該当しません。 一方、現場でエクセルに詳しい人が作ったエクセルマクロなどは、まさにシャドーITの代表となります。 モノによってはウナギ屋さんのタレのように、歴代の担当者が手を加え続けて、複雑怪奇なものになっていたりします。 さて、このシャドーITが情報システム部門の何を悩ませるか？ というと ・メンテナンスできない という一点に尽きます。 情報システム部門が作ったシステムにおいては必ず以下のものを作ります。 ・要件定義書 ・仕様書 これは このプログラムは何を目的としたもので、どういう風に作られています という説明書のようなものです。 プログラムというのは、専門家であるエンジニアでも その動きだけを見て、中身がどうなっているかを把握するのは困難です。 それは新しい家電を渡されて、取説もなしに使いこなすように言われるのと同じです。 なんとなくこれでいいのかな？ぐらいまではわかるかもしれませんが それが本当に正しい使い方なのかはわからない という状況になります。 その為、例え自分が作って、自分がメンテナンスしていくものだとしても、 必ずこういった書類を作ります。 自分がメンテナンスする際の備忘としても使いますし 別の人がメンテナンスする際には、これがそのプログラムの作りを知る為の 手掛かりとなります。 しかし、シャドーITは言ってしまえば素人が作っていますので こういった書類が作られることはありません。 よしんば作られたとしても、メンテナンスされることはほぼ0%です。 シャドーITの困ったところは なんらかの理由で動作しなくなったときに この状態で突然、情報システム部門に持ち込まれるという所です。 こういう場合、ユーザー側からすると 前任者から仕事をする上でのツールとして渡されて、深く考えずに使っていたけれど、ある日突然動かなくなって、仕事に支障をきたしている。 しかし、自分からすると何がどうなって動いているのかわからないツールなので、こういうものは情報システ

さて、システムがカットオーバーし、品質にはいろいろと問題はあるものの なんとかシステムは止まらずに動いています。 しかしながら、またしても問題が起きました。 今回カットオーバーしたシステムは2つあるのですが ここではそれぞれを仮に ・Bear ・Fox とします。 私がこれまで問題にあたっていたのは Bearの方でした。 そしてこのBearのリーダーは 「もうこんなプロジェクトは嫌だ！カットオーバーした暁には抜けさせてもらいます！」 という事で、抜けることになっています。 （気持ちはとてもよくわかります。優秀な人だっただけに残念です。） これもこれで問題なのですが、 じつはこれにさらに拍車をかける問題として、 なんと Foxのリーダーもいなくなる という事がわかりました(笑) つまり、カットオーバーしたばかりの2つのシステムのリーダーが ほぼ同時期にいなくなり、システムに精通した人間が誰もいなくなる という、非常事態に陥ってしまったという事です。 Bearの方はリーダーがいなくなるという事が、ある程度前もってわかっていたので これまでの仕事の中でなんとか現状の運用保守はできる状態までは持っていけていたのですが、Foxの方はそもそもチームに人がいなかった為、 リーダーが全て知っている。 リーダーしか知らない。 これが常態化しており、受け取る相手もいないので引き継ぎのアクションも取っていません。 準委任契約でコンサルティングファームがいたので、 なんとか運用保守はできますが、そのままの状態ではコストがかかりすぎて いつまでたっても、導入にかかった費用を取り戻せませんし、 経営がそれを許すわけがありません。 ただ、この状態になるまで放置していた時点で経営にも責任はあると思います。 Foxというシステムはかなり重要度の高いシステムなのですが ・慢性的な人員不足による属人化 ・高負荷によるメンバーの消耗 というような状態を放置しておけば、 人が抜けていってシステムが回らなくなる状況というのは想像に易いはず。 そうなって困るのは他でもない経営です。 さて、話は戻って 会社としては誰かをFoxのリーダーに据えなくてはいけませんが みんなFoxのこの状況は知っているので、やりたがる人はいません。 しかし、だからといって誰もやらないという訳にもいきません。 一旦、ここでFox

今回は出向について、特に親会社から子会社の社長としての出向について書いてみます。 親会社から子会社への出向 という話はよく聞くと思いますが その形は様々ある中で、一番よくない、もしくは一番難しい と思うのは社長の出向です。 これが何故難しいかというと 1.子会社の利益と親会社の利益が相反することがある 2.社長が定期的に変わることにより、子会社の方針が定まらない この2点が特に大きな問題だと考えます。 1.に関して 親会社と子会社という関係上、両者間で取引があることが多いと思いますが これを、 『親会社が子会社から仕入れをしている』 という単純な例で言うと 子会社の利益を増やしたければ、親会社に高く売りたい 親会社の利益を増やしたければ、子会社から安く買いたい という利益の相反が発生するわけです。 このような状況が発生した際に方向性を決定づける社長が親会社から出向している場合、戻った後（出向解除）の事を考える人が多い為、後者の選択をしがちだという事が問題です。 これが続けば、 子会社の利益は圧縮され続け、子会社にいる人間の環境はどんどん悪化していく ということは容易に想像できるのですが、何故かこれを他人事のように捉える社長が多いのではないでしょうか。 子会社に社長として出向する場合、その人には大局的な視点を求められるはずですが、 往々にして、親会社における キャリアの通過点 （社長を経験するという）ステップの一つ というような、近視眼的な捉え方しかしない人が多いように思えます。 しかし、よくよく考えると（よく考えなくても？）上記のような事をしてしまうと、子会社の人材は流出し、会社のパフォーマンスは低下し、競合他社に負けてしまう事になります。 それはグループ全体としては不利益を招きこんでいることになるわけです。 親会社から子会社の出向で社長となるのであれば、むしろ連結の利益を意識することが出来る立場なので、グループとしてどうなのか？を考えないと、出向で社長をしている意味がありません。 にもかかわらず、何故か「俺は何々部長（親会社）とツーカーだから、話が通しやすいからな」というような、非常にちっぽけなメリットを声高にしゃべっている社長の多い事。 （そもそも親会社と交渉するのに、そんなコネがないとうまく行かないという時点で異常だとは思わないのでしょうか？身内のはずでは？）

さて、色々なことに巻き込まれつつ 運用設計も終え、山積したチーム内の問題にも対処しつつ、 このプロジェクトもカットオーバーに近づいていきました。 正直、この時点で このプロジェクトはカットオーバーする品質に到達していない というのが私の中の結論でしたが、プロジェクト全体としては 何が何でもカットオーバーするという流れで進んでいました。 あるあるではありますが プロジェクトの目的が「カットオーバー」になり、 システム品質の話が二の次になっている時点で 炎上プロジェクトかつ、失敗プロジェクトなのですが 入社したばかりの立場でこれを止めることもできません。 そしてそれは、プロジェクトをカットオーバーさせるかどうかを決める リリース判定基準がいまいちあやふやな所にも表れていました。 本来、リリース判定基準とは 明確に数値化されたもの 誰が見ても誤解のしようのないもの プロジェクトとして必達となっているもの 等が掲げられているものなのですが、やはりプロジェクトの目的が 「カットオーバーすること」 になっていた為、関係者もそのあたりを考慮したのか・・・・ 必達の目標を明文化してしまうと もしかするともしかする可能性があったのでしょう。 システムが止まらないで、それなりの結果が弾き出されること というような、非常にあいまいな判定基準が掲げられていました。 ただ、この「もう何が何でもカットオーバーする！！」という方向性が 私個人にとって全くメリットがないか？というと、そういう訳でもありませんでした。 本来であれば、こういった不完全なシステムがカットオーバーされると それを保守していかなくてはいけない立場からすると 「そんな中途半端なもの、リリースしてくれるな」 という事になるのですが、 そもそもこのプロジェクトはここに至るまでにもう何年も経過していて しかも前の記事で述べた通り、チームリーダーが独断専行しなくては前に進むこともできない。 そんな状況です。 【あわせて読みたい】 Stories　2話：コミュニケーション不全 よって、このプロジェクトには、何年もの間に蓄積された このチームリーダーしか知りえないことが数多く潜んでいます。 なんでこんな機能があるのか？ なんでこんな回りくどい仕様になっているのか？ など、本人に直接聞かなくてはわからないような話がてんこ盛りになっている上、

最近、本を読んでいてよく見る言葉として、 心理的安全性という言葉をよく見ます。 簡単に言うと「チームは対人リスクをとるのに安全な場所であるとの信念がメンバー間で共有された状態」という事ですが これは本当に大事な話で、私自身もチームを運営するときに意識をしていたことだったなぁと思ったので、記事にしてみました。 この記事を書いている現在、コロナの影響で企業のリモートワークはかつてないスピードで進み、こういった所謂ニューノーマルな働き方に積極的に取り組んでいる会社は「あれ、意外と直接顔をあわせなくてもいけるな。」という気づきに恵まれているところも多いと思います。 また、それにより様々な可能性も見出していると思います。 ただその一方、直接会わないが為に自分が言ったことに対して、みんなどう思っているんだろう？という空気感が読めず、不安な気持ちになることもあると思います。 そんな時に大事なのがこの 心理的安全性 です。 勿論、これはオールドノーマルの中でも非常に重要ですが、 ニューノーマルの中ではまた違った意味で重要になってきます。 オールドノーマルでは臨場感がありすぎるために、必要になる（パワハラを防ぐ）のですが ニューノーマルでは距離感がありすぎるため、メンバー同士でどこまで心を許せているのかが測れなくなります。 距離感が測れないと、何かの意見を募ったときにそれがメンバーの合意をどこまで取れているのか、その合意がどこまで本心なのか？という事がわかりません。 それはつまりチーム内の合意形成を図る上で、チームとしてどこまでの本気度で臨んでいるのか？が測れないという事になります。 これを「決めきれないリーダーの責任転嫁」として取るのは早計です。 （そういうリーダーが多い事は認めますが） 逆に、 チームでの決め事を「リーダーが全て決める」というやり方はチーム運営において非常に危うい状態 です。 そのような運営をするのは強権を振るうリーダーに多いのですが メンバーは 「リーダーが言うならそれでいいんじゃない？」 という判断の基、 「とりあえずリーダーの方針がこうだから、全部右に倣えしとけばいい」 という流れになり、本当であれば事前に気が付けたことを見落としてしまい、 リスクを見落としてしまうことにつながります。 これは他の記事でもあったような事態を招きます。 【あわせて読みたい】 S

今日はチームメンバーから一つ相談を持ち掛けられました。 その内容は ・開発チームのメンバーのフラストレーションがたまっているので話を聞いてやってほしい というものでした。 現在、私が携わっているプロジェクトの構成としては 【発注側】 私のいる社内SE部隊 【受注側】 ・コンサルティングファーム ・SIer という形なのですが、この中のSIerで構成されている開発チームが悲鳴を上げているという事でした。 私が加入する前からこのプロジェクトはコミュニケーションロスが多く、 それによって、様々な立場の人がやらなくていい事や しなくていい苦労をしているというのは聞いていたので、 私ができることであれば何とかしてあげたいとは思っていました。 ただ、開発については私とは別に開発管理者がおり、私が軽々に首を突っ込むこともできない上に、それについて訴えてくる人もいなかった為、具体的に誰が何に苦しんでいるのか把握できなかったのですが、ようやく話が聞けそうでした。 私が話を聞いた相手はSIerの開発チームリーダーですが 今回の話は コンサルティングファームの開発チームに対する要求がひどい という話でした。 具体的にどう「ひどい」のかというと、 コンサルから流れてくる案件は開発期間が異常に短く、それをリカバリーするために開発チームは土日出勤対応などもしている。こう言った状況が慢性的に続いていて、メンバーも疲弊しているという事です。 ちなみに、コンサルと開発チームの関わり方は以下のような形で 要件定義：コンサル 基本設計：コンサル 開発：SIer 単体テスト：SIer 受入テスト：コンサル 内部結合テスト：コンサル みたいな形になっていて、コンサルの担当している要件定義、基本設計が 往々にして遅れるという事です。 そして、その遅れに対して何故かSIerが担当している 開発と、単体テストの納期を短くするように言ってくるらしく それに応えるために、無理な働き方をしているという事です。 開発チームのリーダー曰く、 コンサル部隊は開発経験が乏しく、開発にどれだけ工数がかかるかが全く分かっていない上、仕様も固まらないまま、開発に投げてきたりするので、蓋を開けてみたら全然話が違う という事も多く、相当振り回されているという事です。 これが事実だとしたら困った話です。 開発部隊がダウンしてしまったら、ほ

過去の記事に書きましたが 【あわせて読みたい】 システムの運用保守の難しさ：初めに システムは導入だけではなく、運用保守も非常に大事な仕事です。 導入チームと保守チームという形で IT部門内の役割を分けている会社でありがちというか見落としがちなんですが 運用保守に入っても、大規模案件は動きます。 （当たり前ですが） これは運用保守をやっていく中での難しさの最たるものとも言えます。 運用保守として細々した案件対応を行いながら 息の長い大規模プロジェクトが動き出すとどういう事が起こるかというと、 ①大規模案件で変更をかけようとするオブジェクトと、運用保守で触らないといけないオブジェクトが重複する。 （※ここで言っているオブジェクトというのはプログラム等の事を言います。） これは代表的な現象で、大規模プロジェクトでも、運用保守でも同じシステムを触っている以上、同じオブジェクトを触るというタイミングが必ず発生します。 問題は大規模プロジェクトはそのオブジェクトを拘束する時間が長いことが多いという事です。 例えば大規模プロジェクトで、ある機能Aに修正を入れることになったとします。 修正を入れることが決まったのは4月ですが、修正にはかなり時間がかかる為、完了するのは6月という事がわかっています。 しかし、一方同じ機能Aに対し、運用保守の方で5月に不具合が発見されたので、すぐに修正を入れないといけなくなりました。 しかし、上に書いた通り、機能Aには4月から大規模プロジェクトの方で修正が入っているので、すぐには手を入れることはできません。 こうなった場合、どうするか？という事を運用保守チームは常に考えさせられることになります。 やり方の一つとして、大規模プロジェクトで入れていた修正を一旦なかったことにして（修正前の状態に戻す）、その上で不具合の修正を入れる。そして、不具合の修正が終わった後に、再度大規模プロジェクトの修正を入れるというやり方もありますが、これもそう簡単ではありません。 不具合修正前に入れていた大規模プロジェクトの修正は、不具合修正を入れた後では違ったやり方をしなくてはいけないかもしれないからです。そしてそれは往々にして起こります。 こうなると当初、不具合が発覚する前に見積もっていた工数を大幅に超過して、予算を圧迫したりしますし、この対応により、また違った不具合を招い