読者です 読者をやめる 読者になる 読者になる

業務系SIerでやりたいように技術やる方法を考える

まぁ最近、色々とやりたいことができたのでどうしたらいいかということをここに残す。

 

 

 

 

さあてな、私はなぜかとち狂って、SIという名の墓場に来てはや4年、幸いにも良い巡り合わせにより、ある程度好き勝手できる職場でよかった。

これも日々の行いがよかったからだな。無論、新入社員のときは先輩にいびられて死にそうになっていたが。

 

ここでいうSIerっていうのは所謂業務系SIerだ。

私が勝手に定義すると以下の4つに分類されると、勝手に思っている。(重要なことなので二回言ったぞ☆)

・業務系SIer

・研究系SIer

・パッケージ系SIer

・ニューカマー系SIer (定期契約型、技術志向)

まぁ、ここまで挙げておいてなんだが、業務系SIerとはナンゾや、ということだけ説明するよ。他は本題とは関係ないからな。

 

業務系SIer

業務系SIerっていうのは、所謂、ザ・SIって感じだよ。適当すぎるので、簡単に翻訳すると、お客様の業務を聞いて、その仕様を詰めた上で作りの部分は協力会社に任せるお仕事だよ。

よく言われる問題点として、以下の点が挙げられるよ。

・技術丸投げなので、技術力がない

 ・協力会社の人をリードできない

 ・仕様を詰める段階で、仕様を詰めきれない(できる姿がイメージできないので)

 ・業務に適した技術提案ができない

まぁ、これも会社によって様々ですが、大体の有名所の大部分の社員がこの状況だと思いますね。これも近年強まるSI崩壊論によって一部は改善されているような気がしなくもないですが、少なくとも私の周りはそのままですね。

 

メリットは以下の点だよ。

・人を集約できる

・業務コンサルが強い

・絶対期限までに終わらせる契約をする

どうしても大規模開発になると、人集約型の人月モデルにならざるを得ないですね。フレームワークの発達により、保守性は置いといて、業務機能実装するだけなら誰でもできてしまうからな。

ここでいう業務コンサルは、RFPを貰ってからのことね。企画段階ではない。無論、業務コンサルは、業務系SIerなので、当然ながら強いですね。というか、それがなかったら価値がないですね。といっても、RFP貰ってからの提案が大体なので、中途半端に成りがちなのが面倒なところ。あるべき姿を提案したいのに、お客様が提示する形を実現する方式にどうしも寄ってしまうってのがよく言われていて、企画段階、要は普通のコンサル会社がやっていることを巻き取ろうという動きがでてきているとかないとか。

期限厳守はリスク丸投げのお客様にとっては最高の契約ですね。高いお金を払ってまで、わざわざ契約するのもこの点にあると思っています。

 

本来のあるべき姿として、

企画〜実装〜保守まで同じ人が携わるというのがベストなんでしょうが、先程の技術力であったり、規模大きいお客様だとそこまで自社システムにどうこう考えておらず、足並みが合わなかったりで、難しいのですよ。

そもそも論として、生産性・技術力は個人に帰属するもので、作りを丸投げするのはよくないと思っています。WEB系の会社が個人になんぜあんなバカ高い給料を払うのはその理由ですね。簡単な実装一つとっても、保守まで考えたり、労働集約型を鑑みて全体の設計思想に合っているか考えたりすると、すごい人が少ない人数で実装したほうが効率がいいんですね。でかいなら、その分分ければいいわけですし、ただしその分けるアーキテクチャが難しかったりする。。。。

まぁそれは置いておいて、業務もできて技術もできるスーパーマンなんてもんは、なかなかいるはずもない。だから丸投げしましょうというのが今の現状。昔でしたら、お客様の業務もそれほど複雑ではなかったらしいんですが、今は効率化の果にとてつもなく複雑なことが多いですね。お客様に合わせて業務を勉強しつつ、技術も勉強し続けるのは、『常人』であればとても困難です。大抵は一人のお客様に何年も付きっきりで、他のものは疎かになってしまう人が大多数。

だいぶ本題とは離れてしまったが、業務SIerとはこんな感じだ。

 

本題:やりたいように技術やる方法

 

『技術やる』っていう言葉がなんだかよくわからんというツッコミは無しだ。

ここでいうのは、

・自分が好きな仕事をする

・既存のやり方を一新させる

のことを指す。

自分が好きな仕事をする』っていうのは、私にとってどうでもいい事柄(人の調整、ネゴる、どうでもいい資料作成)をできるだけやらず、楽しいこと(自動化ツール作成・導入、アーキテクチャ設計・実装、技術調査、Sphinxによる内部資料作成)をやることだ。

まずは、ある程度業務的な仕事をこなした後、上司に自分の要望を進言し、受け入れてもらうことなのだが、大事なのはある程度業務的な仕事を経験・貢献した後でないと聞き入れてもらうことは厳しい。自分が異分子の環境だと、まずは自社に貢献してからではないと、頭の悪い人の妄言だと受け取られること間違い無し。

私は幸いにもこれが成功し(当時は狙ったわけではないが)、楽しいことが色々とできる立場となったのだが、問題は「既存のやり方を一新させる」ことである

そのためには、「こうしたほうがいい」「こっちのほうが効率化できる」という意見を上司に納得させることが必要。

その場合、イマドキの技術が分かっている人が偉い人だと非常に助かる。深いところまでわかっていなくても、こんなもんがあるのか、こうあるべきだと、なんとなく理解してくれる人が欲しい。例えば、身近なところでは、Jenkins導入しましょうとか、Git使いましょうとか、偉い人がよくわかっていないと、メリット・デメリット話す前によくわからんから一蹴されて終わりなことが多い。

文脈からお察しの通り、私の職場には分かっている偉い人いないので、以下の二通りが必要。

・企画書作る(メリデメ、人月単価まで)

・一人でダマでやる(しれっと)

企画書も作ったこともあるのですが、やりたきゃやればという雰囲気なので、トップダウン的にこの期間でやれということにはならなかったですね。まぁこんな若造の妄言に対して、予算がつくのは難しいのだろうか。。。

そもそも私がいつもやっている業務内容がわからないのであれば、ダマでやったとしてもその業務内容の内として、大丈夫な気がしないでもないが、その行為自体が評価されなきゃ今後発展(第二の私、第三の私が現れること)に繋がらない。

なので、技術的な発展の土壌としてポータル的なサイトを立ち上げ、そこに集約させる(スケジュール、vagratfile, デプロイ情報、etc)といいのではないかと思っている。