株式会社アイアイシー I.I.C.Inc., 取引先の皆様へ 個人情報保護方針 サイトマップ

株式会社アイアイシー 会社概要

弊社代表プロフィール

弊社代表のプロフィールです。
今までのエンジニアとしての実績、何を目差して起業したかなど、
当時の記憶を辿り、時系列で書いてあります。
少しでも、代表の「人となり」が伝わればと思っています。

平松二三生

アイアイシー代表取締役会長
システムエンジニア / プロジェクトマネージャー / ITコンサル / 心理カウンセラー


IT業界一筋18年。その間、数々の輝かしい実績を挙げてきた(詳細は後述)。
19歳でIT業界に。3年間のサラリーマン時代を経て、22歳でフリーエンジニアに転身。
28歳でアイアイシーを設立。現在に至る。
36歳で「心理カウンセラー」の資格を取得。

■講演実績:
・常時〜社内研修講師
・2006年11月 デジタルハリウッド株式会社
  「90分で分かる『成長できる会社』の選び方」
弊社代表 平松二三生

 

代表取締役会長のブログ好評稼働中です。下記バナーをクリックしてご覧ください。

好評稼働中! アイアイシー社長平松のブログ 「社長部門」ランキング1位獲得

2007年1月 「人気ブログランキング」の「社長部門」において1位を獲得

 

昭和45年 3月 愛知県豊橋市にて生誕
平成元年 4月 独立系のITアウトソーシング会社に就職(19歳)
平成 3年12月 上記会社を退職
平成 4年 1月 フリーのエンジニアとして活動開始(21歳)
平成 7年 4月 某生命保険会社の大規模プロジェクトでマネージメントを経験(26〜28歳)
平成10年12月 有限会社アイアイシーを設立(28歳)
平成11年 4月 某信販会社の経理財務システムを受注(29歳)
マネージメント補佐として、プロジェクト遂行に尽力
平成13年 9月 某生命保険会社の契約管理プロジェクトを受注(30歳)
平成14年 8月 同生命保険会社の料金システム保守を受注(31歳)
混乱していたプロジェクトをマネージメントし、正常化。
平成15年 3月 1000万円に増資後、株式会社に組織変更(33歳)
平成17年11月 同生命保険会社の資源管理システムを受注(35歳)
他社にて約1年がかりで開発をし、稼動させられなかったシステムを、
2ヶ月で仮稼動、半年で本稼動まで達成。現在は保守を担当。
平成18年11月 心理カウンセラーの資格取得

≪ITアウトソーシング会社に就職〜サラリーマン時代≫

所属していた会社が「発展途上」で、「人数が少なかった」ということもあり、
社会人1年目(サラリーマン時代)の終わりごろから、
担当プロジェクトのサブリーダーになっていました。
同期の2名を管理しつつ、プロジェクトを遂行していました。
当時でも、「19歳という若さでマネージメントを担当する」というのは
「異例中の異例」だったと思います。

≪退職〜サラリーマン時代の終わり≫

小規模ながらもサブリーダーの経験を活かし、3年目には小規模のプロジェクトでありながら
リーダーを務めることになりました。
しかし、そのプロジェクトが失敗してしまいました。

原因としては、当時、営業と契約を担当していた上司が再三の申し出にもかかわらず、
対応しなかったというのが主なもので、自分自身にはほとんど責任がありませんでした。

責任 私としては、リーダーを務める以上、自分自身の落ち度もあり、
責任を問われるものと思っていましたが、全くそれがありませんでした。

また、やはり、私自身としては「反省の意味を込めて、問題を総括したい」という
気持ちもありましたが、そのことに関しても、一切触れられなかったもあり、
会社との「問題意識の差」に、次第に違和感を持ち始め、結局は退職を決めました。

思えば、「3年弱」という短いサラリーマン生活でしたが、
今の「自分自身の基礎」を作ったともいえる貴重な時間でした。

閉じる

≪フリーのエンジニアとして活動開始≫

サラリーマン時代を終え、今度は「フリーエンジニア」としての活動が始まりました。

