The Way to Nowhere

あるITエンジニアの雑文。

仕事

「バーサタイリスト」

「バーサタイリスト」って、あんまり聞き慣れていない言葉だな、というのが率直な印象。

木村岳史の極言暴論! - 技術者はSEになるな、「何でも屋」になれ:ITpro
つまり技術者の在るべき姿は、“広く浅い”ゼネラリストでも“狭く深い”スペシャリストでもなく、“広く深い”「バーサタイリスト(多能の人)」である。

なるほど、 ”versatile” 「多才の、多芸な」からきた "versatilist" ですか。
「フルスタックエンジニア」の言い換えともとれるし、強いて言えばさらにカバーすべき領域を広げた感じですかね。

確かにそういうポジションでの仕事は「大変だけど楽しい」だろうっていうのはよくわかるし、私もできればそうなりたいね、とも思うけど、そういう機会を得られる事自体がなかなか難しいよなと感じる。
ある意味では「不器用だから」っていうのもあるし、またある意味では「器用貧乏だから」むしろ「何でも屋」的なSEになってしまうっていうのもある。

いずれにしても、まずは何かの領域で「スペシャリスト」として頭角を表して認められないことには、そもそも「バーサタイリスト」的に活躍するなんてできないんじゃないかな、多くの人にとっては、などと思います。

私の場合は、そんなわけもあり、とりあえず目先の生活の為もありで、プロジェクトの為に集まりそのプロジェクトが終われば去る、という「スペシャリスト」として当面は生きて行こうと思うのでありました。

しかし「バーサタイリスト」って、語感的にはあんまり一般的に浸透しそうな気がしないな、とか思ったりもします。まあ言葉自体はどうでもよいのですけどね。 

「SIガラパゴス」のERP導入における問題点

朝の電車の中で何気なくTwitterでつぶやいたら、記事の筆者ご本人に反応して頂きました。

記者の眼 - 「SIガラパゴス」を育んだIT部門の罪:ITpro

この話はもう何周目かな?と思うくらい、何度もグルグル回っている感もありますが、同じような主旨の話でも繰り返し訴えていくということも必要だと思うし、そういうお立場でもあると思うので、それはそれでいいと思っている。

私はフリーになってこの辺のテーマからは「斜め」方向に行ってしまったわけですが(斜めの上か下かはわからないw)、この記事を読みながらも、記事の論旨とは違う観点で思った事があるので、その辺りをメモ程度に書いておこうかと思います。

記事中で「ERPレガシー」という事に触れらている。
私もその「ERPレガシー」の作り込みに関与してきたと言える。
アドオンたくさん作ってきたな~と。まあ、それが仕事だったし。 

その点に関しては、記事のテーマにある通り、 ユーザ企業側の問題が一番大きいとは思うけど、長年ERP絡みのプロジェクトの現場にいて、それとは別の問題が2つあるなと考えてきた。

1つ目はERPのいわゆる「導入コンサルタント」の問題で、ちゃんとしたスキルとマインドを持った人が圧倒的に不足していると思う。
ERPパッケージの標準機能、業務プロセスを「そのまま使う」といっても、実際にはどこのセットアップ項目をどのようにセットアップして使っていくかということにはいろんな工夫の余地があると思っている。
だけど、できるだけちゃんと標準機能を使うようにしよう、という工夫をしようとするって事がない、そういうふうに考えられる人って少ないよな、と。
まあ、「標準機能じゃできませんね」ってことでアドオン化した方が商売になるっていうSIer側の事情も絡むのだとは思うけど。
そしてどうしてもなんらかのアドオン/カスタマイズは必要だとなったとしても、ただ普通に機能要件を実装するだけじゃない工夫の仕方がパッケージの場合はあると思うんだよね。

もう1つの問題は「スキルのある人材不足」とは裏返しとも言える話で、ERPパッケージをうまく使いこなす為に「コンサルタント」と称する高度なスキルのある人が必要って事は、そもそもERPパッケージ製品自体がまだまだイケていないんだと思っている。
色々と進化はしてきていると思うんだけど、難易度としてはむしろ上がっていると思うんだよね。

