Excelスクショ問題について周りの方へのお願いと、今職人となっている方への励ましの言葉（元職人より）
Excelスクショ問題について周りの方へのお願いと、今職人となっている方への励ましの言葉（元職人より） 2014年8月3日日曜日 ITニュース うつ病 最近一部で話題になっている「SEがテスト工程で画面のスクリーンショットをExcelに延々と貼り続ける作業」について、実際にスクショ貼り職人を経験した自分としては、何か残しておかねばと思い、この記事を書きます。 自分はSEでしたが、うつ病でもうすぐ2度目の休職に入ります。Excelスクショ職人を経験しています。そんな自分が、「Excelスクショに対して疑問を抱いている方」と「今現在Excelスクショ職人な方」へ、お願いと励ましの言葉を述べさせていただきたいと思います。 【参考】 SIerの闇・Excelにエビデンス貼付け - Togetterまとめ あるシステムを開発したら、必ずテスト工程があります。プロジェクトによっては、全くユーザーインタ
銀行系SIerからみた今回の経済問題 - novtan別館
３つの理由とかは入れないようにしようｗ 第一期 サブプライム問題発覚直後 そもそも発覚前の銀行の利益って爆益といってもいいほどあったはずなんだよね。みずほFGで6000億くらい？それが半分以上吹っ飛んだというのも当初はわからなかったんだけど。 キャッシュの大幅な減少は、投資の抑制に繋がる。本当は三菱東京UFJ銀行が統合作業を終わるところで他のメガバンクに人が移動したり、東京三菱UFJが統合の余波を駆って次のシステム投資を行うところのはずだったんだけど。MUFGは統合が終わるまで慎重に、という言い訳で投資を抑制。他のメガバンクも目玉のシステム投資をしなきゃならんので既存のメンテ方面に大きなしわ寄せ。 第二期 巨額損失発覚直後 サブプライムの問題が意外と大きかったことが判明した直後。 もうメンテの案件も削られまくり、単価下降の要請も出る始末。そんななか、いよいよMUFGの統合対応要員が余り始め
今度の不況でSI業界が悲惨な状況に陥りそうな３つの理由 - masayangの日記（ピスト通勤他
釣り 題名に「３つの理由」みたいに数字を入れるとアクセス数が上がると聞いた。 本当かな？ 本題 自分がこの業界で景気後退を経験するのはこれで3度目。 一回目は1990年前半のバブル崩壊後。 二回目は2000年のネットバブル崩壊後。 今回のは1990年前半のそれを、規模・深刻さ共に凌駕すると予想している。 理由(1): 空洞化 「上流＝付加価値の高い仕事」という概念は根強く、開発という「核となる」行程を安い外部に流すようになってしまった。 レバレッジ効果があるから収益向上につながってきた。 が、新たな仕事が来なくなるとレバレッジは逆転を始める。 つまり、外部依存率を下げつつ、利益率向上を目指すという苦痛が待っている。 →開発を忘れた人達には無理。 理由(2): 分業化 1990年代初頭の情報処理試験は「二種」「一種」「特種」しかなかった。 今はなんだよ... 情報処理試験の中の人達に雇用機会
レバレッジ経営・レバレッジ開発 - masayang's diary
ということで、リーマンブラザーズが飛んでしまった。 例によって「デリバティブ取引が悪い」などという論調もあるが、デリバティブだけが悪いのではない。 借入れた資金でレバレッジをかけて張っていたのが問題なのだ。 以下、かなり長文 レバレッジ 自己資金1万円で年利5%の運用をしても、利回りは5%。当たり前。 でも、5万円を年利2%*1で借りて、自己資金と合わせて5%で運用すると... 得られる利益は60,000*0.05=3000円 借入金に対する利息は50,000*0.02=1000円 差し引き2000円の運用益 自己資金10000円に対する利回りは20%! 低金利で借り入れて投資に回すことで、高い運用益を実現できる。これがレバレッジのもたらす恩恵。では、短期で借り入れる金利が上昇したらどうなるだろう？ 例えば上記例での短期借入れ金利が4%に上昇したとしよう。 5万円を年利4%で借りて、自己資
人生いろいろ、技術者もいろいろ、搾取されないに越したことはないよね - 雑種路線でいこう
受託調査＆研究補助→ユーザー企業コンサル→通信事業者コンサル→Web企画構築→金融SE→研究・コンサル→パッケージベンダ・マーケ→パッケージベンダ・技術渉外のおいらが来ましたよ。 こんなことをいっては「上流」にいる方々には失礼かもしれませんが、IT業界は上流にいるほど得になるような構造になっています。それぞれのプロジェクトについて自分のところで十分な経費を確保してから下流に流しますので、下流にいるほど仕事がきつくなります。それをうすうす感づいているから、若い人は少しでも上流に行きたがります。PGをしばらく勤めたらSEに、SEを少しやったらコンサルに。産卵まぢかの鮭でもあるまいに、自分の技術レベルも分からないまま、やみくもに次のステップを目指そうとする。 実はプログラムを書かなきゃいけない仕事ってやったことないんだけど、Web企画構築の時はベンチャーで大手ISPに提携を申し入れ「お前らに顧客
SEとPG、どっちが頭がいい？（2）：下流から見たIT業界：エンジニアライフ
刺戟的な題名で続けます。 前回は日本独特のSE／PGの分業体制がどのようにして発生したのか、ということを説明しました。それは日本にソフトウェア開発が産業として根付いたときに、PGが単純作業労働者と位置付けられてしまったため、上級技術者を区別する言葉が必要とされた、それがSE（システムエンジニア）だというものでした。 ●C言語＠UNIXでは COBOLの開発ではSE作業とPG作業がきちんと分けられていると思われがちですが、これも前回述べたとおり実際には形式だけのものになっていました。これはタイムシェアリング端末の普及によってプログラミング作業が格段に効率化されたからでした。プログラミングに残っていた煩雑な手作業の部分が省力化されたのです。 この事情はBasicやC言語でも同じことです。1980年代後半、わたしは最初の会社を辞め、パソコンの開発をするようになりました。現場では、技術者はそれぞれ
IBMの問題はアメリカナイズされた老害 - ひがやすを blog
日本IBM周辺でトラブルが続出している。IBMの下請けとしてサブシステムの開発に携わっていたソフトウェア企業が4億円近い負債を抱え、2008年10月中にも破産手続きに入る。同社は、IBMから追加費用の支払いが行われていなかったと主張して訴訟準備に入っていたという。ほかにも、スルガ銀行やソフト開発会社など、IBMを相手取った訴訟も続発しているのだ。 この訴訟続発を問題のように受け止めている人も多いようだけど、IBM自身にとっては、そんなに問題じゃないと思う。ユーザーの発注が確定しなくてもその先の作業を進めるために下請けに先行発注したりすることがなくなったり、不採算案件は最初からやらない、あるいは早期に手を引くことが、徹底されたからだと思うから。 これまで、日本的な空気を読むビジネスから、アメリカ的な白黒はっきりな契約ベースになったということなので、一方的に悪いことではない。 でも、契約を交わ
株式会社マジカジャパンの羽生章洋が書いてるブログ:閉塞感を越えて - livedoor Blog（ブログ）
日本のIT業界には閉塞感が漂っているように見えます。行き詰まりを感じているように思えるのです。ただ、最近になって業界界隈から距離を取るようになって、どうしてそうなってしまっているのかということが、おぼろげながら見えてきました。 ギョイゾー！というサービスをリリースしてから、非常に多くの方々とお会いするようになりました。大抵は情報システム部門さんがない企業さんだったりするので、これまで私どもがお付き合いしてきたような、いわゆる業界を理解してくださっている方々とは違います。そういう方々とのお話をするにつれて、業界全体の問題が浮かび上がってきたように感じるのです。 一言で言えば、説明不足ということになるのでしょう。きちんとしたソフトウェアを作りさえすればよいという空気が間違いなく存在しています。そもそもその基本となる部分で昨今では空洞化などといわれたりするのですが、それを脇に置くとしても自分たち
SI業界の老害が若手と下請けを蝕む理由 - ひがやすを技術ブログ
10年間泥のように働いて花が咲きましたのぶくまのコメントにこういうのがありました。 経営層がプログラムの品質を度が越えたほどに軽視する理由の 一つが説明されてます。目から鱗です。意外とみんな知らないようなので、「SI業界の経営層の考えが古い理由」をきちんと説明したいと思います。 汎用機あるいはオフコンの時代は、COBOLやRPGなど(他にもありますが私が経験したものをあげています)の言語が使われていました。 昔の言語は、誰が書いても同じようなコードになると思われていました。もっというと、コピペしてちょっと書き換えるという開発スタイルが多かったのです。もちろん現場によって開発スタイルは違うと思いますが、コピペが横行してたんじゃないかなぁ。 コピペでの開発なら、そりゃ誰が書いても同じようなコードになるよね。 再利用性、保守性より「最初にとりあえず動かすこと」が重要視された。コピペでちょろっと変
プログラマが仕様を決めればいい - GoTheDistance
最近よく思います。 システム開発の上流工程においてはコードは出てこない。言葉や図解で埋めつくされて、最終的には日本語でしかない。設計書とか仕様書とか。で、この大抵上流工程ではこれらのドキュメントに対するレビューなるものがあるのですが、これが実に無益なものだと感じることが多い。こんな所でPDCAまわして何が面白いんだろうとよく思う。 ここでチェックする多くのことは、言葉の解釈に関することがほとんどです。 この言葉はプロジェクトで使われていない 書き方が統一されていない 誤字脱字が多いので直せ。 この文章ではこのように解釈される恐れがある ここではこのような話になっていたがどうなのか こんなんばっか。どこもそうだと思う。解釈の違いは、要件の違い。なんちゃって。 で、結局こういうことを繰り返していくうちに段々とドキュメントがグダグダになっていく。そして繰り返していっても前提が変わってしまえば全部
Service Integratorになれる日が来るのだろうか - GoTheDistance
ZEROBASEさんのBlogに書かれていることが、自分の問題意識とシンクロした。この辺で少し整理しておきたい。 要件定義前提のビジネスモデル Webサービスに「システム開発」の側面があるからといって、業務システムのように「ユーザに聞く」とか「要件定義」とか「要求開発」しようとする発想では、うまくいかない。そこで「プロダクトアウト」か「マーケットイン」か、といった二分論での議論も危険。どっちの面も必要に決まってる。 そういう仕事って何？「マーケティング」や「商品企画」ですよね？ で、それってSIerには未知の領域なんだと思います。 SIerはWebサービスを開発できるのか？ SIerがディフェンシブにならざるを得ないのは「要件定義」というプロセスそのものにあるのではないか、と最近思いはじめました。要件定義が基点となって「我々は今回こういうものを作るのです」という取り決めを行いその器の大きさ
スーツにはスーツの道がある - GoTheDistance
勢いで書く。 スーツ側の人は業務内容が密接にプロジェクトや会社の中の話と結びつくことが多いので、はてな界隈ではなかなかスーツ側の人はスーツ側の濃ゆい話を書くことが出来ないことが多いようだ。圧倒的にスーツ側の人間がはてなを始めとしたブロゴスフィア全体で少ないなぁとつくづく思う。QAも少ないけど。この辺をアツく語るブロガー出てこないかなー。 私は200X年に今の会社に入社して、数年間WEBアプリケーションの開発をやった。多くはJavaの案件だった。最後の案件は去年の夏ごろだ。前任のPMが逃げるように辞めていってしまい、非常に複雑なロジックを自分が担当することになった。1500行越えktkr。それを参考にして(これが大間違いだったんだよセニョールorz)２週間かけて作ってみたはいいものの、テストを繰り返しているうちにどんどんボロがでて、結局その当時のPMとパートナーさんに相談して設計からやり直し
JavaとRubyの間にある、ベルリンの壁 - GoTheDistance
ネタ元はこのあたり。 SIer と Rails とエンタープライズと エンタープライズにおけるRailsの価値とは 弊社の某エロい人がRoRに萌えており「おお、なんて生産性が高いんだ。もうWebアプリなんて全部これでいいじゃないか。」とか本気で思ってそうなので萎える。言語の違いは時にはビジネスモデルの違いにつながることが理解できないようだ。言語ってのは文化なの！これからはRubyを全面的に取り入れ開発標準もRubyだぁぁぁぁとか言い出したらどうしよう。グーで殴るしかないかｗ 本来、コード量の少なさや、CoCを前提とした設定の少なさが価値を発揮するのは、メンテナンスの場面です。読み込まないといけないコード量の少なさと、少ないコードの変更で修正ができることが、その理由です。そのためには、大前提として、Ruby（on Rails）らしい、プログラムを作っておくことが必須なので、マネージャはその辺
ニッポンのSEよ、蜂起せよ - 雑種路線でいこう
なんかはてブってば情報サービス産業の悲惨さを訴えると急速にブクマが伸びるものらしく、お前らダラダラ職場からブクマチェックしないで、とっとと帰れよと思うこともあるが、きっと帰れない深い事情もあるのだろう。 しかし分かってないなあ。10兆円台に乗せた情報サービス産業にあって、経済産業省のIT関連予算ってイマドキ400億円もなくて、これって腐りきった社保庁システムの年間保守費用より小さいんだぜ。それが日本のIT業界発展を阻害しているなんて過大評価じゃね。 日本のSI業界の過酷な労働条件を改善したければ、やるべきことは労基法の改正とかじゃなくて、市場メカニズムを正しく機能させることだ。日本のIT業界を発展させたければ、援助交際をやめて何もしないことだ。 最近こそ郵政4分割とか、自民党の参院選対策で大見栄を切った年金の名寄せとか、政治に皺寄せされた不条理なデスマ案件が散見されるけれども、官公需って昔
IT業界のネガティブイメージ - カレーなる辛口Javaな加齢日記
http://www.atmarkit.co.jp/news/200710/31/ipa.html 業界の重鎮もたじたじ 業界の重鎮＝老害？ 「トヨタ自動車やソニーのようなユーザー企業と違い、IT（の導入）しか行っていないNTTデータのような会社が一番謎」といった疑問が出た。イメージを聞かれても、そのイメージ自体が何もないという皮肉な答えだ。 必ずしも全員が3Kではない」と反論。岡本氏も「3Kの“帰れない”は、帰りたくない人が帰れないだけ。スケジュール管理の問題だ。 ふーん．帰りたくない人が９０％以上を占めるとは知らなかったな． できるヤツから潰される：http://www.mars.dti.ne.jp/~hirok/xp/col/031.html なぜ日本はこれほど残業が多いのだろう。理由は二つある。 もともと、年功序列・終身雇用というものは、ある程度の残業を前提にしたシステムだ。賃下げ
IPAフォーラム2007で討論してきた - 東大MOT学生の奮闘記
10月30日に行われたIPAフォーラム2007の『「学生から見たＩＴ産業」と「ＩＴ産業から見た学生」〜ＩＴ産業は学生からの人気を回復できるか〜』と題された討論会でしゃべってきた。IPAとは情報処理推進機構の略で、情報処理技術者試験とか、未踏ソフトウェア創造事業をやっているところ。 大学の先生から、討論会に出る学生を求めいているという話を聞いたのが討論会に参加したきっかけ。僕はてっきり、IT産業の未来について語り合うのかと思っていたのだが、「IT産業は3Kのイメージが強く、就職において人気がなくなってきているが、どうすればその人気を回復できるか」というタイトルを聞いて、ちょっとがっかりした。 ＠ITにこの討論会についての「IT業界不人気の理由は？ 現役学生が語るそのネガティブイメージ − ＠IT」という記事が上がっていた。ちなみに、記事の最初の写真に討論会に参加した学生が写っているが、前列の
要件定義カード1枚8万円──脱・人月商売宣言 － ＠IT
「1タスク8万円」という価格体系を提示し、人月商売からの脱却を宣言するスターロジック代表取締役兼CEO 羽生章洋氏 「二度と人月商売はしません」──スターロジックは7月19日、都内で開催した自社イベント「StarLogic Conference2007」において、エンドユーザー自身による要件定義に基づき、「要件定義のカード1枚当たり8万円（税別）」という価格体系でシステム構築ビジネスを進めていくと発表した。従来の「人月」に基づく見積もりと比べて、1/3から1/5の価格になるという。 「人月換算でコストを請求する商習慣こそが、SI業界のさまざまな問題の根源。人月から脱却するには、納得でき、分かりやすい価格体系を提示することだ」（スターロジック代表取締役兼CEO 羽生章洋氏）。 低コストにできる理由は、ユーザー自ら要件定義を行い仕様を最初に明確にする点と、実装段階で自動生成により生産性を追求し
日本のソフトウエア産業、衰退の真因
ソフトウエア・エンジニアリングのリーダーの一人、エド・ヨードンは1992年に、『Decline and Fall of the American Programmer 』を著し、米国のソフトウエア産業の衰退と挫折を警告した。この本を出す少し前まで、彼は「この国が危ない（A Nation at Risk）」というタイトルで講演行脚をしており、同書はそれをまとめたものである。 この本の中で、ヨードンは日本をソフトウエア開発における優等生の一人として挙げ、インドの飛躍を予見している。本が書かれた時点では、インドのＩＴ産業はまだ黎明（れいめい）期にあったが、彼の予想通り、現在は英語圏で質の高いソフトウエア開発力が得られる国として、欧米から頼られる存在になり、ＩＴ立国を目指す他のアジア諸国からお手本と見なされるまでになった。 「この国が危ない」というヨードンの警告に触発されたのか、米国上院の「米国の
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