私が「フリーエンジニア」を目指したのは、サラリーマン時代に感じた「責任に対する意識の希薄さ」
という違和感から、「自分自身が全ての責任を担う存在になりたい」という希望があったことと、
今にして思えば、「天狗になっていた」と感じられても仕方が無いのですが、
「自分は仕事が出来る」という自負が大きかったので、
「会社に守られている状況ではなく、自分自身の力を試したい」という
欲望があったからでした。

バブル崩壊 しかし、現実はそんなに甘いものではありませんでした。
・・・というのも、その当時は「バブル崩壊直後」。
本当に仕事がありませんでした。

実際、「IT業界の優秀な人材は新しい活躍場所を探し、他業種へ・・・」などということが
起きていましたし、エンジニアにとっては非常に厳しい時代でもありました。
おそらく私1人の力ではどうにもならなかったと思います。

当時はまだ、今ほど労働市場はオープンではなく、「フリーエンジニア」で活動している人は
少なかったと思います。
そんな状況下で、しかもバブル崩壊により仕事が無い時代に・・・
「年齢22歳キャリア3年のフリーエンジニア」に仕事を依頼するはずもありません。

チャンスを与えるそんな中、ある1人の社長さんが私の厳しい状況を救ってくれました。

その社長さんは「キャリアも少ない」、しかも「フリーエンジニア」という、
どちらかと言えば「リスクの高い」であろう私に「チャンス」を与えてくれました。
おかげさまで、その「チャンス」を活かし、その後は順調にキャリアアップすることが出来ました。

確かに私自身としても「与えられた仕事は相手の望む100%以上のクオリティで臨む」という
気持ちで仕事をしていましたので、客先にも評価されました。
しかし、「チャンスが無かったら」、それも叶いません。

チャンス ですから、その社長さんには「特別な感謝の気持ち」を持っています。
しかし、私が恩返しをする機会を与えてもらえず、まだこれからという年齢で
お亡くなりになってしまわれました。

「自分はチャンスを与えられた・・・」というこの体験が、
今の「若い人達にチャンスを与えたい」という、 私自身のモチベーションになっています。
叶わなかった「恩返し」の意味も含めて。

閉じる

≪某生命保険会社の大規模プロジェクト≫

サラリーマン時代の所属会社から紹介してもらった「お仕事」でした。

思い出深い仕事 通常は退職した会社さんからお仕事をいただくというのは、あまり前例が無く。
私自身としては「縁」を大事にしていたので、そういう意味では非常に嬉しく感じました。
そのため、非常に「思い出深い仕事」となりました。

・・・・しかし、「思い出深い」のはそれだけでは無く。
この「お仕事」は、ボクのエンジニア人生の中でのかなり悲惨なものとなりました。

私が担当していたのは、エンドユーザー側のシステム検証という役割でした。
当時、システム開発を担当していたのは、外資系の某コンピュータメーカーでしたので、
私の仕事は、彼ら作業していた設計フェーズや開発フェーズの納品物を検証するという
ものでした。

当初、私が担当していたのは、契約管理システムの中で、比較的大きなサブシステムの1つ
である「新契約システム」という「システムのほんの一部」で、
それを開発側で担当しているのは「5〜6人程度」という規模のものでした。

しかし、プロジェクトは遅延続きで、大混乱してしまい、「新契約システム」全体の開発管理を
する必要がありました。
大規模のシステム開発ですから、誰も責任を取りたがりません。
そこで、私自身が「その任を担当する」こととなりました。

それは、私自身がそのプロジェクトに参加してから、1年数ヵ月後、システム稼動まで半年しか
残されていない時期でした。
それから半年間はかなり地獄のような状況でした。

新たに担当することになったのは「新契約システム」のおよそ「2/3」の規模で、
開発担当者の数に至っては「50人程度」の規模となっていました。
つまり、いきなり「50人規模のプロジェクトマネージメントを27歳のエンジニア」が担当することに
なったのです。

通常であれば、開発者の納品物を検証するだけで良かったのですが、プロジェクトは大混乱しており、
まともな納品物は望める状況ではありません。
しかも、稼動半年前だというのに、システムのほとんどが正常に稼動できる状況ではありませんでした。

マネージメント業務 ですから、それから半年間は
「進捗管理」「障害管理」「品質管理」「報告業務」「客先調整」と、
全てのマネージメント業務を1人でこなしました。

