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

なんとか打てる手を打って、このボロボロのプロジェクトを立て直そうと頑張っていましたが事態はさらに悪化します。 次々と発生する案件に蓋が出来ないので その案件を処理できる体制を作ろうと苦肉の策を打ったところが前回まででした。 前回書いたように、これで状況が解決すると考えるほど楽観主義ではありませんでしたが、 多少の状況改善にはなるだろうと思っていたところ、実際にこれによって 少し 状況は良くなりました。 特によかったのは、プロパー（社員）しかやれないことになっている仕事の1部を 名実ともに協力会社さんにお願いできるようになったという所です。 これまでは、人が足りていようが足りてなかろうが、少ない社員でなんとかせねばと キュウキュウになっていたのですが、これを人に振れるというだけで 精神衛生上、だいぶマシになります。 勿論、いきなり渡しても処理できなかったりするので、実際のところ、負荷は減っていなかったりするのですが いつか楽になるかもと思えるだけで、人は気力を振り絞れるものです。 先の見えない真っ暗なトンネルを歩き続けていると気分が滅入るけれど 向こうに豆粒ほどの光が見えただけで、どこにこんな力が潜んでいたのか？と思うほど、力が湧いてくる そんな効果もあります。 そのように四苦八苦しながらなんとか打開策を打っていたのですが そんな状況にとどめを刺したのは、やはり例のプロジェクトリーダーでした。 この人自身は とても頭がいい人なのですが、やはりリーダーには向いていない とつくづく思いました。 彼がこんな状況のプロジェクトに次に求めたのは 「システムについてプロパーが理解していないのはまずい。 せめて言っていることがわかるレベルには達していないとまずいので なんでも協力会社に投げる前に、自分たちでまずは処理できるように」 といってきたのです。 毎度の事なのですが、彼の言っていることは決して間違ってはいません。 しかし、状況はそれを許していないのです。 人づてに聞いたのですが彼の上司は昔 「あいつは正論で人を潰してしまう」 といっていたのらしいのですが、まさにそれによりプロジェクトが潰されようとしていました。 彼の言っていることは正しい。 私も状況が許すなら同じことを言っていたと思います。 しかし、この状況でそれを言うというのは あたかも 点差がついた試合でどうしても起死回...

キャリア構築を考える上での心構えを一つ書いておこうと思います。 これも経験談になりますが、おそらく嘘は書いていないと思います。 それは 今の自分の実力よりも少し難易度の高い仕事をする。そんな機会が巡ってきたら決して逃してはいけない です。 これを続けないと人は成長できません。 キャリアを構築する＝実力をつける という事を考えた場合、 「自分のできること」という事は、「今までと同じことをする」 という事であるということを強く意識したほうがいいと思います。 よく、 現状維持は退化と同じだ みたいなことが言われますが、まさにその通りで ITの世界は、とどまることなく先へ先へと進んでいきます。 そんな世界の中で、同じことを続けるという事は 時代に取り残される。すなわち退化してしまうという事です。 新しい製品だけでなく、新しい手法もどんどん開発される中 同じことをし続けるというのはキャリア的なリスクとも言えます。 しかし、厄介なことに、背伸びをした仕事をする機会というのは なかなか自分の意思では巡り合う事が出来ず どうしても運に寄る部分が多いです。 （そのチャンスを人為的に作り出すために転職をするという側面もあるのですが） もしそのチャンスが巡ってきたら 勇気を出して一歩踏み出して、新しい仕事に取り組みましょう。 それがまた一つあなたの「できること」に加わるわけです。 それを繰り返すことであなたのできることはどんどん広がっていき、 気が付けば、多様なスキルを持った人材になっているわけです。 ただ、ここまでいろいろ述べてみましたが これは考えてみれば当たり前のことで 将来野球選手になろう！と思ったとしても同じことで まず、 ストレートを打てるようになろう！ と決意して、ある程度打てるようになったとします。 しかし、そこで満足してただひたすらストレートを打ち続けるという事はないはず よし！次はフォークを打てるようになろう 次はカーブを打てるようになろう となるはず。 いやー、フォークは打てる自信がないので、手を出しません。 ストレートなら得意なんですけどねぇ なんて野球選手はいないはず。 だから、これも特別なことを言っているわけではないんですが 何故か仕事になると、強く意識しないと忘れがちです。 チャンスが巡ってきたら、恐れずにチャレンジしましょう！ ちなみに少し話は...