「各種セットアップをして標準機能だけで出来ます」とか言っても、実際のプロジェクトの現場でちゃんと動くようにするにはえらい大変だったりする。
ほとんどプログラミングしているみたいなものだと思う事があるけど、普通のプログラムみたいにエディタ上にシーケンシャルにロジックが見えるわけではなく、普通にプログラムを書くよりもむしろ難易度は高いと思える事もある。
それをプログラムを書かない(書けない)「コンサルタント」が対応しようとするものだから、そりゃあ炎上しますわ。。。

そんなわけで、もっと「簡単に」使えるようになる業務アプリケーションパッケージが必要なんだと思うわけです。

繰り返しますが、元記事の論旨とは違う観点の話をあえてしています。
ERPでサポートする業務プロセスがベストかどうかは本質的な問題ではなく、一つの標準プロセスに整流化することで、重複業務のカットなどの効率化を図り、一般管理費を下げることを目指す。
これ自体には基本同意していますので。
今現在あるERPがベストでないにしても、導入すると決めたからには今あるものを受け入れて、その中で工夫すべきだと思います。

時間がないので、この辺の話はまたあらためて考えてまとめてみたいと思います。

会社を辞めました

既にちょっと間が空いてしまいましたが、先日の12月15日を以って16年8ヵ月勤めた会社を退職しました。
今後はフリーランスのエンジニアとしてやっていくつもりですが、一応法人としての体裁は作ろうと思っております。

一般的には別に名の知れた会社とかではないので、そこはまあ私の事を直で知っている一部の人だけ分かればよいかと思いますが、そろそろ自分自身の記録としてブログにも書いておこうかと思った次第であります。

最近方々のブログで「退職エントリ」が書かれているのをGunosyとかから流れてきて時々見かけますが、そういうので色々書いている人って結構若くて、働いてまだ2、3年なんだけど、仕事や会社や業界のことなど様々な事についてそれなりに鋭い洞察をしていたりして、大したもんだな、と思ったりしてます。

私なんかはここまで来るのに16年8ヵ月もかかってしまいましたからね。いや、ヤバイわ、、、

技術の事だけではなくて、経営戦略とかマーケティングとかの勉強をしたり、SIerの業界の問題点とかを色々と考えたりもした上で、自分自身のやりたいこと/やりたくないこと/得意なこと/苦手なことなどを様々考えた結果、私の場合はフリーのエンジニアみたいな感じで独立するのが一番良いのだろう、と考えたのは、もう何年も前の事なのですが、色々とタイミングは図っていたら、ここまで引っ張ってしまいました、というところです。

「人月商売」の観点しかない状態では、どうしても稼働率を高める事を追求していかざるを得ないので、自分の専門性を深堀りしたり、自分自身で考えた新しい事にチャレンジしたり、という事がとてもやりづらくなってきているというのは感じておりました。

そうは言っても、SI仕事自体は色々と内容や形は変わってもなくなることはないと思いますし、そんな中で一定以上のスキルのある人を「期間限定で欲しい」っていうニーズはむしろ益々高まっていくのだとも思います。正社員である必要なくなっていくよ、って話でもあります。 要するにフリーランスで良いでしょう、と。

とは言え、いきなりフリーランスになるという決断はできずに、転職含めて色々とキャリアパス的なものを模索していたのですが、リーマンショック後の人余り状態とIFRS強制適用という流れの中で、Oracle EBSのSLA/FAH(Subledger Accounting / Financial Accounting Hub)絡みのツール開発と販売という話が出てきたので、それで単なる受託ではない今までとは異なるビジネスモデルが作れるかも!ということで、これがやれるならもうしばらく会社にいてみようかと思ってやっていました。

このプロジェクトは他ではなかなかできない経験をたくさんさせて頂いたと思いますが、結果的にその試みはうまくは行かず、「普通」の仕事に戻ることになりました。直接的には震災後にIFRS強制適用が事実上延期となったから、ということなんですけど、でも、それだけではない、と色々と思う所はあります。

そんなわけで自分がそういう「特別な」事ができる状態ではなくなったので、以前から考えていた通り会社は辞める事に決めました。既に携わっている案件は全うした上で、ちょうどキリのよいのがこのタイミングとなったのでした。で、今さら転職とかもうないなー、とも思いました。

フリーになっても当面の生活していく為の仕事内容はあまり変わらないとは思いますが、その辺りうまくやりくりしながら、新しい事にもチャレンジしていきたい、と考えております。

