タグ

ブックマーク / okachimachiorz.hatenablog.com (10)

  • 2014年のSIビジネスとかそのあたり - 急がば回れ、選ぶなら近道

    というわけで2014年に突入ですが・・・ 景気が回復しつつある現状で、SIの受注も好調なようです。ユーザー企業でも多少の予算の余裕も出てくるところもあり、システム投資には多少前向きになっているところも感じます。多少のでこぼこや、業界・業種によって色合いは異なるでしょうが、今後数年は景気の回復基調はコンセンサスになりつつあるようです。IT業界も例外ではないでしょう。もたもたしているビッグデータ案件を尻目に、システムリプレースや既存改修、新規でのシステム開発もスタートしつつあり、SI業界の件数ベースは今年は昨年を確実に上回るでしょう。 とはいえ一方で不採算案件も相当増えるように見えます。結果、SIビジネスはトレンド的には案件増・売上増ですが、利益減(または横ばい)というのが実態になるかと。要するに単金はそうそう簡単にはあがりませんが、案件は増えて、人繰りが追いつかず、結果限りなく失敗に近い「よ

    2014年のSIビジネスとかそのあたり - 急がば回れ、選ぶなら近道
    indication
    indication 2014/01/26
    ここ2年が勝負だと思う。まぁいつも勝負だけども
  • システムの「価値」をどう考えるのか?〜なんで人月換算基準がなくならないか、について - 急がば回れ、選ぶなら近道

    「なんで人月換算基準がなくならないか」については、これは作る側での議論が非常に多いのですが、逆側から見た議論があまりにも少ないので、自分の考えを記録しておきます。そもそも、発注した側ではシステムの価値をどう見るのか?という議論があまりにもなさ過ぎの印象があります。いくら作る側が頑張っても、発注サイドで「いやだから、結局いくらかかったか内訳見せろ」という話になった途端に、残念ながら人月単価が登場するわけで、話は振り出しに戻ります。 まず一義的にはユーザーから見たシステム開発は投資になります。確かに、毎年作っているでしょう、という話もありますが、普通は数年に一回作っては動かして、メンテナンスにモードに移行させる、という形になります。投資として、通常はキャッシュ・アウトに相当するコストで資産を認識します。リースにすれば、定常的でしょうという話もありますが、オン・ブックになった途端に普通に取得原価

    システムの「価値」をどう考えるのか?〜なんで人月換算基準がなくならないか、について - 急がば回れ、選ぶなら近道
    indication
    indication 2013/07/16
    システムの必要度合いでの価値、業務パターンを網羅する(例外)場合の価値、データ量での価値、インフラとしてみたときの価値
  • なんでもかんでもクラウドにあげるのか? - 急がば回れ、選ぶなら近道

    某エントリーの話で、「なんでもかんでもクラウド化なのか?」というお話もご意見も多数頂戴いたしまして。一応念押しですが、そういうつもりはまったくないですよ。以下、個人的な補足メモです。会社の意見ではありません。一応、会社の公式声明は「できるものは、とっとクラウド化したほうがいいですよ。」です。 クラウド化の是非については、いろいろあるでしょう。ユーザーの所属する産業毎にシステムのあり方・考え方は違うでしょうし、当然クラウド化すべきだという意見や、いやそもそも無理があるという意見もあると思います。ただ、今までのように先例がないから無理、という理屈は通用しなくなっているのが現状でしょう。その意味では無茶な理屈ではなく、普通に選択肢としてクラウド化が候補になっている、と思います。その上で、クラウド化しない、するという議論が普通にできる状態になりつつあると思います。 そんな中でいろいろ思うところをち

    なんでもかんでもクラウドにあげるのか? - 急がば回れ、選ぶなら近道
  • クラウド上にEDIを「移行する」ということの意味 - 急がば回れ、選ぶなら近道

    ニュースリリースというか記事はこちら。日経の中田さんの記事ですね。 http://itpro.nikkeibp.co.jp/article/NEWS/20130306/461423/ この辺の解説を記録のために書いておきます。個人的にはちょっとしたマイルストーンなので。 まずEDIの定義ですが、これはElectronic Data Interchangeの略で、B2Bでの電子データ交換の仕組み自体をさします。歴史的にはIT歴史と同じくらい古い。当然インターネットよりも古い。昔は(場所によっては今も)電話で”ぴー”とか”がー”とかやっていた代物です。多分50年以上の来歴を誇る仕組みですね。業界ごとにその業界に応じたプロトコルが制定されており、いわゆる標準化がもっとも進んだ分野のひとつです。そして、大抵はミッションクリティカルな業務に属します。エンタープライズ系のITでは最下層に位置するレイ

    クラウド上にEDIを「移行する」ということの意味 - 急がば回れ、選ぶなら近道
    indication
    indication 2013/03/11
    faxはなくならない
  • バッチ処理を再考する - 急がば回れ、選ぶなら近道

    最近そもそもバッチ処理というものを知らない人達を見ることが多くなりました。某プロジェクトで「いや、ストプロってよくわからないんですよ。最近書いたことないし。」という話をずーっと聞いていたのですが、人はバッチ処理という意味で話していたことが後から判明した、ということがありました。 ああ、この人はSQLでのバッチ処理しか知らないのですね、とちょっと衝撃ではありました。とうとうそーゆー時代になったかと。 まず、誤解のないようにいうとバッチ処理、という言葉自体はIT固有のものではないです。生産管理や物流や、そういった業務では普通に「バッチ」という言葉をIT以外で使います。ただし意味はある程度同じで、「一定の塊を一度に処理をする」ということです。物流システムの業務要件なんかを詰めているとバッチっていうと、どっちのこと?なんて普通に聞かれたりします。その意味ではバッチの対義語がリアルタイムというのは

    バッチ処理を再考する - 急がば回れ、選ぶなら近道
    indication
    indication 2012/11/26
    結果をあとから見れるようにするだとか、進捗を見えるようにするだとか、そういった部分を作り込むのがとても変態
  • SIで得るものはあるのか? - 急がば回れ、選ぶなら近道

    「SIで得るものはあるのか?」 おそらくここ10年以上、日各地で自問自答された問いでありまして。かくいう自分もその一人であります。デスマの度に、ここまでやる意味はあるのか?赤字の度に、そこまでやる意味はあったのか? 思わなかった人はいないはずです。特にここ数年は、見るもの聞くもの、酷いプロジェクトが自分の周りでも多く、「いいから、そのまま回れ右」という行動パターンの機械学習全開です。(遠い目 他方、「構築をやらないと確実に実装力は落ちる」こういう声もあるでしょう。これもまた真実ではあります。特に、SIの中身丸投げモードのスイッチが入りっぱなしで液漏れ寸前なところは、もはや経験不足を通り越して「リバース・プロキシーって何をするんだっけ?」って真顔で聞くPMの方もいらっしゃる状態もありまして。実際にやらないとわからない、ということは普通におきます。特にアーキテクチャやインフラ周りは、そうなっ

    SIで得るものはあるのか? - 急がば回れ、選ぶなら近道
    indication
    indication 2012/08/27
    ニッチなものになりつつある
  • 小売業における個別原価法とシステムとその先に - 急がば回れ、選ぶなら近道

    まず小売業の利益計算の基的な会計処理は売価還元法になっている。ありとあらゆる原価法の中でもっともザルで、かつ、いい加減な方法の一つである。端的に言えば、一定のカテゴリーベースでの売価の総額と仕入の総額を総計して、原価率を算定して、その率をもって利益を算出する計算方法になる。また、基的に棚卸法になるため、実際の棚卸を行い、原価計算期間終了時点での在庫金額を確定させないと、利益が算出されない仕組みである。 現場感覚でいうと、値入率(事前想定粗利率)から、実際のロス率を差し引いても、粗利率(事後達成粗利率)に一致しないため、直感に反するオペレーションになる。このため、数字にしっかりした人間であればあるほど、数字を信頼しないというモラルハザードな仕組みになっている。さらに、そもそも小売流通業の税前利益率は2-3%を達成できれば“優秀”であり、細かい利益率の管理が必須である。バイヤーレベルでは、

    小売業における個別原価法とシステムとその先に - 急がば回れ、選ぶなら近道
    indication
    indication 2012/03/27
    個別原価を求めるいい仕組みがあったら、教えてほしいという内容
  • いわゆる仕様と業務例外について - 急がば回れ、選ぶなら近道

    最近とにかく、移動が多いので、その中でちょいちょい考えたことをまとめておきます。まずは仕様の理解の仕方とか、業務例外とか、押さえておきましょうという視点から。別にこれが正解で必須というわけではないので、あくまで個人の経験をまとめただけです。 モデリングとか、なんというかそういう高尚な話ではなくて、実際に仕様をまとめるときに、現実的に落ちる穴を、経験的に書きます。大抵のプロジェクトでは、仕様が固まらずに、または手戻りが発生して酷くコストが膨らむということがやはり多いわけで。理屈はともかく自分の経験的な対策案です。 (なんというか、開発方法論や手法・ドキュメントのまとめ方は、なんとかBOKから始まって、アジャイルや押しくらまんじゅうやらでいくらでもであるのですが、その一方で丁寧な要求定義や設計それ自体ができる人材は、むしろ急激に減っているような印象すら受けます。海外からの翻訳や輸入はやたらと多

    いわゆる仕様と業務例外について - 急がば回れ、選ぶなら近道
  • "BigData"では何が問題なのか? - 急がば回れ、選ぶなら近道

    ”ビッグデータで奇跡が起こる” はいどうも。まず、個人的には楽天的な進歩史観には、まったく組しない。 従って、突然に新技術ができて、なんか凄い事になる、というのはさらにまったく同意しない。すべからくブレイクスルーは課題解決により起こると思っているので、問題意識のないところに、こんなものできました的な発想は、基的にプラスにならないことが多いと思っている。現状のビッグデータブームは2011年の秋口現在は完全にハイプになっており、バブルと言ってもいいと思う。印象として、十数年前のナノテク・ブームに似ている。 とはいえ、過度の期待という側面を除けば、それなり効果もある部分もあり、”そこだけ”を見ていけばそれなりに効果はある(と思う)。大体において、今後は以下の二つのユースケース・カテゴリーに集約されると思う。すなわち、ビッグデータの拠り所はまずもって以下の2点だ。 1 Webのログ解析 というか

    "BigData"では何が問題なのか? - 急がば回れ、選ぶなら近道
    indication
    indication 2011/12/12
    目的不明が問題
  • システムはどこまで内製化できるか - 急がば回れ、選ぶなら近道

    どこでも何回も何十回も言われているが、システムを経営の変化に対応させるにはある程度のシステムの開発を内製化すべきである、という論調が強い。この問題は、古くて新しい問題であり、と同時におそらく、いままでとは違うコンテクストで語られることになるような気がしている。ここ10数年の流れを見れば、内製化の議論はアウトソーシングの流れとそのより戻りの反復運動の繰り返しだといっていても過言ではなかったと思う。近年はむしろ、SI屋さんの全体的な弱体(特に技能として)化とクラウド等によるインフラの導入しやすさと相まって別の背景で語られることが多くなってきている。また、見逃せない背景としては、そもそもの就労可能若年層の減少と、若年層の総体数減少による能力のばらつきの顕在化も強くあげられる。特にシステム開発の供給サイドの問題は、エンドユーザーの内製化の議論においては、今までのコンテクストでは語られることがなかっ

    システムはどこまで内製化できるか - 急がば回れ、選ぶなら近道
  • 1