しかも、実際にプログラム開発を担当していたのは「その年次の新人」や
「2年目」「3年目」といった若手のエンジニア達でしたので、品質を保つために
「彼らの教育」や実際の開発の指導も行わなくてはいけませんでした。

そして稼動予定日になり・・・・。
半年前に正常に稼動できなかったシステムは、無事稼動することが出来ました。

システム稼動 おそらく、私がマネージメントを担当し出した時期には、
「半年後に稼動出来るとは、開発を担当している誰1人信じてなかった」と思っています。
私1人を除いては。

私自身としては、非常に苦しいプロジェクトとなりましたが、
通常、「26〜28歳」という時期では、おそらくまず不可能であろう「プロジェクトマネージメント」の経験を
積むことが出来たのは、私の中でとても活かされています。
マネージメントとしてのノウハウを確立したのもこの時期ですね。

閉じる

≪有限会社アイアイシー設立≫

私が会社を立ち上げようと考えたきっかけは、前述の「某生命保険会社の大規模プロジェクト」での
出来事でした。

個人でできる範囲の限界このプロジェクトにて、私はマネージメントという分野に本格的に足を踏み入れました。
その際に一番感じたのは「個人で出来る範囲の限界」でした。
プロジェクトを遂行する上で、やはり一番大事なのは、
「個人を纏め上げ、組織にする」ということ。
いくら「特定の個人のスキルが高い」と言っても、プロジェクト遂行は難しいものであるというのを
実感しました。

次に感じたのは「コンセンサスの難しさ」でした。
いくら「正しい道を選択して」しても、それに賛同して、実行してもらうのは、非常に困難でした。
前述のプロジェクトでは、混乱しすぎていて、「私自身の発言は絶対」という状況に置かれて
いましたが、それでも「意識を統一する」という行為はとても難しいものであると感じました。

最後に「教育の大切さ」。
前述のプロジェクトでは、開発を担当くださった方々は非常にモラル高く作業してくださいました。
しかし、プロジェクトを遂行するため、また開発行程をスムーズに進めるノウハウというものが
全く確立していませんでした。
生意気なことを言わせてもらえば、私よりキャリアを積んでいる人ですら、ノウハウが少なかったと
感じました。

その中で、私が直接指導していた若手エンジニアは「目ざましい成長を遂げました」。
やはり、きちんと「教育を施せば、人は成長する」というのを肌で感じた瞬間でした。

これらのことから、「自分と同じ目的意識を持って仕事を遂行してくれる組織」があれば、
もっと多くのユーザーにより良いシステムが提供できるのでは無いかという考えが浮かびました。
それが起業のきっかけです。

また、起業にはもうひとつ理由がありました。
せっかく手塩にかけて教育した開発メンバーでも、結局は違う会社さんのメンバーなので、
プロジェクトが解散してしまえば、私の手元を離れてしまいます。
それが「ちょっともったいなかった」という理由もありました。

IIC-Web起業時は、坂本取締役(当時は社員)と2人でもスタートでしたので、
「身の丈にあった会社にしよう」ということで、有限会社からスタートすることにしました。

・・・そして、平成10年12月、アイアイシーの歴史は始まったのでした。

閉じる

≪某信販会社の経理財務システムを受注≫

きっかけ

アイアイシーという会社組織になり、最初に受注したのが、このプロジェクトでした。

「フリーエンジニアのときにお世話になった社長さんが紹介してくれた仕事だったから」
というのがこの仕事を選んだ理由です。

直前のお仕事(生命保険会社)は、サラリーマン時代に所属していた会社さんからに
紹介してもらったお仕事でしたので、この仕事が終わるまでの間は、
お世話になった社長さんの仕事を担当するやることが出来ませんでした。

約束「この生命保険の仕事が終わったら、また社長の仕事をやります。」
私はそう約束していましたので、それを守りたかったというのが大きかったです。

それと・・・。
「会社になってから初めての仕事はお世話になった社長から」
という思いも強かったです。

閉じる

遅延していた業務を担当

実際の仕事はというと。
担当したのは「経理財務チーム」の「決算業務」と言う部分でした。

