小売業における個別原価法とシステムとその先に - 急がば回れ、選ぶなら近道
まず小売業の利益計算の基本的な会計処理は売価還元法になっている。ありとあらゆる原価法の中でもっともザルで、かつ、いい加減な方法の一つである。端的に言えば、一定のカテゴリーベースでの売価の総額と仕入の総額を総計して、原価率を算定して、その率をもって利益を算出する計算方法になる。また、基本的に棚卸法になるため、実際の棚卸を行い、原価計算期間終了時点での在庫金額を確定させないと、利益が算出されない仕組みである。 現場感覚でいうと、値入率（事前想定粗利率）から、実際のロス率を差し引いても、粗利率（事後達成粗利率）に一致しないため、直感に反するオペレーションになる。このため、数字にしっかりした人間であればあるほど、数字を信頼しないというモラルハザードな仕組みになっている。さらに、そもそも小売流通業の税前利益率は2-3%を達成できれば“優秀”であり、細かい利益率の管理が必須である。バイヤーレベルでは、
いわゆる仕様と業務例外について - 急がば回れ、選ぶなら近道
最近とにかく、移動が多いので、その中でちょいちょい考えたことをまとめておきます。まずは仕様の理解の仕方とか、業務例外とか、押さえておきましょうという視点から。別にこれが正解で必須というわけではないので、あくまで個人の経験をまとめただけです。 モデリングとか、なんというかそういう高尚な話ではなくて、実際に仕様をまとめるときに、現実的に落ちる穴を、経験的に書きます。大抵のプロジェクトでは、仕様が固まらずに、または手戻りが発生して酷くコストが膨らむということがやはり多いわけで。理屈はともかく自分の経験的な対策案です。 （なんというか、開発方法論や手法・ドキュメントのまとめ方は、なんとかBOKから始まって、アジャイルや押しくらまんじゅうやらでいくらでもであるのですが、その一方で丁寧な要求定義や設計それ自体ができる人材は、むしろ急激に減っているような印象すら受けます。海外からの翻訳や輸入はやたらと多
業務系システムのクラウド適用の現状 - 急がば回れ、選ぶなら近道
2013年の夏・秋の状況の整理として記録しておきます。数年したら変わっているか、そもそも自分の仮説が違うかわかるのでそのポイントとしても記述しておきます。 4月以降、「業務系システムのクラウド化」ということで、顧客各社やマーケットへのヒアリングを行ってきています。対象はいわゆるWeb系は除いてあります。曖昧な言い方になりますが一般に「IT業界でエンタープライズ」と言われるセグメントにフォーカスしています。結果としてわかったのは、企業のクラウド利用についての意識は、言われているほどには高くはない、というのが現状です。ただし、これは一様に低い、ということではなく、かなり業界やセグメントや企業規模によって違いがあります。この違いの要因と今後どのようなところに影響するのか、というのが興味の焦点です。尚、これは自分個人の印象や某社でのヒアリングの整理のみをよりどころにしているので、たかだか200社弱
設計と実装の狭間で - 急がば回れ、選ぶなら近道
・現状 ・・・相変わらず溝は埋まっていません。希望の星と目されたDSLは現時点ではかなりの不発弾に近い感じで、設計系クラスターはあまり元気がないですね。翻って見れば、設計と実装が最も近かった時代は、なんのことはなくて、自分も含めて（懐古趣味の老人を除いた）皆さんが毛嫌いするCOBOL＋汎用機の時代だったかもしれないという意見すら出る惨状です。あの時代以降、 UMLが登場し、まさに銀の弾丸状態で、それ以降Unified Processやら何やらが、インフルエンザの如く流行りました。ま、その延長上に今のアジャイルまでの流れがあるわけですが、気がついてみれば、これほど設計と実装が離れてしまった時代もないという状態になってしまっています。・・・設計と実装の狭間は、相変わらず埋まっていない気がします。 ここへ来て、実装技術の多様化は、カンブリア紀を思わせる拡大の一途になっています。開発環境のみならず
業務系SEの末路的なお話でして - 急がば回れ、選ぶなら近道
某DevLoveというところで話をしろ、ということでありましたので、いろいろ話をして来ました。 http://devlove.doorkeeper.jp/events/1733 まとめはこちら http://togetter.com/li/387189 あと、しんやさんの詳細なブログがこちら http://d.hatena.ne.jp/absj31/20121009/1349795347 スライドはこちら http://www.slideshare.net/okachimachi/devlove1 以下、ちょっと自分なりにまとめを。 ■自分なりにどう話したか 自分の仕事的にはHadoopとAsakusaでの課題解決が現在の本業です。ただ、Asakusaの位置づけとして、SIのための道具立てという側面が強く、また結果として会社も直接・間接にSIにはかかわっているので、割と現状の問題も意識して
SIで得るものはあるのか？ - 急がば回れ、選ぶなら近道
「SIで得るものはあるのか？」 おそらくここ10年以上、日本各地で自問自答された問いでありまして。かくいう自分もその一人であります。デスマの度に、ここまでやる意味はあるのか？赤字の度に、そこまでやる意味はあったのか？ 思わなかった人はいないはずです。特にここ数年は、見るもの聞くもの、酷いプロジェクトが自分の周りでも多く、「いいから、そのまま回れ右」という行動パターンの機械学習全開です。（遠い目 他方、「構築をやらないと確実に実装力は落ちる」こういう声もあるでしょう。これもまた真実ではあります。特に、SIの中身丸投げモードのスイッチが入りっぱなしで液漏れ寸前なところは、もはや経験不足を通り越して「リバース・プロキシーって何をするんだっけ？」って真顔で聞くPMの方もいらっしゃる状態もありまして。実際にやらないとわからない、ということは普通におきます。特にアーキテクチャやインフラ周りは、そうなっ
業務系エンジニアはどうしていくべきか？ - 急がば回れ、選ぶなら近道
まず超個人的な見解です。あとWeb系の人は関係ないので、そういう人は読んでも無駄です。ここでいう業務系エンジニアというのは、主にSI屋で特定企業向けのシステムを構築しているエンジニアの人たちをさします。 まず、非常に難しい時代になったと思います。 端的に、ちゃんとしたSIをやることが難しくなりました。まず、技術的には面倒なことが増えた、というかできるオプションが制御できないくらいに増えているので、うまく制限をしないとコードや仕組みが劣化する一方になりました。エンジニアリングに自由を！というのは聞こえはいいのですが、チームプレーをするのに、いちいち約束事決めないと回らないようになっているような気がします。それも毎回。始めるたびに。 別段、いきなりチームメンバーの能力があがったり、さがったりするわけではないのですが、なぜか外すと酷いことになる振れ幅が増大したような気がします。ルール決めをいちい
SI屋さんとSIと、直近の課題について。 - 急がば回れ、選ぶなら近道
某セッションでちょっとしゃべったことをつらつらと。SIの現状と近い将来について思うところをまとめておきます。自分自身の立ち位置も確認していくという意味で。 結論的にいうと、SI自体は必要とされていますが、SI屋さんのビジネスモデルは成立しないという状況になるので、旧来の「SI屋さんの方法」ではうまくいきません。なので、別のやり方でSIをどうやっていくか？という議論が必要になりますね、という話です。 まずSI事業は人月稼働で商売をしています。スタート地点はそうではなかったのですが、一旦大きな人数を抱えると、食わせる必要があるため、より大きな仕事を取る羽目になります。要は稼働させる事、それ自体が目的になります。稼働を維持させる事で、収入を確保する事ができ、確保された収入で稼働のための人員を維持できる。そもそもそういう循環をベースに組織の目的が、「結果として」形成されてしまっています。 副作用と
大規模SIは少数精鋭で乗り切れるのか？ - 急がば回れ、選ぶなら近道
まず現状の認識は以下の通り 1.20-30代の就業人口の減少これは大前提になる。 また情報共有も進むためよりブラックな会社が 人を集めること自体のハードルがあがる。 結果として、人員を集めるということがより厳しくなる。 これはITに限らず、労働集約的産業全体の課題でもある 2.能力格差の拡大今の40-50代よりも間違いなく、現状の20-30代は 勉強している人としていない人の格差は広がっている。 ゆとり云々とは別に、社会的なプレッシャーから、 むしろ勉強しないと勝ち残れないという強い意識のある集団と、 ゆるふわほんわか草食集団の差が非常に非常に広がっている 3.資源の拡大要するに、割とハード・リソースに余裕が出てきている まず、クライアントサイド。 要はなんでもできる状態になりつつある。 jsあたりはほぼ無法地帯の感もある。 一時、jsでOSみたいのまでいけるぜ、というデモもあったが 技術
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