私自身のバックグラウンドとしてはOracle EBSのFinancials関連の経験が長くて、特にSLA/FAHに関しては内部構造を自力でかなり調べた上で、某大手製造業のプロジェクトでは様々な要件をクリアする為に実践もしたので、非常にニッチな領域ではありますが、実際のプロジェクトの現場に入るようなポジションにありながら、私ほどに詳しい人間は中々いないだろうとは思っています。その時からはちょっと時間が経ってしまったので、その後それなりに経験者は増えたとは思いますけどね。

今後については別にOracleとかEBSとかこだわるつもりは全然ないです。そもそもOracleがEBSとかFusion Appsとかどうするつもりなのか、表向きには色々言っていますけど、実際の所どうなっていくのかもよくわかりませんしね。もちろん仕事のオファーがあって自分が空いていればやるとは思いますけど。
 
なので、そんな感じで日銭を稼ぎつつ、研究開発的な活動も継続していって、何かしらイケてるソリューションを作っていきたい、とは考えております。

というわけで、そんなにすごい若いわけでもなく、勢いとか情熱とかだけではなくて、打算も含めていろんなレベルでいろんな事を考えた上での、おっさんの決断であります。中学生の時に何かで「サラリーマンにはなりたくない」と書いていた事が思い出され、感慨深いです。私はこういう決断をしましたけど、みんながみんなそうすればいいとか全く思いません。とは言え、自分の人生は自分の選択の結果だという認識だけは持ってた方がよいだろうとは思います。 

今後ともよろしくお願いいたします。
 

ノマドと社畜 ~ポスト3.11の働き方を真剣に考える
谷本真由美(@May_Roma)
朝日出版社
2013-03-09


ソフトウェア開発と業務システム開発は違うという事

しばらくモヤッとしていた事が少し言語化された感じがする。

もしSIerのエンジニアがジョブズのスピーチを聞いたら(1) - Wadit Blog.
もしSIerのエンジニアがジョブズのスピーチを聞いたら(2) - Wadit Blog.
多くの人が混同するのだが、ITという括りであたかも同じように語られるのが、業務システムの開発とソフトウエアの開発である。営業システムとか生産システムといったものが業務システムで、MSのオフィス製品だとか、DBMSだとか、パッケージのようなものがソフトウエアとすると、それぞれを開発するやり方は違うと思いませんか。
もしSIerのエンジニアがジョブズのスピーチを聞いたら(3) - Wadit Blog.
なぜ、"コードはソフトウエアを作る時に書いて、業務システムはそのソフトウエアを使って組み上げる"ことができないのでしょうか。プログラマーは、役に立つ魅力あるソフトウエア(ツール)を産み出すことに自分のスキル、意欲を傾注したらいい。そして業務システムを作る人は、業務プロセス、仕事スタイルをデザインできる人がすればいい。後者こそ本来のSIerのめざすところではないでしょうか。
もしSIerのエンジニアがジョブズのスピーチを聞いたら(4) - Wadit Blog.

よくSIの受託開発仕事をDISる文脈で「コードを書く事へのこだわり」みたいなものを語られる事に対して、 なんとなく共感する部分も感じつつ、同時に違和感も感じる事が多いのだけれども、それはそういった文章がここで言われている「混同」に無自覚だからなのかな、と思った。
具体例挙げられるほどに覚えてはいないのだけれども。

ソフトウェアによる様々なサービスやプロダクトが登場してくる現在及び今後の状況において、SIの現場ではできるだけ「コードを書かない」でソリューションを確立・提供すべきなんだと最近強く思う。
エンジニアとしてはコードを書くスキルを磨いて実装力を持ち続ける事は必要だとは思うけど、SIとして顧客に提供する価値って「コードを書く」事じゃないよ、と思うわけです。

スクラッチ開発で人月積み上げた方が儲かるっていうのはその通りなんだけど、そんなコストをかけ続けられる顧客自体がどんどん少なくなって先細るのは明白なので、こういう視点も一つの例として、SIでどんな価値を提供すべきなのかを考え転換していく必要があると改めて思った次第です。

そういう取組をしたとしても人月の呪縛から逃れるのは難しいとも思っている。
まあ、個人的には人月見積を全面否定する気はないのですが、持続可能なビジネスとして成立させる為には同時に考えていくべきテーマではあるよね。