前回の記事に引き続き、 プロジェクトリーダーがシステム導入の際に 運用保守の事も考えて実装をしないといけない という話をしたいと思います。 当たり前といえば当たり前なのですが、 フェーズが進むにつれ、運用保守を意識するシーンは増えていきます。 【テストフェーズ】 テストフェーズの辺りから、頭の半分ぐらいは運用保守の方に使っていかないといけません。 一般的にテストフェーズでは 今迄に検討・作成したプログラムがちゃんと思惑通りに機能するように作られているか？ という点をテストを通して確認するのですが、 「ここまでの流れで、しっかり運用保守の事を考えてプロジェクトをコントロール出来てきているのであれば、運用保守の事を意識するというよりも、設計通りに動くかどうか？に力を集中した方がいいのでは？」 と思われるかもしれませんが、それは違います。 そもそも テストフェーズというのは、「想定通り動かない」という前提で行うもの です。 「想定通り動くはず」なんて意識でやっていると、拾えるはずのバグを見落としてしまう程度のテストケースしか考えないので、そもそもこのフェーズの意味を失ってしまいます。 これと同様に、今までしっかり運用保守を意識して設計を進めてきたけど、 テストフェーズではそれが裏切られると思ってテストを行わなくてはいけません。 どういう事かというと、 設計の段階では機能単体の動きを想定しながら作りこみますが それらを一連の機能としてテストシナリオを考える際に プロジェクトリーダーが想像もしないようなシナリオが生まれていたりするので それをチェックしないといけないという事です。 例えば機能の前後関係のあるOとPという機能があったとします。 要件定義の段階では 機能O→機能Pの順番で処理される という事がわかっています。 各機能を設計する際に 機能OではアウトプットとしてKとLを生み出します。 機能PはLを基にZを出力します。 と設計したとします。 そしてテストの際に 機能Oをまず実行し、Lを生み出します。その後、機能Pが実行され、LからZが出力されます。 というテストケースを考えたとします。 で、このシナリオは終わり。 すると、ここで「 あれ？機能Oで生み出されたKはどうなるの？ 」 という事に気が付きますが、周りの開発者に聞いても、機能Pの前提処理は機能Oしかなく、機能O...

プロジェクトリーダー(以下、PL)は プロジェクト全体を管理し、無事にゴールできるように 様々なタスクをこなさなくてはいけませんが、 その役割はプロジェクトを通して、一定のものではありません。 プロジェクトのフェーズごとにその役割を微妙に変えていかないといかないといけないのですが、そのお話を書こうと思います。 まず、そもそも何故そのようなことをしなくてはいけないのか？という理由ですが それはプロジェクトには大きく分けて、 システムを導入する という事を考えるフェーズと 導入したシステムの運用保守をどうやって行くか を考えるフェーズが 混ざる からです。 コンサルやSierであればシステム導入の事だけ考えればいいのですが 社内SEとなるとそれだけ考えればいいという訳にもいきません。 というか、むしろ導入よりも運用保守している期間の方が圧倒的に長いので そちらの方が重要です。 そして、導入後のイメージを膨らませながらシステム実装する唯一の立場が社内SEであり、それをコントロールするのが社内SE側のプロジェクトリーダーになります。 プロジェクトリーダーを外部の人間に任せてはいけないという大きな理由の一つです。 さて、プロジェクトのフェーズをざっくり分けると以下のようになります。 要件定義フェーズ 開発フェーズ テストフェーズ 移行フェーズ 各フェーズでのプロジェクトリーダーの役割の移り変わりを見ていきます。   【 要件定義フェーズ 】 導入するシステムで実現したいこと、それをどういう形で実現するか？という青写真を描くフェーズです。 システム導入というのは社内SEにしてもそんなに年中やっていることではなく、規模が大きくなるとそれはなおさらです。 ユーザーからすると、そこに輪をかけて稀な経験になり、「How要件定義？」どころか「What要件定義？」という感じになります。 一方、コンサルやSIerはそれを仕事として幾度となく繰り返してきていますので、発注側と受注側において、 プロジェクトの「慣れ」具合に天地の差があります 。 そこを社内SEは埋めないといけませんし、ちゃんと溝を埋められているのか？をプロジェクトリーダーは注視しなくてはいけません。 要件定義フェーズとして定められたスケジュールの中で、きちんと終わらせるためには ある程度スピード感をもって臨まなくてはい...

