The Way to Nowhere

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

仕事

SIerが人月商売から脱却するのはやっぱり難しい

これはもう散々言われてきた事で、今さら私が言うような事でもないわけですが、自分の実感として改めて思う所があったので、まとめておこうかと思いまして。

SIerが人月商売から脱却する為に、様々な策をいろんな人がいろんな所で語っているよう。
それで大体は、サービス化とかSaas化みたいな話になりがちなわけで、方向性の一つとしてそれはそれでいいとは思う。

ただ、顧客への請求を人月ベースに依拠しないビジネスモデルを探るにしても、そもそも「価格」ってどういうふうにしたら決められるのかって事を考えないといけないと思う。

当たり前の話ではあるが、一般的にモノやサービスの価格は、そのコストと顧客価値の間に適当な落とし所を見つけて決まることになる。

 コスト ≦ 価格 ≦ 顧客価値

コストは厳密には「見積コスト」という事になるのだろう。
見積コストを下回る価格は赤字確実なわけで、ビジネスとして継続できないし、ある意味で利益供与になってしまう。また、顧客が見出す価値を超えた高値では売れるわけない。

別の手段で回収する方法があるなら、それらも含めたビジネスモデルとして考えるべき話である。

で、人月商売とは結局このコストベースの価格決定方法だけにロックされてしまっているって言う事なんだよね。
これは単純にSIerだけの問題でもなくて、顧客企業側もほとんどのシステム投資は「コスト」としか見れないから、最もわかりやすいしリーズナブルなわけだ。
SIerは人月商売から脱却したくても、顧客側はそう簡単には納得しないよね。
かかるコスト(とSIerの適正な利潤)を超える金額を払うという事になるわけなんで。

また、顧客への課金方法がどうなろうとも、内部的な人件費コストはやっぱり人月で見積もるしかないわけで、だから単純に人月の考え方自体を否定するのはちょっと違うと思うわけです。

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

かなり大きな企業なら程度の差はあっても何らかその手の根拠を持って投資予算は決めるのだろうけど、実際そういう段階の話に関わった事はないんでよくわからない。
また、予算はそういうふうに決めていたとしても、SIerへの発注をどうするのかはまた別の話だしね。

というわけで、あまりまとまっていませんが、顧客への課金方法は色々手を打ったとしても、内部のコスト計画上で人月の考え方は外せないわけで、収益ベースとコストベースが直接リンクしないところをいかに折り合いを付けてビジネスモデルを作るかっていう、他の産業だったら普通にやってそうな事をやる必要があるよという話だね。

さらにSIerにとってはシステム投資の顧客価値をいかに見極めていくかというのが大きなテーマとしてあって、さらにその範囲内でできるだけ「高く売る」にはどうしたらいいかを考えていく必要があるよね。顧客のシステム投資に対する意識を変えていけるような提案が必要なわけです。
一般的なレベルの話では、やっぱり蓄積したノウハウを結集して何がしかのテンプレート化、パッケージ化、サービス化をするって話なんだろうなぁ。
その「何がしか」をどう見極めるかが問題なわけだし、今まで普通に受託開発だけやってきた会社にそう簡単にできる事じゃないのだろうけどね。

プロジェクトマネージャ試験はまた不合格で

あまりタイムリーな話じゃないですが、4月に受けたプロジェクトマネージャ試験はまた不合格だったようです。
今回も論文の判定Bということで、あと一歩。
あと一歩なんだからちゃんと対策して臨めよ、って事だと思いますが、それもなかなか。。。

今回は午前Ⅱと午後Ⅰの足切りの通過もぎりぎりだったようなので、また全般的にブラッシュアップしとかないといけないかな、と思いました。

秋はまた別のを受ける予定です。

朝型にできなくて何が悪い

私も超夜型人間、朝型にしたくてもできない。
今日はたまたま起きれて、これを書いているけど。

会議が朝8時開始に!? “朝活ブーム”で追い込まれるギリギリ社員
誰もが残業をするより、早朝に仕事した方が効率的なことはわかっています。ですから調査すると、「残業は避けて早起き人間になりたい」と半数以上の人が答えます。

確かに最近は自主的に早出している人が増えた。
私は直接被害は被っていないけど、会議までやっている人達もいる模様。