SI仕事の区切りにて雑感

昨年より関わってきた仕事に一段落着いたので、雑感を少々記録。 
久々に開発プロジェクトの現場に戻り、しかも相当なビッグプロジェクトだったので、現場ならではの知見も相当得られたと思います。反面教師的な意味も含めて。

私自身は既に燃え上がっている所に「火消し」として召集されて、自分の専門分野の火を消し続けるだけで手一杯な日々でしたので、全体的な観点では動きようもなく、最後まで全体像はよくわからない感じでしたが、これもまた大組織らしく分業化された仕事の回させ方なのかな、と思いました。

大組織の通常の業務オペレーションにおけるセクショナリズム的考え方がプロジェクト体制上の各チームにも持ち込まれて、担当領域の境界線があいまいな部分の課題等では、それぞれが勝手に定義した自分達の領域の考え方に基づき仕事と責任を投げ合う様がそこらじゅうに見られて、傍目に見ていて爽快な感じすらありました。
普通はそういう所はプロマネが仕切るべきものなんでしょうけど、プロマネ的機能自体がそれなりの組織になっている事もあり、その投げ合いに参加してしまっているような事になっていたりとか。

こういうプロジェクトが多くの会社で発生している、とか考えるといろんな意味でぞっとしますね。
IT投資として何を目的にやっているのかがプロジェクトで実際に手を動かしている関係者に浸透していない、という事が根本的な所にはあるなのかなと思います。
目先のスケジュールや課題数減らしの為の近視眼的な対応で結果的に無駄になった作業とか相当なものです。
いつまでもこんな事は続けていられなくなりますよ、きっと。

プロジェクト自体はまだまだ続いていくようですので、そのプロジェクトや会社自体が今後どうなっていくのかは遠くから生ぬるく見守っていきたいと思います。

システム開発的な観点でも過去に何度も見たような問題がまた繰り返されている感も多々あり、ましてERPを使っているんだから、もうちょっとどうにかできないものかな、という思いもあります。
もちろんそれぞれに違う会社が時期をずらして同じような事をするからこそその道のプロとしての仕事があるという面もあるのではありますが、こういう所をもっとうまくやれるようなSIのソリューションを何か実現できないか、というのは今後のテーマとして継続して考えていきたいと思っています。

「システム部門への不満」と言うけど

SIerのビジネスモデルの話と表裏一体とも言えるシステム部門への「ダメだし」のお話。

経企部門が吐露する「システム部門への不満」 - システム部門再生:ITpro

これをネタに何か書こうと思いつつ、時間とれなくて寝かしておいたんですが、あらためて読んでみたら当初と違う事を思いましたので、その辺について書いておこうかと思います。

システム部門が経営に貢献する為には自社のビジネスやその業務プロセスに対する理解が不可欠で、システム活用してよりよくしていく事に積極的に関与すべきというのはもちろんその通りだとは思います。
この記事では経営企画部門が「経営層に一番近いポジション」としていろいろダメだししているわけですけど、どこか他人事のような物言いがすごく違和感を感じるんですよね。
「御用聞き」とか「コミュニケーションスキルがない」とか「積極的な提案がない」とか漠然とした不満を言っていても仕方ない。経営企画的には、自社の事業のバリューチェーンのどこをどうすべきかという具体的な要求があって、それにどう応えていくかを業務とシステムが一緒にやっていく必要があると思うわけですね。一方的にシステム部門がダメとか言っている場合じゃないというか。

勿論、そういうプロセスの中でシステム部門の人間も積極的に貢献していく事は必要だと思います。
そういう取り組みはしつつも、そういう所から離れてシステム部門から何か提案するとしたら自分事である運用や保守の改善ネタになりがちだろうし、その辺て特に理解されづらい所かもしれないですよね。タダでさえコストとしか見られていない所だし、ビジネスへの貢献という観点ではさらにわかりづらい。

まあ、メディアのインタビューへの対応だからあまり具体的な事を話していないだけで、実際にはいろいろなやり取りをしていることとは思いますけど。