プロジェクトに参加したときには、周りのチームがいわゆる「内部設計」を始めている時期なのにも
かかわらず、私の担当部分は「要件定義」もままならない状態でした。
スケジュールでいうと、単純に言えば、「他のチームより3ヶ月遅れ」という状況でした。
つまり、「お荷物」を引き受けたということです。

実は、このプロジェクトに参加する前に、慣例として行われる「事前面接」で、
私自身はこのプロジェクトを率いているリーダーと口論をしました。

そのリーダーさんは「技術には自信があるか?」と聞かれたので。
(実際はもう少し細かい話でしたが)。
私は「自信はあります。」と答えた後に、こう切り出しました。
「しかし、私は技術がバックボーンであって、一番重要なことでは無い」と。

そのリーダーさんは「技術がいかに大切か」ということを語り始めました。
ただ、当時私も若かったので、
「そんなことは当たり前。私たちの仕事はその技術を使って、いかにいいシステムを作るかが重要」
とお互いの意見は平行線になりました。

面接終了後、「これはこの面接落ちたな」と思ったのですが、
その状況を見ていた、口論したリーダーの上司である「統括リーダー」が私を強く推し、
この仕事をすることになったという出来事がありました。

その「統括リーダー」は当時「お荷物」であった「決算業務」を私に任せれば何とかしてくれると
いった思惑があったようです。

その後も、その「統括リーダー」とは仲良くさせていただき、当時のそのチームの中では
若輩者であった私に対し、たびたび意見を求め、それに答えるという間柄になりました。

そんなことがあり。
数ヶ月の遅れが発生している業務を担当することになったのです・・・。

平行作業 まずは最初の数ヶ月で、遅れていた作業(「要件定義」「外部設計」「内部設計」)をまとめて、
並行作業で行いました。
「決算業務」そのものは、業務としては難しいのですが、システムとしては
それほど難しいものではありませんでしたので、何とか対応できました。

とはいえ・・・普通のやり方では不可能であったとは思います。
通常であれば、順を追ってやらなければいけない作業を、全て「並行作業」という形で行う訳です。
プロジェクトでは、それぞれフェーズ(段階)において、提示された手法で作業を行う必要があります。
しかし、私たちが担当した時点では、それをやっていたのでは、とても間に合いません。
ですから、私は「プロジェクトから提示された手法」について、ことごとく無視しました。

優先順位 単純に「無視をした」訳ではありません。
提示された作業内容を私自身で判断して、今の状況と見比べた上で
■「やる必要が無い」
■「やる必要があるけど、今やらなくても良い」
■「すぐにやるべき」
という風に「優先順位」をつけた・・・それだけのことです。

しかし、結果として「すぐにやるべき」という作業はあまり無かったですけどね・・・。

閉じる

「仕事で大事なのはモチベーション」

その後、色々遅れはあったものの、開発に着手することになりました。
ここでまたひと騒動がありました。
開発者、つまりプログラマが足らない・・・。

若いエンジニア 通常であれば、プログラマというのは、経験が比較的少ない
「若いエンジニア」が担当します。
しかし、その「若いエンジニア」を確保するのが難しい状況でした。
ですから、その時期に「プログラマとしてプロジェクトに参加する人」には、
色々なキャリアを持った人がいました。
■年齢の割にキャリアが短い人
■IT業界をしばらく離れてブランクがある人
■明らかに挙動がおかしい人

そこで、前述の「統括リーダー」が聞かれました。
「平松君、キミのところではどんな人材が欲しいかね?」と。

私はこのとき、「統括リーダー」を驚かせようと、ある秘策を考えていました。
ボクは当時の状況からすると、かなり無謀なことを言っていたと思います。
「どんな人材でもいいです。使いこなす自信があります。」

実は、これには「裏」がありました。
先ほども言いましたが、私たちが担当していた「決算業務」はシステム的にはそれほど難しく無いと
いうことがあったのと、当初から開発をスムーズに進められるように、「シンプルな設計」にしていました。

CAD それは「どんなプログラマが開発しても、ほぼ同じプログラムが出来る」というもの。
この点を、かなり意識して行っていました。
従って、前述の発言には「私なりの勝算」があった訳です。