でも「朝の方が頭の回転がよく効率がいい」とか言うし、確かにそうかもしれないが、早出して仕事しているって、結局定時内で仕事しきっていないことには変わりなく、サービス残業しているのと一緒じゃない?って気がするのだが。

色々なライフスタイルの関係で定時後の夜に仕事しなくて済むようにする工夫の一つとして有効だとは認めるけど、早出しておいて「ノー残業」をアピールされても、それはちょっと違うんじゃないのと思ってしまう。

周囲とは協調してうまくやっていく必要はあるけど、結局は成果を上げているかどうか、そこに自信があれば朝型だろうが夜型だろうがどうでもいい。

私自信がその成果を上げているかどうかはさておき。。。

プロマネになりたくない理由

タイトルが自分の感覚とはだいぶ違った印象だった。「今さら」か、という感じで。

PMになりたくない症候群 - 斎藤昌義(さいとう まさのり) - ZDNet

私の感覚では「プロマネ(PM)になりたくない」人は以前の方が多くて、最近の若い人の方が「PMになりたい」的な事をちゃんと言う奴が増えた、との印象だった。

以前は「PMになりたくない」というよりは「PMになるキャリアパス自体に考えが及んでいない」という感じで、「とにかく技術を磨かなきゃ」という雰囲気が大勢だった気がする。
それがここ数年で「プロマネ」ということを上の方から言い出し始めて、それで意識付けされて素直に乗っかる下の人間も普通に出てきた、という感じかな。さすがに「ゆとり」教育を意識する程の若い連中から、この辺の話を聞く機会はまだないけど。

色々と物事が波及する際の大手と中小の時間差という事なのかもしれないし、単に自分の立場が上がってきたことで、そういうことも見聞きするようになってきただけのことかもしれない。

私自身は以前から積極的に「プロマネはやりたくない」と思ってきた方だった。
なぜだろう?
やっぱり技術を磨き素晴らしい仕組みを作り上げるのが楽しいわけで、技術がわからなくなり、わからないまま管理と調整だけに明け暮れるのが嫌だったのかな。
だからチームリーダーとかになっても、実装も含めて全部自分自身でできる前提でメンバーの作業を回していた感じになってた。
とにかくアサインされてくるから仕事を割り当てなきゃ、みたいな。
もちろんスケジュールの都合等で実際に全部を自分でやることは無理なんですけどね。
ともかく、そんなやり方だと人数増えてくると立ち行かなくなる。

だから、最近は「プロジェクトマネジメント」の重要性は理解していますよ。
それは自分が成し遂げたい仕事が、自分一人の力ではやりきれない規模になってきたからで、人に動いてもらうにはプロジェクトマネジメントのスキルとかタスクは必要だな、と。

でもそれは「プロジェクトマネージャ」になりたいわけでは決してない。
自分はあくまで「プログラマ」であり「技術者」なわけで、そういう職種にあって自分が関わるプロジェクトを推進する為にマネージする必要があるというだけのこと。
プロジェクトマネジメントのスキルって、色々と難しい事を言う人もいるかもしれないけど、要するに人と協調・協力して仕事をうまく進めていく為のスキルみたいなものなんで、程度の差はあっても誰もが持つべきものだと思うんだよね。

ITSSなんかにも職種として「プロジェクトマネージャ」とか定義されているけど、専門職種としての「プロジェクトマネージャ」なんて意味がない、というか、本当に成り立つのか?と思います。
役割としての「プロジェクトマネージャ」をやるとしても、PMとは別に専門分野を持っていなければまともな仕事はできないと思うだが。

今でも「いざとなったら自分でもやる」気は十分持っているし、「とっかかり」に以前よりは時間かかるかもしれないけど、実際やれる自信はある。
でも、そうなった時ってほぼ「デスマ」なんだろうな、と思うわけで、そうならないようにするのがある意味では自分の仕事になってきいるわけでもあります。

そんなわけで、私は相変わらず「PMになりたくない」派なようです。

追記:
そういえばこんなのがあったのを思い出した。