それから、業者に「丸投げ」していて実態を把握できていないから積極的に貢献できるような動きができないという話もあって、だから「内製化」という話もありますね。まあ、 対応に必要な期間や十分なスキルのある要員の手配等の制約もあるので、業者はうまく使えばいいと思いますけど、そういう制約さえ取っ払えば自前でもできる くらいの技術力がないと本来的な意味での業者の管理とかコストの妥当性とか評価できないのだと思います。それはシステム部門をなくして経営企画の中にシステム企画の機能を持たせるとかしても、部門の割り方の問題だけで結局同じ事が必要になるんではないかと思います。

というわけで経営企画とシステムの部門間対立的な構図で捕らえている事自体がそもそもどうなの?と思った次第です。

『ソフトウェアパートナーシップモデル』と言ってもそんなに新しい感じはしないけどね

時々出てくるSIerのビジネスモデルの話のようだ。

オフェンシブな開発~「納品しない受託開発」にみるソフトウェア受託開発の未来 - Social Change!
私たちは「お客様にとっての内製部隊として使って頂く」ことをコンセプトに提供しています。

この「内製部隊として使って頂く」というのは、それが全てとは思わないけど、一つの方向性としては賛成、という所でしょうか。
システムの開発や運用のマネジメントリスクを認識したユーザ企業にとっては、高度な技術を提供して手を動かしてくれる人さえいればいい、という事になると思うので。

で記事の内容、全体的には同意できない部分も多々あるかな、と。

「ディフェンシブ/オフェンシブ」というキーワードを「ビジネスモデル」にかけていたり、「開発」にかけていたりで、字句通り理解しようと思うと、それらの言葉への自分自身の先入観も手伝って、何を言っているのかよくわからない感じになったりしました。

まあ、言わんとしていることはなんとなくはわかりますが、一括請負受注の方がハイリスク・ハイリターンなわけで、ビジネスモデルとしてはむしろ「オフェンシブ」なんでは?とか思ったりします。
言葉のイメージだけの話ではありますが。
従来型で「やばいぞ」と言われている一括請負モデルに対するオルタナティブを積極的に模索し取り組んでいるという事で「オフェンシブ」だという事なんでしょうかね。

開発という観点では、そのハイリスク・ハイリターンな一括請負受注の中で極力リスク要因を排除していく為に、新しいチャレンジングな技術には取り組みづらいという意味で、「ディフェンシブ」だというのはまあ理解できます。

で、この「ソフトウェアパートナーシップモデル」という「新しいビジネスモデル」との事ですが、うーん、「クラウドアプリケーション」に拘る理由とかはイマイチよくわからないのでその点を無視しますが、これっていわゆる「ソフトウェアエンジニアリングサービス」とか言ったりして、割と普通なんではないか、というのが率直な感想。

特に保守・運用フェーズでは、顧客の予算の都合という理由が大きいと思いますけど、一定期間の固定金額の中で改善も含めて優先度付けながらやれることをやっていきましょう、っていうのはごく普通な事のように思うわけです。

実は、これらもすべて「納品」していることに起因します。納品するためには要件の確定と見積もりが必要になり過重なバッファが発生し、納品があるから開発と運用が分かれますし、納品するためにハードウェアを購入するのです。人月以外の単価ということで、ストーリーポイントやファンクションポイントなども試しましたが、結局は「金額のための見積もり」につながってしまえばうまくいきません。金額のための見積もりをしてはいけないのです。

これもよくわからない論理展開で色々と突っ込みどころがありそうなんですが、
ともかく人月の見積もりとか否定しているわけですけど、一定金額の中でやれる範囲をどうやって決めるかと言えば、やはりいろいろ出てくる要求に応える為の作業の工数見積もりをして、許容できるコストから逆算した上限工数と照らし合わせていくって事になるんではないでしょうか。
契約金額に影響を与えないビジネスモデルだからといって「金額のための見積もりをしない」って事にはならないと思うんですが。

どこまで顧客に情報を提示するかはわかりませんけど、「やれる範囲はここまでです」というのを顧客と合意するにはそれなりの根拠としての見積もりがやはり要求されるのではないでしょうかね。
「内製部隊として使って頂く」という事なら、なおさらだと思います。

しかも、本番で運用が始まれば、ユーザのニーズを汲み取りながら変えていけます。月額定額なので、要件はいつでも、どれだけ変えても良いのです。要件はいつでも変えても良いし、どれだけ変えてもかまいません。優先順位も変えることができます。これも大きなメリットです。