但し、正直言って、私たちが行った設計手法については、
当時のプロジェクトの意向を相当「無視」した形となっていたと思います。
しかし、私なりに「稼動後のメンテナンスのしやすさ」や「情報共有のしやすさ」といった
自分自身が「今まで培ってきたテクニック」はふんだんに盛り込んだつもりです。

これは、後々分かることですが・・・。
実は、「その後の法改正」や「組織変更」などでメンテナンスを行うとき、私たちが担当した「決算業務」が
「一番工数が少なくて済んだ」そうです。

これは、この「設計」があったからこそなんですね。

開発者 話は戻って・・・。
先ほどの私の発言もあって、開発者として割り振られたのは・・・。
■IT業界をしばらく離れてブランクのある40代の方
■30代前半で、システム経験が数年で、しかも別チームで「スキル不十分」の烙印を押された方
の2名でした。

ボクは当時から、「仕事に一番大事なものは『モチベーション』である」というのが持論でした。
ですから、お二人にまずしたことは、お互いの意思統一でした。

私は彼らに語りかけました。
「年齢は私の方が下ですが、設計者ですので遠慮なく指示や指摘をさせてもらいます。
でも、おかしいと思ったことは言ってください。意思の疎通が出来ていないのであれば、
何度でも説明しますし、間違っていたのであれば、素直に訂正します」

やはり、私自身は「年下から色々言われるのは面白くないだろう」と思ったんです。
でも、「こちらの意図は伝えなければいけない」ですし、遠慮していたら、それこそ円滑に遂行出来ない。
ですから、最初に意思統一をしておきました。

転職組 次に行ったこと。
それは「30代の方」に対してのケアでした。
彼は大阪の会社に所属していて、出張で東京に来ていた方でした。
元々は北陸の銀行のシステム部門に勤めになられており、
IT業界に希望を持って転職された方でした
ある程度の年齢を過ぎてからの転職となったので、経験も少ない・・・そういう方でした。
経験が少ない彼は元の所属チームでは「駒使いのように」扱われていました。

私は彼に言いました。
「元に所属していたチームから、『スキル不十分』という烙印を押されて、悔しいですよね?
それに『雑務』をやるために東京まで来た訳では無いじゃないですか。
だから見返してやりましょうよ。
仕事に関して『アナタに足りない』と思う部分は全て教えます。
いっぱい経験を積めるように、たくさんのプログラムを作らせます。
この仕事が終わったときには、胸を張ってやり遂げたと言える様にします。

・・・しかし、たぶんここから数ヶ月が相当ツラいと思います。
それでもやりますか?」

彼は迷わずに「やります」と答えてくれました。
まぁここまで言われて「やりません」といわれたら、それこそカッコつかないですが、
彼の同意を得ることが出来ました。
今でこそ、このやりとりは「コミット」という行為で、「モチベーションを維持するために必要である」と
分かっていますが、当時はそこまで認識していませんでした。

しかし、本能・・・・とでもいうのでしょうか?自然とやっていたんですね・・・・。

No.1後日談なのですが。
この「経験の少ない30代の彼」なんですが、開発が終わってみたら、全体で80人、
開発担当でも50人以上はいたであろうチーム内にあって
「チーム1の開発効率」を誇りました。

これには「統括リーダー」も驚いていました。
「他チームで『スキル不十分』と言われた人材が、一番開発量をこなすなんて!!」と。

実は、これには「裏事情」があって・・・。
「出来るだけ簡単で、大量に開発出来るものを中心に担当させていた」ということがありました。
しかし、それを差し引いても、ご本人は真面目に良くやったと思います。

この時点では気が付いていなかったのですが、「担当していたときには他チームより数ヶ月遅れ」と
言われていた業務が、この頃には追いついていたようでした。

それはこの後の「結合テスト」というフェーズになって発覚します。

閉じる

マネージメント補佐に昇格

私たちがプロジェクトに参加して、1年も経とうとしたころ・・・。
「結合テスト」というフェーズが始まりました。

これは、「各担当がバラバラに開発していたプログラムやシステムを連結させてテストしていく」という工程で、
システム開発全体としては、スケジュール上の中期もしくは後期の初旬に行われる作業です。

