2016年以前、システム事業部は全員が開発職の社員で、営業専任職や事務専任職はいませんでした。
営業活動は、SEでもある管理職の仕事で、
事務作業は、SE、PGが出来る事は自分達でやる、出来ない事は本社の管理部門にお願いする
という全員総力体制の組織でした。

社員が増える事でバックオフィス系の作業も増えてきて
SE、PGが兼務で対応することに限界を感じるようになります。
営業については現場に常駐する組織があるので、
顧客との大きなパイプを持つ課長、係長でもあるSEが営業もおこなう事で、より確度の高い情報交換からの受託ができていました。

そのため、
初めてシステム事業部に開発職以外の社員を採用し、初めて開発以外の組織を作ったのは
より組織内ニーズが高かった事務職が働く組織となりました。

システム会社の事務職ということで、
他業種の事務職よりもパソコンを使う機会は格段に多くなります。
Excelに関数やVBAを使っているのは珍しい事ではないし
会社のホームページをメンテナンスするのも外部発注するという概念がありません。。。
SE、PGが自分達でやっていた事を引き継ぐ事になるので
ファーストペンギンであるシステム事業部企画職の１人目は苦労したと思います。

企画職、、、そう事務職ではなく企画職
企画チーム、、、そう総務チームじゃなくて企画チーム

システム事業部の開発以外の業務を担当してくれる組織の名称をどうするか？はめっちゃ悩みました
事務系の名称を付けてしまうと本社管理部門との作業の棲み分けが分かりにくくなるかな？
というのと、営業職の採用も念頭にあったので曖昧になりそうな名称をあえて選びました（営業企画、事務企画等、何を企画するかを名称に入れていない）

また、システム事業部は”イベント企画”や”制度起案”を独自にやってきた歴史があるので、
それを任せる組織のメンバには0→1的な動きを期待して”企画”という言葉を選びました。
職種名称も事務職とか業務職という名称にせずに、ITスタッフ（ITS）という何コレ？というワク（限界）が見えづらい名称にしました。
個人的には、企画組織、企画職の名称の曖昧なところはポジティブな曖昧仕様です

結果、ファーストペンギンの採用にめっちゃ苦労しました。
事務職経験者や企画職経験者を採用して前職より業務範囲を広げて欲しいという提案をするわけですが、フィットする出会いがなかった。。。

結局、新卒（？）のファーストペンギンに出会うまで２年くらいかかったかな？
企画チームの企画職のITスタッフの採用により
第１期企画チームがスタートします。

まず、ITスタッフの仕事の定義からです。
職種定義ありきというよりは、その時点での人員体制で何ができて、何が出来ないか？
そんな事を探りながら本社管理部門に委託していた業務を少しずつ企画チームに業務移管を続けて行きます。

以前は他部門に任せていた事でコミュロスがあり、
依頼意図が正確に伝わらずモヤモヤする事が多かったのですが、
そういった部分が少なくなり、モヤモヤが晴れたことでみえてくる課題もありの立ち上がり期です。

事務系作業が見えてきたところで、もう1つの課題である営業専任職の採用に着手します。
職種名称はセールスエンジニア（SA）。
営業だけじゃなくって、もう少し対応出来る範囲を広げるイメージです。

今までSEが営業的役割で接する顧客発注部門と
開発運用を行う担当者として接する顧客利用部門とお付き合いする中で、システムを動かすための名もなき小さな作業をいくつも見てきました。
”パソコンの設定”とか”データ変換”とか顧客担当者によっては苦手〜後回し〜となる事って結構あるんです。そーゆうのも併せて発注してくれればコチラでやるのですが、開発側としても後回しにしがち。。。
そーゆう開発職でなくても対応可能な周辺業務のアシスタントもして欲しいのですね。

という事でSAは、
セールス（営業）＋エンジニア（開発アシスト）＝顧客にとってはコンビニエンス！なお仕事です。

苦戦したITスタッフの採用とは異なりSA採用は順調にいったんだけど、１つ笑い話が。。。
普段技術職の採用しかした事が無かったので運転免許の有無なんて気にした事が無かったんです。
結果、上司が運転する車で助手席で寝る新人SAという事案発生。
SA2人目は運転免許持ってる方が良いんじゃなーーい
と思う今日この頃デス。

第２期企画チームは、SAを迎え、ITスタッフの人数も増えて担当業務を増やし続けていた成長と拡大のピリオド。
そして”こども向けプログラミング教室の運営”という企画チームの独自プロジェクトもスタート！