では、キャリアを構築する為の手段である転職について書こうと思います。 社内SEとして必要な経験値は多岐にわたり その為にはどうしても転職という手段を取らなくては経験できないものがある というのは別の記事で書きました。 あわせて読みたい 社内SEに必要な能力：システム開発における様々な立場の経験 じゃあ、転職する上で、どういう転職をしたらよいのか？を書いてみます。 あくまで経験によるものですので、絶対解ではありませんが一つの参考にはなるかなと思います。 まず、社内SEとして必要なキャリアとして以下のものを挙げましたので それぞれ、どのような場所で経験したらよいかを書いておきます。 1.開発者として 2.システムエンジニア（上流工程）として 3.コンサルタントとして 1.開発者として についてですが、社会人になって初めての会社がその経験の場になると思いますが 初めの会社を選ぶ際に キャリアを考えて選ぶことが出来る人というのはそうそういないと思います。 なので、これについては最初に入った会社が「どうも違うなぁ」 と思った時に考えるので良いと思います。 初社会人でいきなり上流工程に携わることはないと思うので 開発経験は詰めるはずです。 なお、「どうも違うなぁ」というのは「俺はもっと上流工程がしたいのに」とかではなく「ちょっと業界がニッチすぎないか？」とか 仕事をしていく中で、この方向に進みたいなぁというのが見えてきた際に、 このプログラム言語に習熟しても足しにならないかも と思った時です。 もう少し補足すると、例えばwebの業界に進みたいかもと思っているのに、 ひたすら、銀行系の開発案件に入っても意味がないというような意味です。 開発経験を積むという意味では、いわゆる独立系SIerとか技術者派遣をしている会社とかであれば問題ないと思います。 情報システム子会社とかでも大丈夫だと思いますが、 独立系SIerの方が2次請け、3次請けとして仕事をするシーンが多いので そちらの方が最初の経験値としては良いと思います。 逆にいきなりコンサルとかにはいると、開発経験なしで 上流工程をやらされるかもしれませんので、危険だと思います。 いきなり上流工程に組み込まれることで、なんだか選ばれたような気になるかもしれませんが、 これは基礎体力もつけないで、いきなりパルクールをさせられるようなも...

社内SEはITプロジェクトにおいて いわゆる発注側という立場になりますが、 それ故に求められる能力は多岐にわたります。 特にプロジェクトマネジメントやコストコントロールなどをする上では タイトルにあるように様々な立場での経験があるとないのでは 精度が全く変わってきます。 ただ、書いたように様々な経験を満たすことを 一つの会社にいるだけでは難しいので 必然的に転職を何度かする必要があります。 それも計画的に、 できるだけ変な会社に入らないように 。 これを実行するのはとても難しいのですが こういった経験を持っている社内SEは強いです。 どこに行っても使えます。 個人的には必殺のスキルになると考えていますし、 自分が経営者だったら、絶対こういう人が欲しいです。 あんまりわかってない人が多いですが・・・ キャリアをどう構築するか？ の話にも関係するので、 どうやったらそうなれるのか？という話は置いておいて それがあるとどういいのか？について書いていきたいと思います。 開発者としての経験 社内SEとなった時、何に役に立つか？ システム導入の際にザックリとした費用感を出すことを迫られることが多いのですが、 その際の根拠になります。また、実際にプロジェクトが進む際に、 ベンダーが出してくる見積もりの妥当性チェックにも必要です。 具体的には？ 開発という作業に何が必要か？そしてそれを行う時にどういった所に時間がかかるものなのか？ どういう所にバッファ（余裕）を織り込むのか、リスクと考えるのはどういう所か？ という事がわかります。 これがわからないと、ベンダーが過剰に乗せてきた見積もりに対して突っ込むことが出来ませんし、逆に値切りすぎて、無理なプロジェクトを構成してしまったりします。 要は妥当な落としどころがわかりません。 システムエンジニアとしての経験 社内SEとなった時、何に役に立つか？ ここでは上流工程、いわゆる設計や要件定義をする人と定義しますが、 プロジェクト全体のスケジュール感覚が養われます。 工程の漏れがないか？スケジュールとして無理があるものに仕上がっていないか？ という事が検証できるようになります。 勿論、これも見積もりの際の妥当性の根拠になります。 具体的には？ プロジェクトには様々なフェーズがありますが どのフェーズで何をしようとしているのか？その期間...