障害 この時期になって、「チーム内の他のシステムの品質がおかしい」と
私自身も気が付き始めました。

プログラムが間違っていたり、データの連携が間違っていたりすることを俗にIT業界では
「障害」という言い方をします。
結合テストが始まってからというものの、この「障害」の連続でした。

私たちが担当している業務については・・・「障害ゼロ」。
正直言って、出来すぎだとは思いましたが、ある程度予想できた範囲でした。

私はシステムの品質にとことんこだわりました。
開発時には、開発の効率化を行うため、かなりの工程を省きました。
しかし、その省いた工程のケアを目的とした検証作業を地道に行いました。

それと、品質を一定に保つために、各作業フェーズの前には必ず「完了方針」を作り、
余計な作業はやらせませんでした。
そして、その方針を撤退させるための「「ルール」作りとその「遵守」、それを「検証」するという作業を
繰返しました。

実は、今社内で行っている「マネージメント研修」で教えている「ノウハウ」は、この時点で
ほとんど確立しているんですよね・・・。

とにかく、品質管理は徹底していましたし、数ヵ月後を見据えた作業方針を推進してきた訳です。
他チームとの差が出るのは必然でした。

この頃から、私たちはだんだん暇になっていきます。
他の担当者は障害対応に躍起になっていますが、私たちの業務では、障害が起きないので、
当然と言えば、当然です。

その為、私自身は「さらに品質を上げるため」に色々と策を巡らせていました。
しかし、その策は実行されませんでした。

「統括リーダー」からの一言がきっかけでした。
「・・・すまんが、リーダー補佐をやってくれないか?」

チーム 当時、私が所属していたチームは、全体で80名ぐらいいました。
それを4つのサブチームに分けていて、それぞれにサブチームリーダーが1名ずつ。
それと、チーム全体を管理するリーダーが1名の計5名体制で行っていました。

それ以外にも、もう1つのチームと2つのチームを束ねていた前述の「統括リーダー」。
それを補佐する「マネージメント職」の面々・・・。
かなりの数の人間が管理に携わっていたと思います。

しかし・・・全く管理が出来ていませんでした。
その為、「統括リーダー」が私に白羽の矢を立てたのです。

当時、チーム全体を管理するチームリーダーは、80名を管理するという意味においても、
チーム内の全ての業務量の品質を管理すると言う意味においても、明らかに「スキル不足」でしたので、
その補佐をして欲しいという申し出でした。
ちなみに・・・この「リーダー」は、私と事前面接で口論したご本人です。

当然のことながら、私は「断り」ました。
私がプロジェクトに参加していからの「1年間」、非常に苦労して何とか品質を保ち、
これから「ちょっとは楽できる(・・というより普通の状態に戻る)」状態になってきたのに。
更なる「品質向上」を目差そうと思っているそんな状況で、そのような申し出は
受け入れられませんでした。

それに・・・障害で苦労している他の担当者さんについては、はっきり言えば「自業自得」で
それまで、真摯にシステム開発をしてこなかったのが問題だと思っていたからです。
何故、他人の尻拭いをしなければいけないのかと。
正直、直前の生命保険会社でも尻拭いをさせられていたので、もう辟易していたということも
ありました。

何度かお断りを続けるうち・・・最後通告をされました。
「今回はお願いでは無い。命令と捉えてもらってもいい」
この一言で、80名のチーム全体のリーダー補佐をやることになりました。

リーダー補佐の仕事は、それほど難しくはありませんでした。
直前の生命保険のプロジェクトで、50人規模のプロジェクトマネージメントは経験していましたので、
スキル的には全く特に問題ありませんでした。

衝突 しかし、環境に問題がありました。
それは、作業指示を出す相手が、「自分より前にこのプロジェクトに参加していた人」で
「自分よりキャリアのある人」ばかりだったからです。

よく勘違いをされる方がいらっしゃいますが、
「私は仕事上の衝突というのがキライ」です。

何より「非効率」ですから。

確かに、私は「意見を戦わせる」ということは、むしろ進んで行う方です。
部下にも「青臭いことの何が悪い。どんどん自分の意見を言おう」と公言して憚らないですから。
しかし、それはあくまでも「効率化の為」か「システムの品質の為」のどちらかでしかありません。