それから既に本番で動いているシステムに対する変更って、やはり開発時と同じ「ノリ」ではできないというのが実際で、それは開発と運用の担当が分かれていようがいまいが変わりはなくて、本番変更のリスクを鑑みて十分なリグレッションテストをしようと思えば、それなりの工数=コストを見込む必要があるというのは間違っていないとは思うんです。「気軽に変更できてコストが安いよ」というのはどこかミスリーディングな気がします。

確かに「その程度の変更になんでそんなにかかるの?」みたいな過剰な見積もりが時折見られるのも事実だとは思いますけど、そんな見積もりを繰り返しているようでは契約切られて仕事自体がなくなるかもしれませんよ、という危機感をどれ程意識しながらやっているかという、会社とか技術者とか次第な所があるのかな、と思います。

元記事はなんだか読み進めるにつれてどんどんPR記事っぽくなっていくのが、何だかな~と思っていたのですが、これと数日しか違わないので、やっぱりそういう事かと後から納得はしました。

「株式会社ソニックガーデン」設立および事業移転のご案内 - SonicGarden 株式会社ソニックガーデン
このたび、TIS株式会社の社内ベンチャーである「SonicGarden」は、より一層の事業成長を目的とし、その構成員を中心として「株式会社ソニックガーデン」として新会社を設立しました。

極論やあまり馴染まない印象の言葉の組合せを使って、耳目を集めようって狙いも意識無意識を問わずあるような気がしました。

まあ「終わった」とか「やばい」とか悲観的な事ばかり言っていないで、やれる事は何かを考えて実際にやってみる、という試みとしては、敬意を表したいと思っています。


私としてはやっぱり「顧客にとっての投資価値」をどうやって見積もれるようになるかという所に、SIのビジネスモデルにおける一つのブレークスルーがあるような気がするわけですが、この元記事やさらにリンク先の関連記事などを見ても、現在水準の技術者の人件費を中心としたコストベースの価値しか見ていない印象がして、その辺には迫れていない気がします。
私としては「もっと儲かるビジネスモデルにするにはどうしたらいいのか」という方向性で考えていきたいと思うわけですが、まあそもそも私と同じ方向性で考えているわけでもないと思うし、やっぱりなかなか難しいんだなあ、とあらためて思いました。


あわせて読みたい:
SIerが人月商売から脱却するのはやっぱり難しい
SIerの人月ビジネス脱却の件

大企業で働くのがどーとか

あんまり元記事と関係ないかもしれないけど、仕事上でいわゆる大企業の方々と関わることはよくあって、ちょうどこの記事が出る少し前くらいから、もやもやと思い始めたことがあったんで書いておこうかなと思いました。

まあ、今の若者がどうすべきかとか別にどーでもいいんですけどね。
自分が何をやりたいのか自分でよく考えて決めればいいと思いますけど。

将来有望な若者の将来価値を毀損する、大きなワナ - Chikirinの日記
というわけで今日のお話は、「やった!頑張った甲斐があって、就活もうまく乗り切れた!」とか、「まあ、オレのスペックならちゃんと大企業&大組織に入れ るのも当然だけどね。」とか言ってる人は、実は「完全に周回遅れです」みたいな場所で人生最初の「働く訓練」を受けることがどれだけ自分の将来価値を毀損 する可能性があるか、よーく考えてみたほうがいいんじゃないか、ってことなのでした。
大企業で働くと毀損されるいくつかのコトについて - GoTheDistance

このように、大企業という所は人が立ち替わり入れ替わりしてもいいように、もっと言えば誰が辞めてもいいように作られたレールの上にお仕事の流れが 存在しますので、そのレールに5年も疑問を覚えず乗りっぱなしでいると世間知らずのおバカさんになってしまい、高確率で自分の頭で仕事を作り出せない市場 価値ゼロの人間になるかもしれないよって、指摘する必要もないのにわざわざちきりんさんは指摘していらっしゃるのです。上から目線とDISってる程度の方 にはわからない、ありがたい人生の先輩ですね。

もちろん大企業でしかできない仕事というのも存在しますし、市場価値の高い仕事は大企業に多く転がっているの事実です。ただ、大企業にあぐらを掻いてはダメだってこと。この10年で、どんだけの日本の大企業がくたばりましたか?