2022年現在、企画チームは
SEとしても現役？の次長がチーム長となり、SA１名、ITS６名のチームになり、
そろそろ次のステップへ進んで良い頃合いになりました。

4月から営業企画チームと名称を変更し、SA2人目の採用をします
って事でwantedlyです。

SA増員後の未来図ですが
営業企画チームを一つ上の規模に拡充して営業企画グループにして、
管下に営業チーム、企画チーム等のチームを作る予定。

第１、２期企画チームを作ってくれた社員が順調に成長しているので、チーム長として責任を持った立場になってくれるはず

と未来予想図を描いています

30期を迎えた時に、先代社長から現社長に代替わりを果たし
中小企業のリスクである事業継承問題をクリアして
2022年現在、38期となります。

システム事業部の人数も増え、2021年4月に100名を突破。コロナ禍で、イベントも出来ないので、記念のQUOカードを作って配りました。

SES型ではなく、顧客直接取引による受託開発をメインに移行してきた結果
システム事業部は以下３つを特徴とする組織になりました。
■固定顧客を長期間サポート
　→業務知識の集積
■現地常駐による顧客との問題意識共有
　→顧客社員代替レベルの行動
■設計開発（稼働前）だけでなく運用保守（稼働後）まで
　→システムライフサイクルフルサポート

最近の10年でもやっている事のベースは変わっていないと思うのですが
・営業企画組織の設置
・社員増加による営業所の設置
をすることで、仕事の幅を広げたり開発環境投資に手を付けられるようになりました。

直接取引顧客の崩壊していたシステムを再構築したことで
顧客の信頼を得たエムアンドエスは、次の直接顧客に巡り合うことになります。
SIer経由でSESタイプの仕事をしていた顧客から直接取引の提案を受けたのです。
最初は２、３名から始まって、信頼されたSEのもとプログラマの数を増やしていく、、、を繰り返して今は30名以上の社員がシステムに関わっています。

ココは直接取引だけどSESっぽい仕事からスタート。
現在は受託見積タイプも増えてきて
人数x単価で売上が固定的に見込めるタイプ
見積時のカンが外れたら大赤字の請負タイプ
の２つでリスクバランスをとっています。

ここのシステムは全国展開大型システムで
エムアンドエスは、その中の数個のシステムを担当しています。
連結している上流下流のシステムは他社が担当しているという感じです。
最近のシステムの難しさって、このシステム連携によってシームレスにデータを流すところと、複数プラットフォーム横断知識が必要になるところだと思うんです。東横線の横浜での遅延が東上線の川越まで影響するってやつです。こーゆうトラブルが増えました。

当然、自分のところだけ良ければOKなんて対応をしても抜本的な対応にはならないので他社の領分にも目を向けなくちゃいけない。20-30年も同じシステムをメンテしているとユーザーからの助けて！を見て見ぬふりをする事が難しくなってくる。。。

かくして、顧客サービスの沼にずぶずぶとハマっていく。

この
顧客（と自分）の利益　＞　会社の利益

ってゆう働き方を軌道修正するのに膨大な時間がかかった。
無料サービスって、顧客は喜ぶ、自分は御礼を言われて満足となるが、
長い目で見ると、自分たちの作業の価値を下げちゃうので、”お客様のために”が度を超すと問題だよね。。。

個人が褒められる仕事の仕方から、会社や組織として褒められることを強みとする会社へ変わっていくことで派遣会社社員っぽい動きから脱却しようと藻掻いたのでした。

（つづく）

バブル崩壊で仕事がなくなったエムアンドエスですが、
ここで創業社長の天然発言が会社の方向性を変える。
仕事ないんだから、形振り構わず仕事を取ってくる！というのが普通の社長のすることだと思うが

「これからは直接取引中心の会社にする！」
「景気が悪くなったからって下請けに仕事出さないなんてSI企業の責務放棄！」

と、逆切れしたのだ。

​社員からすると、いやいや、SES系の仕事も無いのに直接取引って何言ってるの・・・という
感じだったが、、、言い続けるって大事よね（遠い目・・・）

運の悪いことに、
自分は、奇跡的に１社だけあった直接取引顧客のシステムを担当していた（正確に言うと先輩に押し付けられたが正解）
ついでに言うと、
自分は仕事に関しては自分の好き嫌いはさておき、頼まれた仕事には（嫌々ですが）応えてあげるタイプだった。

ついでに言うと、
自分は前職で、自分が作ったプログラムが動いているところを見た事がなかったので、転職時に直接取引のある会社としてエムアンドエスを選んでいた。（入社したらSESジプシーだったので面接時に言った事と違うだろーーーと思ったが）