「リーダー補佐」という役割が与えられたものの、権威も権限も全く与えられませんでした。
完全に「アウェイ」の状態でした。
しかし、そんな中でもプロジェクトを推進すべく尽力し、一定の成果を上げることが出来ました。

あの時期、あのプロジェクトが破綻せずに乗り切ることが出来たのは、少なからず私の対応が
役立っていたと自負しています。

マネジメント このプロジェクトを経験して、改めて感じたことがあります。
「プロジェクトを遂行する上において、マネージメントスキルは絶対必須である」
ということ。そして「リーダーは人格者でなければいけない」ということ。
「プロジェクトが成功するも失敗するも、マネージメントが重要」である
という絶対的な事実でした。

はっきり言えますが、あのプロジェクトにおいては、チームリーダー、そしてサブチームリーダー全員が
マネージメントという全ての面において「スキル不足」でしたし、「マネージメント不適合」でした。

私自身は理由があり、途中で撤退することになりましたが、
このプロジェクトについては、この後「数年経って」も、品質面での問題が発生し続けたそうです。

閉じる

≪契約管理プロジェクトを受注≫

生命保険会社 現在も取引させていただいている生命保険会社さんのプロジェクトに参加させていただきました。
前の生命保険会社での経験を活かし、契約管理システムの構築を担当することになりました。

≪料金システム保守を受注≫

契約管理プロジェクトを担当している頃、料金チームでトラブルが発生したので、面倒を見て欲しいと
言われ、「火消し役」として、参加しました。

このシステムは、極端に資料の少なく、情報の共有化、つまり「ナレッジマネージメント」が出来ていない
というのが問題でした。

次にユーザーとのコミュニケーションの問題。
意思の疎通がきちんと取れておらず、無用な衝突を生んだりしていました。

モチベーション 最後にモチベーションの問題。
私が参加したとき、大量に発生している作業の前に、各個人のモチベーションは
下がり気味でした。
一番の要因が「先の見えない」ということ。
いくら作業をこなしても、ゴールが見えない状況でした。

そして、一番の問題は、それまでのマネージメント担当者が日々の作業に追われて、
きちんと問題を把握していなかったことが問題でした。

まず、私がしたのは、「部下になってくれる人たち」との「信頼関係」を作ることでした。
仕事というのは、組織でやらないと非効率ですし、品質が保てません。
ですから、まずは「自分自身を信頼してもらい、自分の指示を素直に受け入れられる状況を作ろう」と
したのです。

信頼関係 その為にひとつ宣言をしました。
「ボクが状況を変えるから、付いてきて欲しい」と。
そして、私自身が出来ることから、状況を変えていきました。

私はまず「問題を整理」した上で、部下の人がきちんと分かるように
「明確な対策」を提示しました。
そして、「その理由」と共に、「その対策によってどのような効果が表れるか」という点について、
きちんと説明しました。

私が講じた「対策」により、言った通りの「効果が表れる」。
このことにより、配下で作業してくれるメンバーとの信頼関係は築くことが出来ました。

ナレッジマネージメント 実際、講じた「対策」は随分オーソドックスであったと思います。
まず、「ナレッジマネージメント」については、チーム内で誰かが知りえた情報を自由に書き込め、
チーム全員が参照できる「データベース」を作りました。
そして、自らが陣頭指揮を執り、共有すべき情報を保存していきました。

次に「コミュニケーションの問題」ですが、このプロジェクトにおける問題は
その「報告スタイル」にありました。
「問題が発生したときに、報告が遅れること」がしばしばありました。
本人にその気は無かったのでしょうが、どこかで「怒られるから報告しづらい」という
気持ちがあったのかもしれません。

ですから、「嫌な報告ほど、率先して行い」、報告を密にすることにより、出来るだけ意思の疎通を図りました。
そして相手の気持ちをなるべく探るために、用事が無いときでも色々な話をするようにしたり、
出来るだけ「業務に対する質問する」ことで、前向きな姿勢を認識してもらおうと努力しました。

そうすることにより、ユーザーの反応も少ずつではありますが、変わってきました。

