見積りの根拠出してくれっていったら、金くれって言われたよ
システム屋の常識ってものが分からないのですが・・。 社内の業務をいくつかIT化することになった。ACCESSとかでも頑張ればできそうな感じだったんだけれど、システム屋にやらす方向で進めることになった。 何社かシステム屋呼んで、こっちのやりたいことをいって、概算金額出させてた。この時出てきた金額が350万～2200万。こんな簡単なシステムなのになんでこんなに金がかかるのか・・。なんでこんな差があるのか・・。（この時点でシステム屋業界に対しての不信感が社内に生まれることになった。）結局、一番低い金額で出してきたところが、営業の印象もなかなかよく、そこに決めることになった。 その後、細かい金額出させるために何度か呼んで、必要なことを事細かく伝えて詳細見積りとスケジュール表を出せっていった。それで出てきたのが、A3の紙１枚で4項目ぐらいのざっくり見積りと、設計期間・製造期間・動作確認期間っていう期
システムの「価値」をどう考えるのか？〜なんで人月換算基準がなくならないか、について - 急がば回れ、選ぶなら近道
「なんで人月換算基準がなくならないか」については、これは作る側での議論が非常に多いのですが、逆側から見た議論があまりにも少ないので、自分の考えを記録しておきます。そもそも、発注した側ではシステムの価値をどう見るのか？という議論があまりにもなさ過ぎの印象があります。いくら作る側が頑張っても、発注サイドで「いやだから、結局いくらかかったか内訳見せろ」という話になった途端に、残念ながら人月単価が登場するわけで、話は振り出しに戻ります。 まず一義的にはユーザーから見たシステム開発は投資になります。確かに、毎年作っているでしょう、という話もありますが、普通は数年に一回作っては動かして、メンテナンスにモードに移行させる、という形になります。投資として、通常はキャッシュ・アウトに相当するコストで資産を認識します。リースにすれば、定常的でしょうという話もありますが、オン・ブックになった途端に普通に取得原価
業務プログラマーはこの先生きのこれるのか - novtan別館
SIerはなくなると言われて久しいです。僕もそれは間も無くやってくる現実だと思います。少なくとも、従来型のSIという仕事自体はなくならないけど、そのやり方は大きく変わると思っています。いくらクラウドだSaaSだなんだといっても業務要件を自動で書いてくれるわけではなく、何が正しいかの判断もしてくれません。今までにもまして、何を組み合わせてどう作るかを考える必要がでてくるし(従来であればスクラッチで作ります！ってのが出来たものもそんな金かけるなんてアホかと言われる世界です)、そうなるとエンジニアは広範な知識と経験を持って勝負しなければなりませんね。 しかし、いわゆる上流の工程が今にもまして重要になる反面では、下流の仕事が減っています。コアロジックさえ設計書に書いておけば、それ以外は自動生成されてテストしするだけだしテストも自動化されてるよ〜なんてことになるといわゆる大量な作業をもくもくとこなす
業務システムエンジニアは如何にして業務を身につけるべきか - novtan別館
データベーススペシャリストの午後の問題を見ていると、わりと業務システムなんて簡単にできる気がしてくるんだけど、実際に問題にぶち当たるのは、日本のシステムには厄介なオーダーメイド部分が沢山あって、一般論が通用しないことが多いせいかなあ。 よく問題になる在庫管理システムにしたって原理は簡単なんだけど、実際にはあの取引先には専用の帳票があってとか、この得意先は1営業日すべてのプロセスが早いとか、そういう仕様がたくさんあったりするんですよね。 それをもって「顧客の業務」と言ってしまえばその通りなんだけど、それって本当に必要なんだろうか。 こういう顧客に張り付いているエンジニアは、一般論を知らないことがよくあるんですよね。ここではこうやっている、というのは大事なんだけど、それが、普通はこうやるんだけど、ここではこういう理由があってこうしている、という理解にならないと、よそにいった時に何もわからなくな
業務系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にはかかわっているので、割と現状の問題も意識して
業務系SEの末路的なお話でして
Statistics Favorites 4 Downloads 0 Comments 0 Embed Views 0 Views on SlideShare 0 Total Views 0 業務系SEの末路的なお話でして — Presentation Transcript 業務系SEの今後について 消費税増税と年金問題が与える影響 2012// 株式会社ノーチラス・テクノロジーズ http://www.nautilus-technologies.com/ mailto:contact@nautilus-technologies.com Tel: 03-6712-0636 Fax: 03-6712-0664 Copyright © 2011-2012 Nautilus Technologies, Inc. All rights reserved.NAUTILUS Proprietary &
『SIエンジニアの自分戦略 -急がば回れ、選ぶなら近道-』ノート
2012/10/09に開催された『SIエンジニアの自分戦略 -急がば回れ、選ぶなら近道-』のノートです。 SIをやっている人には是非読んでほしいです。私のノート作成スキルを割り引いてもさておいても …です。 ※(2012/10/10追記)上の文について、言葉の選び方が不適切だったので修正致しました。「私の資料作成能力の限界で、okachimachiorz1様の伝えたいことの半分も伝わっていないかもしれない。だけど、それでも読む価値がある内容です」ということが、上の文で私が言いたかったことです。申し訳ないです。 ◆今日の勉強会について ◇今日の構成 ・最初にokachimachiorz1様の話を40分くらい ・その後休憩を挟んで来ている人達で感想、深く聞きたいということを皆で話合う ・Q&A ◇この回をやろうと思った経緯 ・okachimachiorz1様のブログを一生懸命呼んでいるうち、そ
『SIエンジニアの自分戦略 -急がば回れ、選ぶなら近道-』に参加してきた #devlove - Diary of absj31
SIエンジニアの自分戦略 -急がば回れ、選ぶなら近道- - DevLOVE 2012/10/09 SIエンジニアの自分戦略 -急がば回れ、選ぶなら近道 - DevLOVE #devlove - Togetter 講師及びその講師の方が話されるテーマも相俟って、募集後即定員が埋まる盛況振り。自分もタイミングを逸しキャンセル待ちで登録していたのですが、晴れてキャンセル待ち繰り上がりで参加資格を得る事が出来たのでこの日参加して来ました。 会場はマイクロソフト品川本社セミナールーム。今回はいつにもまして参加者も著名な方が多数参加。注目度の高さがここでも伺えます。 papandaさんの今回のイベント開催に至る経緯として以下の様なコメントが最初にあり、間髪入れずに本編へGOです。 ブログを読んでいて、書かれている事が仕事に対して危機感を持つ内容だった。 こういった内容を書かれる方のお話を聞いてみたい。
ITゼネコン
こういう話は何度も出てるかも知れないけど、書かせてほしい。 IT業界しか知らないまま社会人を続け、下請け→元請けと呼ばれるSIの大手メーカーに転職した。感じた事は「下請けと元請けで待遇が違いすぎる。」と言うこと。 下請けは結局派遣と変わらないんだなと思った。 基本人月いくらの人売り商売なので、いくら働こうが会社に入る金額は一定。社員の給料を上げると言う事は利益を減らす事になる。だから給料は殆ど上がらない。 必要最低限な給料しか払わない。最低限な生活が当たり前。贅沢というのは年に数回しかできない。 元請けは社員が生活に困らないよう、色々な福利厚生がある。あと残業したら手当が出るのは当たり前。出張や転勤者にも大きな金額の手当が出ている。 保養施設は豪華だし、ジムや旅行は割引が結構ある。 年収はなんだかんだ言って多少の年功序列はあり、３０過ぎで子供を持つ頃には６００万を超えるようになってる。 収
SIerにいること、SIerの業務について - shiget84's blog
shiget84 は入社3年半が経過した。いま三連休だが、まさか休日出勤なんか行ってないよね？ここで仕事せずに遊びにいったり、リフレッシュしたりしている人だけが残れる人材ですからね。 参考：http://togetter.com/li/385963 私は10月6日（土）に出勤してました。振替休日は申請済です。大きな障害などなければ休めるはずです（とか言ってると起きたりしそうで怖いですね） さて、その土曜日の帰りに同じ部署の1年先輩のかたとラーメンを食べながら話をしました。うちの部署は担当しているお客さまごとにグループがあり、私とその先輩は違うグループに属しているので一緒に仕事をしたことはないのですが、同じ部署で年齢も近いので、ときどき飲みにいったりしています。その先輩と短い時間ですが、食事をしながら仕事・仕事環境などについて話をしました。 いまの私は楽しく仕事をしています。チームメンバーと
デスマーチから生還する為に習慣付けるべき7つのポイント - ミッションたぶんPossible
先週末に2011年02月分の月報を提出したんですが、なんと勤務時間377.75h、徹夜回数8回と、オレ史上最も過酷な勤務状態だったことが判明しました。…ってまぁ集計する前から分かり切ったことではありましたが、こうやって数値化すると、あれは紛れもなくデスマーチだったんだなぁとしみじみ振り返っています。もう二度とやらねー。 さて、こんな状態で一番失いやすいのは心身の健康です。これだけ過酷な生活だとどうしても健康を害すことは防ぎきれないのですが、それでもある程度までは軽減できるだろうと確信を持って実行し続けたことがいくつかあります。その結果、オレはプロジェクト内でも1・2を争うハードな勤務形態を取りながら比較的他者より健康的にかつある程度健全な状態でデスマーチを戦い抜くこことが出来ました。 例えば、オレとその案件のチームリーダーは終盤ほぼ同じだけの稼働状況にあったのですが、最終的に健康度合いには
May_Romaさんの痛烈な批判からSI業界を学ぶ - novtan別館
僕もかれこれ十年以上、この業界にいて、それなりに問題点についてはお伝えすることもあったと思います。 たとえばこれ→SI業界を目指す君達へ贈る「何故システム開発はテンパるのか」 - novtan別館 ただ、それはSIerだけが悪いわけではなくて、ユーザーも含め、ITとは何かということについての意識がうまく転換できなかったことに根本的な問題があると思っています。ITは何をするためのものなのか。SIerが従来作ってきたシステムは、従来のやり方で問題なかったし、まだそういうITの世界は暫く残ることは残ります。ただ、全体のパイは縮小しているようにも見えますし、生き残りをかけた戦いはそろそろ中盤戦ではあります。 と、前置きをしつつ、本題に。 May_Romaさん連続Tweet：「インフラとかシステムとかの問題ではなく、そもそも仕事のやり方がおかしい。」 - Togetter ここにまとめられたものから
SIで得るものはあるのか？ - 急がば回れ、選ぶなら近道
「SIで得るものはあるのか？」 おそらくここ10年以上、日本各地で自問自答された問いでありまして。かくいう自分もその一人であります。デスマの度に、ここまでやる意味はあるのか？赤字の度に、そこまでやる意味はあったのか？ 思わなかった人はいないはずです。特にここ数年は、見るもの聞くもの、酷いプロジェクトが自分の周りでも多く、「いいから、そのまま回れ右」という行動パターンの機械学習全開です。（遠い目 他方、「構築をやらないと確実に実装力は落ちる」こういう声もあるでしょう。これもまた真実ではあります。特に、SIの中身丸投げモードのスイッチが入りっぱなしで液漏れ寸前なところは、もはや経験不足を通り越して「リバース・プロキシーって何をするんだっけ？」って真顔で聞くPMの方もいらっしゃる状態もありまして。実際にやらないとわからない、ということは普通におきます。特にアーキテクチャやインフラ周りは、そうなっ
技術革新は何のためにあるのか？ - 急がば回れ、選ぶなら近道
技術革新は須く斬新的なものであるべし、という肩に力の入った信念の人は流してください。ちょっと、力の抜いた小ネタなので。 最近というかここ10年来、いわゆる業務系のシステムに関わっていてよく思うことではあります。特に最近、NoSQLやHadoopといった「新技術」が登場するにつけて強く感ることではあるのですが、なんというか、「こんな感じ」のことができます、というようなプロダクトアウト的でありながら、かつ、漠然とした抽象的な話が多すぎる気がします。要は、全般的に問題の設定が苦手だよなということです。 特定の技術の各論はともかく、まず、大上段に構えると、実はITでは一般の人が想像する以上にユーザーとベンダーで期待ギャップがあります。ユーザーから見ると、大抵は「こんなこともできないのか？」ということがごく普通にできません。一方、一般のTVとか報道とかは、スパコンや遺伝子やビッグデータや、なんやらか
ウェブの「受託開発」が面白くないという8つの誤解 - Zerobase Journal
ぼく自身は多くのベンチャー企業とかよりよっぽど面白い仕事を「受託開発」でやってきているので（あ、もちろん「面白い」というのは主観的な問題だとお断りしておきますが）、ウェブ業界にはびこる「受託開発はダサい」という思想に強い反発を持ってきました。今日はそいつらをバッサリ斬ることにします。 ぼく自身は多くのダメなベンチャー企業とかよりよっぽど面白い仕事を「受託開発」でやってきているので（あ、もちろん「面白い」というのは主観的な問題だとお断りしておきますが）、ウェブ業界にはびこる「受託開発はダサい」という思想に強い反発を持ってきました。 今日はそいつらをバッサリ斬ることにします。 これまでに見聞きしてきた「受託開発が面白くない理由」を一つずつ取り上げて検証します。 × 受託開発なんて所詮「自分の事業」じゃないから自社事業がやりたい。 ○ 「受託開発」でも「自分の事業」としてコミットすることができる
受託開発脳から自社開発脳へ切り替えの7つの壁 - ヴェルク - IT起業の記録
これ、思ったより大変でした。 自分含め、うちにいるメンバー全員、 これまでの経歴では受託開発をメインにやっていたため、 自社サービス開発の経験はかなり少なかったです。 でも、ヴェルクでは、受託開発をしつつ、 時間を作って色々と作っていこう、というスタンスのため、 起業直後から色々と企画を考えていました。 でも、受託開発脳から自社開発脳への切り替えは思った以上に苦労しました。 要件定義等でお客さんと一緒に要件を考えたりしますが、 最終的に「やりたい事」を持っているのはお客さんになります。 要件定義の前の企画やグランドデザインと言った分野は お客さんの戦略に沿ったものになります。 だから、最終的には、誰かが答えを持っている事が殆どです。 そのため、ゼロからそれを考える事があまりないんですよね。 いざ、ゼロから自分たちで企画を考えようと思った時、 いろいろと壁がありました。 1. 本当の意味での
Re: エンタープライズシステムの開発言語選定の一考察（C#とJava） - 平々毎々（アーカイブ）
エンタープライズシステムの開発言語選定の一考察（C#とJava） - torutkのブログ 前提も明らかで、丁寧に比較されていると思いました。ついでに.NETの情報を補足してみます。 ケーススタディ1 C#で開発していた場合 アプリケーション開発／実行基盤は、3番目の候補を挙げてみます。 開発環境: Visual Studio 2010/C# 2.0/.NET Framework 3.5SP1(2.0) 実行環境: .NET Framework 3.5SP1(2.0) .NET Framework 3.5SP1のCLR(Javaで言うところのJavaVM相当)は.NET Framework 2.0と基本的に同じもの。その上、.NET Framework 3.5SP1からはOSのサポートライフライクルに準じるようになったので(ソース:http://msdn.microsoft.com/ja-
エンタープライズシステムの開発言語選定の一考察（C#とJava） - torutkのブログ
アーキテクチャ設計の一部に、プログラミング言語の選択があります。選択に関わるのは仕事では10年振り（うん？ ちゃんと数えると13年か・・・）です。3月から下調べを開始して、可能な限り公平に。 もちろん人間の判断なので、主観が大きく関与せざるを得ません。特にプログラミング言語は、パラダイムの選択になるので。 前提の明確化 技術選定にあたっては、前提を明確にしておかないと、果てしない議論に陥ってしまいます。 ここでは、開発対象をエンタープライズ・システムとします。エンタープライズ・システムは、開発期間よりも運用（保守）期間が数倍（たとえば、開発１年に対して運用10年といったことも珍しくない）になります。また、システム化範囲も昔に比べて増えてきており、その分作成されるアプリケーション規模（機能量）も大きくなります。 また、運用（保守）期間では、随時機能の変更・追加が行われる想定とします。 システ
エンジニア人月０円セールと、ござ先輩に見た未来 - レベルエンター山本大のブログ
今日はid:gothedistanceと飲んだ。１年ぐらい前から飲もう飲もうといっていてようやく実現。 さすがはござ先輩。いろいろと教えてもらった。 その中で、SIおよびSEのこれからに暗い影を落とす話をした。 これはウチの関西側の営業担当が聞いてきた、あるSE派遣の企業の話。（とはいえ関西企業に限った話ではない） 何十人もの新人さんを集めて、無料でいろんなプロジェクトに派遣するビジネスモデルが台頭してきているらしい。 何十人の内、数名でも生き残って、その後定期的な売り上げになれば良いという、携帯の新規契約無料みたいなモデルだ。 経験者も言い値で出すという。 新人さんに経験を付けてもらうためにお試しで出向することは百歩譲って良いとしよう。 いくらなんでも新人ばかりで上手くいくと思っているような 受け入れ側もプロジェクトもさすがにないから、 こういう新人さんを受け入れるのも1つのプロジェクト
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
2012/10/09 SIエンジニアの自分戦略 -急がば回れ、選ぶなら近道 - DevLOVE #devlove