404 Blog Not Found:スーツの道も、舗装するのはギーク
口を動かすのがスーツなら、手を動かすのがギーク。それさえわかれば、何を着てようがギークを名乗っていいしそうするべきである。スーツを着ているから、スーツな仕事をしているからギークにあらずという輩は、はっきり言ってまだギーク度が足りない。
スーツの言葉など、当のスーツすら動かせない。手の裏付けのない言葉はあまりに安い。人を動かしたかったら、まず自分の手を動かせ。手が塞がっていたら、手を動かした経験を語れ。口で語るな手で語れ。
スーツを身にまとっても、負けじゃない。しかしそれを魂に纏ったら、負けなのである。

晒している人こそ、強いのだから。

ギークとは、魂に纏わないもののことである。
職種としての「プロジェクトマネージャ」というのは、ここでいう「スーツ」に近くなるのかなと。
「スーツ」にはなりたくない、でも「スーツを身に纏わざるをえなくなってきた」ということ。
で、それでも「スーツを身に纏ったギーク」であるべく心がけよう、ということだ。

金融庁の「IFRSに関する誤解」について思ったこと

少し前に金融庁より「IFRSに関する誤解」という資料が公表されましたが、それについて思った事を少々。

金融庁、IFRSに関する17の「誤解」を公表 - IFRS 国際会計基準フォーラム
金融庁は4月23日、IFRS(国際財務報告基準、国際会計基準)についての17の質問とそれに対する回答を集めた「国際会計基準(IFRS)に関する誤解」と題する文書を公表した(PDF)。「一部に『誤解』を招く情報が流布されているのではないかとの指摘がある」として、文書の公表で正しい理解を得られるようにするという。

まあ、IFRSに関するいろいろな記事が出回るようになって、それらを「ななめ読み」しているだけだと、こういう誤解をしてしまう人も出てくるのかもしれないな、というのはよくわかった気がする。

で、さすがにこれには、あきれた。
3.全面的なITシステムの見直しが必要か
[誤解]IFRSになると、ITシステムを含め、業務プロセス全般について全面的に見直さなければならない。
[実際]既存のシステムの全面的な見直しは、必ずしも必要ではない。
  • IFRSを適用するために必要な範囲で、システムの見直しを行えばよい。
「必要な範囲で」やればいいのは当然。
実際にこんな誤解をしている人がいるからこそ、取り上げているのだろうけど、当たり前過ぎる、アホか、というのが第一印象。
ただ、「見直し」をどういう意味で捉えるかによっては、別に誤解でもない気がする。
「見直し」に「変更が必要かどうかの見極め」も含めるのであれば、「全面的な見直し」はやっぱり必要なんだと思うけど。
その結果として必ずしも「変更」が必要とは限らないわけで。

収益認識の出荷基準の件は、微妙な表現で結局誤解は正せていない気がする。
というか、誤解として挙げつつも誤解ではないとしているというか。
[誤解]IFRSでは、収益の認識基準が我が国とは異なり、我が国でこれまで広く使われていた出荷基準による売上の計上が認められなくなる。
[実際]現在の日本基準は実現主義であり、現在のIFRSの収益認識基準(リスクと便益の買主への移転)に照らし合わせても、ほぼ同様の結果となるが多い。例えば、取引の形態によっては、着荷や検収の事実を一々確認しなくても、出荷の事実をベースに、配送に要する期間等を考慮して、合理的にリスクと便益の移転が認められる場合、その時点で売上の計上ができる場合がある。いずれにせよ、プリンシプルに照らして、個々具体的な事例に即して適切に判断することになる。
結局、出荷した事実のみをもっては売上計上できず、結果として出荷基準そのものは認められないと言っていることになるように思うのだが。

出荷基準は、税務上の観点から採用されたものが簡便的にか財務会計にも適用する事が認められてきたというのが実情というのをどこかで聞いた。出荷で収益認識した方が目先の課税対象が増えるわけだからね。
だから日本の会計基準における収益認識基準自体はIFRSとほぼ同等なので、会計基準の差異というよりは、税務との折り合いを付けて統一した基準でできるか、という問題なのかなという気がする。

プロジェクトマネージャ試験をまた受けた

昨年に引き続き、という事で、プロジェクトマネージャ試験を受けてみました。

昨年は午後Ⅱの論文で落ちたという事もあり、午前Ⅰは免除申請しておきました。

今回も全く事前の試験対策なしで受けてしまった。
そういうのもいい加減、時間の無駄なんじゃないかという気もしてきたけど、この辺の試験は日常的に仕事で考える事も多いから、特別な事をしなくても数をこなしていけば、何とかなるんじゃないか、という気もしています。