さて、前回までの話で 減ることなく増え続ける会議に対しての出席を強要され その回避策として、私にすべての会議を集約する という手段を取ったわけですが、その結果 私の時間はすべて会議に埋め尽くされることになりました。 これは誇張でも何でもなく、本当に朝から晩までずっと会議という状況です。 かろうじて空く30分とかは、各種設計書やテストのレビューで埋められ 本当に一切の誇張なく、私は定時内（もしくは定時後も）ただただ人の話を聞く、 もしくは人に報告をするだけの人になっていました。 これにより何が起きるかというと 自チームのタスク管理ができず、チームの負荷コントロールが出来ない 業務知識をキャッチアップする時間が取れないので、いつまで経っても知識が追い付かない 感覚的にチーム全体が過負荷になっていることはわかるが、案件の発生を止めることができない というようなことが起き始めます。 発生する案件の処理自体は導入から入っているコンサルティングファームに任せていたのですが 彼らも運用保守が素人という事もあり、ユーザーが言ってくるものを すべてそのまま受け入れようとするためリソースと案件のバランスが取れなくなっていました。 コンサルのリソースはコンサルのリーダーに任せている為に、 受け入れているという事は大丈夫なのだろう と思っていましたが、単に断る術を持っていないだけでした・・・ この為、 リソースに限りはあるが、Inputはどんどん増え続け 私もキャッチアップの時間が取れない為、戦力にならず リソースの拡充もできないから、メンバーの首がどんどん締まっていく・・・ となり、状況の悪化に歯止めがかからなくなっていきました。 本当は私的にはまず、 新たな案件の発生を止めたい それが出来なくても、優先度をつけ、現状のリソースで処理できるスピード感で順次処理できるようにしたい という思いがありましたが、 なにしろ、会議に出ているだけで、業務知識が一切つかないので ユーザーの出してくる案件の優先度をつけることが出来ません。 そもそもユーザーというものは 出してくる要求はすべて最優先 というような口ぶりで振り出してくるのですが ちゃんと話を聞いたらそこまで急ぎではないものや 整理をしたら後回しにできるものがごちゃ混ぜになっていることが多く、 そういったものを取捨選択したり、ユーザーと折...

これもITプロジェクトあるあるなのですが これまでにも何度も言っているようにITというものは「 ツール 」です。 その為、手段ではあっても目的には通常なりえません。 にも関わらず、何故かITプロジェクトがスタートを切ってから、 何をしたいか考え始めたりすることが多いです。 ツールを先に決めて、そのツールで何をするかを後で検討するという状態ですね。 プロジェクト開始前にはものすごく大雑把な方向性だけが決まっていて 予算と規模感だけで製品選定に入り、プロジェクトスタート！ スタートしてから、 じゃあ、どうする？＊＊するって言ってたけど、具体的にどうやるの？ みたいな話になることを、今まで幾度となく見てきました。 面白いことにITのプロジェクトでは、 この要件定義の手前の段階の話を検討するフェーズは設けられません。 なのに、プロジェクト開始前に検討しないで、 プロジェクトはスタートするという摩訶不思議なことが頻繁に起こります。 （これはコンサル側の思惑もあると思いますが・・・） また、これとは別に、息の長いプロジェクトの途中でだんだん目的を見失って、 カットオーバー直前には「導入すること」が目的にすり替わってしまう という事もまま起こります。 いずれも「やりたいこと」と「そのためのツール」の立ち位置が 逆転してしまっているのですが、プロジェクトの開始前に 「ITを使って何をしたいのか？するべきなのか？」をしっかり検討しないまま プロジェクトスタートに踏み切っている時点で、目的を見失う種は植えられていると言っていいと思います。 そういう意味では、 そもそもITプロジェクトのスタートがどこからなのか？ という事を、はき違えている人が多いのかもしれません。 そもそも論ではありますが、プロジェクトを立ち上げる前には 自分の会社で困っている事 これがあるはずです。 これがあるから、 解決しないとまずい につながり、 じゃあ、ITで何とかしてみようか と続くはずですが、この最初の 自分の会社で困っている事 をしっかり意識しない、もしくはプロジェクト終盤まで見失わない という事が出来ていない為、 最終的に「 システム導入が目的 」となってしまうわけです。 IT導入を始める前に、まずはここをしっかり落とし込まなくてはいけません。 例えば単純に システムが老朽化したので新しくしないとい...