タグ

SIに関するlluviasのブックマーク (5)

  • システム屋に不当にボッタクられたくない人のための要求講座 - novtan別館

    増田の記事を見て書こう書こうと思いつつ週末は忙しくて書けなかったのでドックイヤーどころかバンブーデイと言われる(今作った造語だが)ソーシャルメディア界隈ではもうネタにならないんじゃと思いつつ引っかかった場所を中心に書いてみようと思います。 元増田はここ→システム屋に不当にボッタクられないための発注者心構え 何もIT知識のない素人企業を、スキあらば適当な見積もりでボッタクろうとするシステム屋ばかりでここはひどいインターネッツですよ。 世知辛い世の中です。 こういう「知らない人」を宥める挨拶を持ってくるとは、この元増田、素人ではないっ…とはいえ、ちょっとこのあとに書かれていることは要求のレベルが高すぎるんじゃないかと思います。僕達SIerというのは、「何やればいいかよくわかんないんだけどシステムで会社を良くしたい」って思っている人をお助けすることも大事な仕事です。もっとも、そこまでのレベルの会

    システム屋に不当にボッタクられたくない人のための要求講座 - novtan別館
    lluvias
    lluvias 2013/10/10
    Excel、Accessはとてもコスパの高いシステム。それで実現できそうなことなら、システム屋なんて呼ぶ必要ないよ。
  • システム屋に不当にボッタクられないための発注者心構え

    http://anond.hatelabo.jp/20131003212934 うんうん、そうですね。 何もIT知識のない素人企業を、スキあらば適当な見積もりでボッタクろうとするシステム屋ばかりでここはひどいインターネッツですよ。 世知辛い世の中です。 ●要求は最初になるべく細かく紙に書いて突きつけましょう システム屋を呼ぶときにノー資料ではいけません。思いつくまま口頭で話しても、彼らは都合よく曖昧に解釈するだけです。できあがるシステムはそりゃあもう役立たずですよ。 箇条書きで良いので、システム化したい業務フローは全部書き出しましょう。正常な業務フローだけじゃなくて、イレギュラーパターンもちゃんと明記しておかないと、実装の際に彼ら絶対サボりますよ! 整合性の取れたそいつで彼らの頬をペチペチ叩いてやれば、彼らはあなたのことを素人のカモとは見なさなくなります。 ●予算感は最初に伝えましょう シ

    システム屋に不当にボッタクられないための発注者心構え
  • 株式会社ノーチラス・テクノロジーズ

    劔"Tsurugi" 新しいハードウェアアーキテクチャ(メニーコア・大容量メモリー)に合わせた設計思想で、 性能を最大限に発揮するデータベース Asakusa Framework 業務システムのバッチに並列分散処理の能力を活用するためのフレームワークです。大容量のデータ・複雑な処理を多数のコンピューターに分割して処理し、従来のシステムでは難しかった処理も実現できます。 Asakusa on M³BP Asakusa on M³BPは、分散処理の開発フレームワークであるAskausa Frameworkと、マルチコア環境でDAG形式で並列処理をするインメモリエンジンのM³ for Batch Processing(略称:M³BP)を組み合わせたデータ処理高速化のソリューションです。フィックスターズ社との共同開発でOSSとして公開しています。

  • 急がば回れ、選ぶなら近道

    TsurugiとRSA 2023/12現在、Tsurugiは単ノード稼働の制約があるので、次のフェーズとして複数ノードでの稼働を目指しています。Tsurugiは直接の操作対象データのindex treeをメモリーにもつRDBであり、単ノードでのメモリー限界がパフォーマンス限界になります。複数ノードにまたがるメモリー・クラスターでの透過的な稼働をTsurugiの次の目標としています。想定されているアーキテクチャはRack Scale Architecture(以下RSA)になります。 RSAについては、まずこのポストがスタート地点。 https://okachimachiorz.hatenablog.com/entry/20151225/1451028992 これは2015年なので、8年前のエントリーになります。概ねコンセプトは変わっていません。(8年前は誰かがつくるだろうとおもっていたけど

    急がば回れ、選ぶなら近道
  • システムの「価値」をどう考えるのか?〜なんで人月換算基準がなくならないか、について - 急がば回れ、選ぶなら近道

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

    システムの「価値」をどう考えるのか?〜なんで人月換算基準がなくならないか、について - 急がば回れ、選ぶなら近道
    lluvias
    lluvias 2013/07/16
    全く同じシステムでも1億で買ってくれるお客と1000万円でも高いといってくるお客がいる。営業は業務知識云々よりそれを見極めることに努力しちゃうよね。利己的だけど
  • 1