だからね、まあ、仕事無いしヒマだし、会社潰れるまでは仕事しますよって事で
システムのドキュメント化、プログラムロジックの標準化をしたりしながら
直接取引顧客のシステムを地道にメンテナンスしてみた。

​運の良いことに、
顧客のシステム担当者が、協力してシステムの改善に取り組んでくれたことが救いだった。
仕様書が存在しない（プログラムとデータから読み取るしかない）
機能一覧、ファイル一覧や項目定義も無い（使っているモノと使っていないモノの区別がつかない）
システム発注しても正しく意図が伝わらない（顧客担当者は困っていた・・・）
動かすと落ちるシステムがある（顧客担当者は困っていた・・・）
バグだらけでデータが壊れる（顧客担当者は困っていた・・・）
こーゆー、システムを二人三脚で地道に１つ１つ修繕していったのよ。

ちなみに、コレ大手SIerが放置したシステム。
そして、顧客のIT部門がからんでいないので、担当者はシステムのことは分からない事務職の社員。
本当に困っていたんだと思う。結果として、強固な信頼関係を構築したわけです。

この後、「ドラマかよ！」というような紆余曲折がありましたが
大型の制度改定、オフコン→クラサバ化、会社合併・・・等のシステムを経て
30年続くお付き合いになり、顧客と協業パートナー関係を築くことが出来ました。

この顧客との出会いが、エムアンドエスを
SESから直接受託取引を主とする会社に変えた。
先代社長の天然無理難題が実現してしまった！！！！

（つづく）

そーいえば、昔は会社説明会で受ける定番の質問に
「MとSはなんの略ですか？」というものがあったけど最近聴かれないな。
自分も気になって創業社長（上の写真）に聞いてみた事があるんですが

”M”anagement
”S”ystem

だそーです。

じゃあ、
システム開発会社なのに"コンサルティング"はどーして？
創業当初はITコンサルティングを目指していた？
と聞くと

当時コンサルティングという言葉が流行っていたから
というガッカリ発言、、、

ちなみに創業社長（天然）のイニシャルは「M」
一緒に起業した専務（暴君）のイニシャルが「S」
なんですね。。。

社長が会計と営業出身で、専務は前職何だったんだろう？
確実なのはSEでもプログラマでも無いって事。
なんでシステム開発会社なんか作ってんの・・・

​​自分がエムアンドエスには入社した平成4（1992）年はバブル崩壊の初期だったと思います。
当時はネットを使った求人なんてものはなくて紙媒体での求人の時代
求人雑誌を買ってプログラマ募集のページを開くと見開き2ページしか無いというような就職氷河期

エムアンドエスは10名程度の会社で
大手SIerからの下請け孫請けでSEプログラマを貸し出す、
今で言うと、SES(System Engineering Service) タイプの企業でした。

前述の通り、社長も専務もシステムの素人・・・
現場に行ってみると事前に説明を受けた内容と違い過ぎるーーーー！
そんなことやったことも無いです！って仕事に経験者としてアサインされる理不尽・・・
しかし、天然社長は「？？？」という事が日常茶飯事だった。

この時代、一部の社員を除いて３~６ヶ月でアサインされるプロジェクトが変るので
システムの全容は見えないし、業務知識も覚えたころには別のプロジェクトへ・・・のジプシー状態で
いわゆる、派遣と変わらないじゃんという仕事の仕方だった。

前職で結構テクニカルなプログラムを組んでいた自分は10-20年前にタイムスリップした？
と思うほど、古臭いコーディングで、作ったままの動かないシステムのメンテナンスにウンザリ。
配列使ってプログラム書いたら、顧客のシステム責任者に「他のメンバが理解できないから書き直して」と言われて、変数400個定義して、IF400個書かされた時には、マジ、タイムスリップしたか？と思った。

​システムによっては
個別の仕様書が存在しないだけでなく、ファイル一覧や項目定義も無いシステムって・・・という
デスマーチ必須のシステムもあることも驚いたが
それを、こんなもんだよねー、仕方ないよねー、でスルーしているエンジニアにも驚いた。なんてゆーか、こーゆー仕事の仕方をしていると責任感とか向上心って持っても無駄って気持ちになる。

​で、バブルが完全崩壊する。
元受けのSIer企業は、自社の社員の食い扶持を優先させるので下請け会社は、仕事がなくなってしまった。

​ウチも暇だった。。。が、１社だけ直接取引の顧客があったんですよ。
この顧客が細々ではあるけれど仕事を出し続けてくれたことが
今のエムアンドエス＠システム事業部の礎のカケラ。

（つづく）