最後の「モチベーション」の問題は、最初に行った「信頼関係」を作るということ。
そして、出来るだけ、配下が行った作業については、検証やレビューを行うことにして、
「配下のメンバーにリーダーは自分のことを管理し、考えてくれている」
ということを認識してもらうように配慮しました。

そして、非常にベタなやり方ではありますが・・。
「特別な用事が無い限り、部下より先に帰る事はしませんでした。」

数ヵ月後、正常な状態とは言えないまでも、プロジェクトは収束に向かったのでした。

閉じる

≪株式会社に組織変更≫

規模が拡大するにつれ、やはり「有限会社」という体制には限界を感じつつありました。

株式化 また、この頃から「お客様から選ばれる存在になりたい」という気持ちが大きくなっていき、
「組織変更」という選択肢を選ぶに至りました。

その背景には、IT業界において、そのほとんどが「顧客軽視のサービス」であること。
エンジニアが、その職務を全うするだけの「スキル」を持ち合わせていなく、そのことにより、
お客様に迷惑をかけているという状況が散見されること。
そして、単なる「ネームバリュー」や「規模」だけで、必要なスキルも無しに、
システムを受注している会社が多くいることに大いなる危機感を感じていたからです。

規模拡大 このままでは、「独立系のソフトハウス」というだけで
敬遠される時代が来るのでは無いか。

そんな不安や苛立ちがきっかけになったのは言うまでもありません。

「ネームバリューや規模で選んでもらえないのであれば、それを手にすればいい。」
そんな気持ちで、「株式会社」にすることを選びました。

閉じる

≪資源管理システム受注≫

他社にて約1年がかりで開発をしつつも、その品質の低さゆえ、稼動させることを許されなかった
「資源管理システム」がありました。

危機的状況 しかし、このシステムが稼動しないことには、ユーザーにとって必須である後続のシステム開発が
行えないという危機的な状況が発生していました。

ユーザーから、この状況を救って欲しいと依頼があり、一度はお断りしたのですが、
他に適任者がいないこと、「担当していた他社の開発担当者が何とか稼動させたい」と
熱意に心動かされ、担当することにしました。

まず与えられたミッションは、1年がかりで稼動できなかったシステムを「2ヶ月で仮稼動させること。」
そして・・・「4ヶ月で本格稼動させること。」

かなり無茶なミッションでしたが、まずは「多少の問題がありながらも2ヶ月で仮稼動」を達成。
その後、外的要因で稼動時期が遅れたものの「半年で本格稼動」まで達成しました。

このプロジェクトについては、通常ではあり得ないような問題が噴出したり、色々と苦労が
絶えませんでした。
また、マネージメントにおけるノウハウも多く注ぎ込んだプロジェクトではあったのですが、
さまざまな問題が多すぎて、詳細については、多くを語れません。残念です。

閉じる

≪心理カウンセラーの資格取得≫

実は、以前にある社員に「軽い鬱症状」が出ました。

鬱症状 客先からのいわゆる「パワハラ」が原因だったのですが、自分自身が何も出来なかったという
経験をしました。

また、IT業界においては、他業種の方から見ると「常に個人プレー」というような印象が
あるかもしれませんが、実はそうでは無く、ほとんどの場合は「組織」もしくは
「チーム」で仕事をすることが多いのが実情です。

そして多くの場合、ITエンジニアは「コミュニケーションスキルが低い」という傾向があります。
その結果、「人間関係のストレス」が多く発生することになります。
私自身も、自分自身がエンジニアでありながらも、「ITエンジニアとのコミュニケーションに
ストレスを感じる」ことがかなりありました。

ですから、この「ストレスを少なくする為にはどうしたら良いか」という考えをかなり前から
持っており、その解決方法として、そして「鬱症状」が起きた社員に何も出来なかったという
悔しさから、以前から興味を持っていた「心理学」を勉強することにしました。

カウンセリング セミナーに通い、勉強するにつれ、「心理学」というものは、実は「単にストレスを軽減する」
という目的だけでなく、エンジニア、いや、ビジネスマンとして、成功する要素があるように感じました。
この要素を社内研修に盛り込み、「社員のスキルアップに活かしたい」と
今はそう考えています。

閉じる