いわゆる大企業の人って、物事を理解するのが早く、どんな仕事でもそれなりに平均点以上にこなせる、みたいな所があって、なんだかんだ言ってもベースの能力は優れているというか、ベタな表現で言えば「アタマいい」人が多いな、というのは以前から思っていました。一見するとオチャラケた感じの人でも押さえるべきところはちゃんと押さえるというかね。

で、私の場合、いわゆる大企業の中でもやはり情報システムとか経理とかの人達と接することが仕事柄どうしても多くなるわけです。皆さん能力もそれなりに高く、接すれば人間的には「いい人」が多いと思いますが、新卒から生え抜きでずっとこういうバックオフィスな仕事をしているとか聞くと、こういう人は何を思って今のポジションにいるのかな?と不思議になる事はよくあります。
ITとか経理とかやりたくてその会社に入ったわけではないのだろうになあ、もっとその会社の「本業」に関わる部分に注目して選んだはずだろうに、とか。そうするといまだにその会社でその仕事をやり続けている理由ってなんだろう、とか勝手に思って切なくなったりするわけです。

まあアサインされて関わってからそういう仕事の意義とかもわかって続けているっていうのもわからなくはないですけどね。実際、きちんと本業の部分をよりよくする為にバックオフィスの部門として何ができるかをちゃんと考えて動いている人もいますからね。
特に私みたいなIT系の出入り業者が関わる時は、だいたいシステム再構築とかしている場合が多いわけで、そういう風に新しい仕事の仕組みとかルールを作るところに関われるのは大企業ならではなのかもしれません。

ちなみに元記事はそーとーな大企業を想定しているみたいではありますが、たとえ名もなき会社であっても100人超えてきたら、程度の差はいろいろあってもセクショナリズムとか勘違いした人が出てきたりして、注意してないとダメなんじゃないかねというのが、実感としてはあります。


SIerの人月ビジネス脱却の件

人月ビジネスの件は、ちょっと前に自分でも似たような事を書いていたなぁとか思った。

クラウド時代にSIerはどう生き残るのか? 人月ビジネスからどう脱却するのか? 大手SIer役員にインタビューしました - Publickey
とはいえ、そのときに顧客への価値、あるいは満足度をどう計るかは難しいですね。鉄道は「ここにあるものが、あそこへ移動している」という仕様がはっきりしている。ところがITは仕様があいまいだったり、速くできてもそれが当たり前だと思われたり、価値につながることが理解されない可能性がありますね。


SIerが人月商売から脱却するのはやっぱり難しい
SIerはそのシステム投資の「顧客価値」が見積もれないので、コストベースで積み上げた金額しか提示できないわけですね。金額の根拠を説明するのもコストの話がわかりやすいし合意も得られやすい。
それは顧客側もほとんど似たような話だと思うわけで、本当にそのシステム投資の価値が見積もれているのかというのは結構疑問。
「とりあえず予算がこうだから、この範囲でやるしかない」というのも一つの価値基準ではあるけど、本当ならそのシステム投資によってもたらされる生産性の向上や収益機会の拡大によって得られるはずの「キャッシュフロー」から投資予算も決められるわけなんだけどね。


ビジネスモデルを変えなきゃね、というのは何度も出ている話なので、今さらあらためて言う程の事ではないかなとも思います。

様々なサービスやプロダクトがある中で、実際にそれらを使う企業が自身のビジネスプロセスの中にどう組み込んでいくかという部分は、必要な仕事として残るだろうから、"System Integration" という本来の言葉通りの仕事になっていくというのも一つの方向性なのかな。
それですら、コンサルファームのIT系の人達とはまともに競合するだろうし、顧客が自らスキルのある人を雇ってもいい所だろうから、安泰とはいかない。
そもそもきっとそれだけでは人月ビジネスからは脱却できないでしょう。

そして、そういった過程では、これまでは一番のボリュームゾーンで儲けるポイントだったスクラッチ開発の部分は、どんどん削られていくわけで、今の規模を維持していくのは無理でしょう。

一番仕事がなくなるのは、詳細設計・プログラミングから単体・結合テストくらいのフェーズだけを請け負ったり人だけ派遣しているようなビジネスモデルの会社だったり、実際のそういうモデルの中で仕事している技術者自身なのでしょうが、それこそ今さらなお話。