今回の論文は最低限の字数制限はなんとかクリアしました。
段落とか考慮して厳密な字数を足りていない設問もあったと思うけど、日本語の記述ってそういうもんだしね。

内容的には、自分なりに精一杯ひねり出して書いたけど、なんだかなあ、という感じでした。

まあ、終わった事はもう仕方ないので、後は結果を待つだけで、違う事に切り替えます。

仕事ができる部下は結構多い

平均的に見ればそんなものだというのは、感覚的にはわかる気もする。

リーダーが必ず受け入れるべき3つの指針 |「稼げるチーム」をつくる!営業マネジャーの教科書|ダイヤモンド・オンライン
部下を持ったら真っ先に受け入れることは、「部下はリーダーのせいぜい30%しか仕事ができない」ということです。実際には20%とか40%かもしれませんが、心構えとしては、部下は自分の3分の1程度しか仕事ができないと考えておくことです。

でも、最近私がよく思うのは、仕事できる人は結構たくさんいる、という事。

自分の期待通りの結果が出て来ないのは、自分の期待をちゃんと伝わっていない事が原因として大きい。
もちろんそれを伝える為にどれだけこちらが労力を使わなければいけないか、で「できる」と「できない」の評価に影響してくるというのはあると思います。

また、良い意味で期待を上回る結果を出してくる事もよくある事だし、そう考えると「30%」はちょっと低く見積もり過ぎな感じがしました。
逆に「30%」くらいしか仕事を与えないから、そうなるという事かもしれない。

自分の場合は、いかに「マイクロマネジメント」から脱却するか、という事がテーマかもしれない。

再びグロービス

以前こんな事も書きましたが、また4月からグロービスの講座を受講する事にしました。
本当は昨年10月期に受講しようと予約したけど、突然忙しくなりそうだったとかいろいろあってパスしていたんですが、いよいよポイントが有効期限切れになってしまうという事で決めました。

4月以降の多忙感はまだ全然わからないんですが、まあ「基礎クラス」なんでなんとでもなるかなあ、と思っています。

WinShot

個人的にはすごく「今さら」な感じでびっくり。
仕事上で長らく必需品になっていて、いつから使っているかも覚えていない。
テストのエビデンス取りとか、画面ショット付のマニュアルとか。

勝間和代公式ブログ: 私的なことがらを記録しよう!!: これはいい!!! スクリーンコピーをかんたんにファイルに保存できるソフト、WinShot
ネットサーフィンしていてみつけたのですが、これはいいです。

まあ、人それぞれいろいろな巡り合わせがあるからね。

良いソフトである事には間違いないです。

怒涛の3ヶ月を終えて

仕事そのものなので詳しい事は書けないが、怒涛の3ヶ月が終わった。

要するにものすごーく忙しかった、という事なんだけど。

この間は本当に"living someone else's life"な感覚だった。
もちろん細々とした部分では新しく学べた事もたくさんあったけど、
総合的に見れば「なぜオレが今これをやってなければいけないのか?」って感じで。

そんな感じで半分腐りかけてても、何とか踏ん張って
"What is this here to teach me?"を考えるようにしていた。

久々に唯の末端の作業者の位置付けだったので、
普段とは異なる視点でプロジェクトの運営が見れたかな、と。
中途半端にリーダーではない一メンバーから見て、
「リーダーはこうではいけない」という事を色々と再認識できたと思います。

たとえ個別の担当作業とは直接関係なくても、
プロジェクトやチームの全体状況は共有しないといけない。
過酷な状況になってくると「終わりが見えない」感が精神的には相当きつい。
問題は日々積み上がっていく状況だとしても、
「後どれだけあるのか」がみんなに見える状況にする事って大事だよね、と改めて思った。

まあそれがなされていなかったって事で、反面教師として再認識したのですが。
というか、いろいろツールも駆使してそれなりの環境はあったんだけど、
そこまで機能していないという感じでしょうか。

そんな感じで意味があったのは認めるけど、3ヶ月は長かった。
記事検索
プロフィール

ntakano75

フリーランスでシステムエンジニアをやっております。

Twitter
AdSense
Amazon
  • ライブドアブログ