強みを見極めて独自のサービス化・プロダクト化していく、というのが、総論としてはその通りなのだろうけど、具体的に何ができるのかって考えるのは結構難しいよね。
ユーザがどんなビジネスモデルでやっているのかがわからないと、そこにどんなものが訴求するのか想像もできない。

まあ答えはそう簡単には出ないのだが。

個人レベルで言えば、自前で独自のサービスやプロダクトを作るのは難しくても、ユーザ企業でIT活用を推進するようなポジションに移った方が面白い仕事ができるのではないかとか思ったりします。

『マネジメント信仰が会社を滅ぼす』

ちょっと前に読んだ本。深田和範氏による新書。

多くの日本企業がマネジメントさえうまくやればなんとかなる、と勘違いしてマネジメント信仰に陥り、本来取り組むべき「ビジネス」を疎かにしている、と警鐘を鳴らす。
もしドラ』なんかがベストセラーになったりして、「マネジメント」があらためて注目されているかのような折に、真逆を行く内容かと思わせるつかみではあります。

マネジメント信仰が会社を滅ぼす

序章 マネジメントがビジネスをダメにする
第1章 症状(1)意見はあっても意志はなし
第2章 症状(2)都合のよいことばかりを考える
第3章 症状(3)管理はするけど無責任
第4章 症状(4)顧客よりも組織を重視する
第5章 日本企業の危機的状況
第6章 経験と勘と度胸を重視せよ
第7章 他人を変えるより自分が変われ


「マネジメント信仰」に陥った具体的な症例を挙げた上で、ではどうすべきか、を著者なりにまとめた、といった内容であります。

「経験と勘と度胸を重視せよ」とか「他人を変えるより自分が変われ」とかいうのは、私個人的にはまさに日々思っていることでもあり、基本的に同意しているんだけど、結局は自己啓発的な方向で締める感じは、なんだかなあという印象でもありました。

どうしてそう言い切れるのかわからない所なども時々ありましたが、まあ、これも著者の「経験と勘と度胸」で書き上げた、という事でよいのだろう。

SI業界における、プロジェクトマネジメントに関する問題などにも多少通じるところがあるなー、などと思ったりもしました。
「マネジメントさえしっかりやっておけばよい」とか「何よりもまずマネジメントをしっかりやらなければいけない」とか考えている奴らがたくさんいるというか。

最も害だと思うのは、マネジメントやる人間の方が偉そうに扱われる事が多いって事かな。
本書読んでいて、マネジメントは主役じゃない、脇役なので、こういう所こそ専門化された人間を雇って、管理させるっていうのはありだな、とは思った。
今までITSSとかの専門職種に「プロジェクトマネージャ」とあるのがどうもしっくりこなかったのだが、その辺を自分なりにやっと消化できたというか、一応意味はあるなとわかった。

要するに管理する側とされる側は上下関係じゃなくて、ただの役割分担だという事にしていく必要があるんだと思う。
まあ実際には現場で何が行われているのかをわかっていなければ、意味のある管理はできないんで中々難しいのはわかるけど、なんとかそういう方向に持っていけないものかと思う。
プロジェクトマネジメントを専門的にやる部門を作ったりとか。

大手SIerなんかは既にかなりの部分そんな感じなのかもしれんね。
表向きは何かの技術やソリューション担当となっていて多少の専門知識は必要だけど、実際のプロジェクトで手を動かすのは協力会社の技術者なんで、それらを取り纏め管理するのが主な仕事みたいな。まあ、個人的にはそんな人は見たことなくって想像ですけどね。
この場合も受発注の上下関係が入ってきてしまうのでどうかな?と思うわけですね。
コンサルファームなんかは「PMOだけ」みたいな立場で入っている事もあるかな。そんなふうに割り切った方がむしろいいかもしれない。

あまりまとまりがなくなってきましたが、本書を読んで私自身も「マネジメント」ではなくて「ビジネス」をしたい側だなと思った。
いや、勿論「マネジメント」でもその役割に徹するならできるなとは思うけど、それってまさに本書で挙げられているような「マネジメント信仰」の中に入っていくようなもので、やってて楽しくないだろうなと思うわけで。

最後に一言だけ引用。
「マネジメントなんて小難しいことを言っていないで、さっさとビジネスを始めよう」
いや、まさにね。そういうことです。
記事検索
livedoor プロフィール
Twitter
AdSense
Amazon


  • ライブドアブログ