よいSEにはよい報酬を，“人月いくら”はもうやめよう
少し前のIT Proニュースで，日本IBM・大歳卓麻社長の「ユーザー企業には，技術者の出席をとらないでいただきたい」，という発言が紹介されている（当該記事）。「技術者の頭数ではなく，成果物について対価を払っていただける商慣習に変えていくよう，広く呼びかけたい」，という主旨だ。 私自身も取材のなかで，技術者の数や開発にかかった時間でシステムの価格を決めるのはおかしい，という声を，多くのSEの方々からお聞きする。ベンダーに籍をおくSEからだけではなく，ユーザー企業の方からもである。 システム開発にかかる工数，すなわち“人月”は，価格見積もりの根拠として，現在でも広く使われている。仮に一月100万円のSEが10カ月働いたから1000万円，という見積もりがあったとしよう。では，そのSEが努力して生産性を向上させ，5カ月でシステムを開発できるようになったら，価格は500万円になってしまうのだろうか。
登山口に辿り着けるかと山を登れるかは別問題 - 雑種路線でいこう
ぼくは小学校の徒競走に始まって，受験戦争であれ，就職活動であれ，僕は横並びの競争が苦手だ．ただ早い段階で，自分の欲望には様々な満たし方があり，世の中にはいろいろな世界があるのだ，ということを早く知れたことは良かったと思っている． 思い返すと恥ずかしいことだが，小学校の卒業文集には弁護士になりたいと書いた．口達者が役に立つ仕事を他に知らなかったのである．中学・高校の頃は新聞社に入りたかった．イデオロギー不在の90年代，新聞社の中ではコトバにいちばん軸と張りがある気がした．新聞記者になりたいという僕に学校の先生は新聞研のある東大か，マスコミに強い早稲田に行くといいという進路指導をしたが，あそこで先生のいう通り奮起していたら，新聞社に入れていただろうか．それが自分にとって幸せだっただろうか． 前のエントリで僕はトレーダーになりたいと無邪気にいった同じゼミの学生のことを批判的に書いたけれども，それ
「SOAはベンダーがツールを売り込むためのバズワードに過ぎない」，Martin Fowler氏語る
「私はSOA（サービス指向アーキテクチャ）に対してはシニカルに考えている」。「Refactoring」や「Patterns of Enterprise Application Architecture」といった書籍の著者として有名な米ThoughtWorks チーフサイエンティストのMartin Fowler氏は2006年5月30日，東京都内で講演し，SOAの現状に疑問を投げかけた。SOAは意味のあいまいないわば“バズワード”であり，ベンダーがツールを売り込むための宣伝文句になっているというのだ。ただし，SOAの中には優れたコンセプトもあり，そうしたコンセプトはSOAという言葉とは切り離して考えるべきだという。 「最初は意味があってもすぐに意味がなくなってしまういつものパターンの言葉」というのが，Fowler氏のSOAに対する第一印象だったという。「（同じSOAといっても）人によって言うこ
オープンソースと「オープンデザイン」が出会うとき - 設計者の発言
◆オープンソースの台頭 無償で手に入る業務システム向けの開発・実行環境やフレームワークが急速に充実してきた。Apatche,Eclipse,Seasar2,MySQL,Ruby on Rails等々、枚挙にいとまがない。それらの多くが活発なＯＳＳ(open source software)コミュニティを伴っていて、優れたソフトウエアを開発して社会に貢献したいと願う技術者達の情熱の受け皿となっている。その創造的な流れが止むことはないだろう。 そのような変化を、ソフトウエア業界を牛耳ってきた大規模ＳＩｅｒも無視できなくなっている。初めの頃には品質がアテにならないとかドキュメントが貧弱などと言って相手にしていなかったのだが、いつの間にか実務で使えるレベルまで成熟していることに気づきはじめている。クレイトン・クリステンセンが「イノベーションのジレンマ」で示したさまざまな業界での事例と似たことが、ソ
kokoromoの日記 - つまらない仕事を楽しくする方法
取っ掛かりをスムーズに やり始めればスムーズに仕事をこなすけれど、やろうとしても乗り気じゃない。とりあえず仕事しなくちゃいけないから、簡単にできる仕事からなんとなく始めてしまう。そして、気が重い仕事はどんどん先に伸びていく・・・。 こうならないために、仕事を行うための儀式を決めよう。たとえば、『この椅子に座ったらあの仕事を行う』『このFirefoxは息抜き専用で、IEはあの仕事専用』。こんな風に儀式として行うと、行動の決断が簡単になり、いつの間にかあの仕事をやっていた、となることが理想。（気が重い）あの仕事を処理しようと決断して始めるモチベーションはコストがかかるけれど、始めるための儀式を行うモチベーションはほとんどコストがかからない。 つまらない作業にモチベーションをあげる まず、仕事が完了するまでに行うすべての行動をリスト化する。このリスト化の作業は、作業全体の１割程度費やしても問題な
「姿勢性症候群」が増加中--「同じ姿勢」に医療関係者が警鐘 - CNET Japan
今現在、正しい姿勢を取っているだろうか。 もしも、背中を丸めて首だけ起こす、「コンピュータにもたれかかる」ような格好でこの記事を読んでいるならば、将来的に、理学療法士が「姿勢性症候群」と呼ぶ疾患にかかるおそれがあることを覚えておいてほしい。 姿勢性症候群は、屈曲した前傾姿勢を取り続けた結果、首と胸椎（中背部から腰部におよぶ12個の脊椎）に継続的な力が加わって起こる疾患だ。医師や理学療法士によると、この疾患は一般的に第四、第五、第六胸椎の間にある椎間板に対して起こり、筋肉の圧痛や硬直、場合によっては神経過敏などを伴うという。 何年にもわたって前屈みの姿勢を取っていると、椎間板の間隔が狭くなり、肩胛骨の下部や腕、背中へと神経過敏症が広がってしまう。 デスクワーカー自身や人間工学専門家のほとんどがよく知っているとおり、1日中PCに向かってマウスやキーボードを繰り返し操作していると、手首の弱化やテ
はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
プロジェクトチームのリーダーに向く人、向かない人 ― ＠IT情報マネジメント
チームで遂行されるプロジェクトにおいて、優秀なリーダーの存在は極めて重要です。そこで今回から、リーダーについて考えてみることにします。リーダーシップの具体的な技術に関してはコーチングなどの記事を参考にしていただくことにして、ここではもっとベーシックなところをターゲットにします。なお対象としては、ユーザーサイドに限らずプロジェクト一般についての話となります。 誰でも持っているリーダーの素質 よく話題になることに、リーダーにはリーダーとしての素質がなければならないのか、ということがあります。ある程度の素質は必要でしょうが、それは大多数の人が持っているはずです。そのように考えられる根拠はあります。 例えば、ふさわしい人が地位に就くのではなく、「地位が人を育てる」ケースはよく知られています（年功序列主義の会社ではよく見られることです）。これは、リーダーとして特別な素質がないと思われたり、思い込んだ
neutral23の日記 - やる気マネージメントは他人がするものじゃない、自分でするもの
数年前まで自分のことを仮面サラリーマンだと思っていた。 働くこと自体イヤイヤで、正論が通らないことにもイライラしていた。 そんなアホな世界で暮らしたくはないと、いつも思っていた。 とはいえ、仕事を楽しめなかったわけでもないし、自分にスキルがついていくもの実感ができていて、両者の狭間で、もどかしさを感じていた。 ある日、新幹線で新大阪から東京まで移動時間がぽっかり空いてしまった。 書店でデマルコの本を見つけた。 ピープルウェア(http://www.amazon.co.jp/exec/obidos/ASIN/4822281108/)だった。 内容をごく簡単に荒っぽくいうと、 効率よく仕事をしてもらうのには、即物的なエサでつっても何のインセンティブにもならないよ。 やる気を見出せるようなことをしないと、いけない というものだった。実際にはもっと詳しく書いてあるので、もし読んでいないのなら買って
デュアルモニタにすると生産性が30％アップする
ニューヨークタイムズの記事によると、デュアルモニタ環境、要するに画面を2つ連結する環境にすると表示面積が2倍になり、結果として生産性が2割から3割ほど上昇するらしい。 The Virtues of a Second Screen - New York Times 例えば原稿を書く際に資料を一方に表示させながら、もう一方で草稿を書くとか、そういう感じで「何かを見ながら、参考にしながら」という作業を要する場合に威力を発揮するらしい。 また、画像加工の際にもオリジナルの画像と加工後の画像を比較したり、ネットでお買い物する際にも価格比較とかしやすいらしい…。これにタブブラウザとか組み合わせれば最強なんでしょうか。 単純な話、机の面積が2倍になれば作業しやすいよねーというのと同じ原理に基づいているらしい。
アジャイルだとリファクタリングが必要な理由＆アジャイルする意味をなくす営業・ＰＭの態度 - ウィリアムのいたずらの、まちあるき、たべあるき
ウィリアムのいたずらが、街歩き、食べ物、音楽等の個人的見解を主に書くブログです（たま～にコンピューター関係も） アジャイルが使われる多くの理由は、「仕様が固められない」という部分が多いと思う。 あ、あとは、できるのを見ないと怖いとか。。 っていうことで、アジャイルではじめる場合、初めから「共通部分を抜き出して」ということをやれないケースもあるし、やると危険なケースがおおい。 話が進んでいったら、「ぜんぜん共通じゃないじゃーん！！」っていうことになり、その部分を作り直しとなったりするから。 オブジェクト指向な人は、「そーいう部分のために、派生があるんです」というとおもうけど、派生する意味ないくらい、共通じゃない（見た目は共通だけど、中身は共通じゃない）というケースがあるので、やっぱ、オブジェクト指向を採用しても、共通化すると、作り直しになってしまったりする。 てなわけで、いったん全体を作って
ユーザー企業がITサービス会社の値上げ要請を受け入れない理由
最近、ある大手ユーザー企業のシステム企画担当者に「SI料金は下方硬直性が高い。だから、ITサービス会社の値上げ要請をおいそれと受け入れるわけにはいかない」と言われて、とても驚いたことがある。サプライサイド、ITサービス会社から見れば「それを言うなら上方硬直性でしょ。一度料金を下げたら、なかなか上げてもらえないじゃないか」と文句の一つも言いたくなるような話だ。 しかし、その理由を聞いて少し納得した。要は、原価構造が分かりにくいことを、このユーザーは問題にしていたのだ。SE単価や人月料金にしても根拠薄弱であるのは、ユーザー企業だけなく、ITサービス会社自らが認めるところだ。それに、スクラッチ開発での“コピペ”、つまりコードの再利用も明示的に示されたことはない。ここ数年間、苦労してSI料金を下げさせてきた。ITサービス会社がまだノリシロを隠しているんじゃないかと疑うことこそあれ、料金値上げなどと
FPN-ゼイヴェル・大浜史太郎社長へのインタビューを読んだ
2．ビジネスリサーチの情報収集 デスクトップ調査 の基本〜アニュアルレポートなど公開情報から… デスクトップ調査 とは、主にインターネットなどを使用して、公開情報を調査して整理・分析を行うものです。「CIAも収集する情報の95％が公開情報」ということで、情報不足とい… 2021.01.28 2021.05.13 1915 view コラム〜リサーチャーの日常 人生を通じてマッチクオリティーを追求する 知識の幅が最強の武器になる という本で初めて知った「 マッチクオリティー 」という言葉は、経済学の用語で、ある仕事をする人とその仕事がどれくらい合っているか、その人の能力… 2021.05.04 2021.05.13 295 view 2．ビジネスリサーチの情報収集 日常的な情報収集・整理術（Feedly＋Dropbox） 【 ビジネス 情報収集 と 情報整理 の基本 】いま目の前にあるリサー
知的労働者には「組織を移る力」がある
前回のエントリーに、Doraさんという方から「次回エントリー『こうすれば日本のSEは救われる！』を楽しみにしております！？」とのコメントをいただき、少し悩んでしまった。日本のSIer（少し前までは「SI屋」だと思っていた）の階層構造の問題を指摘しておきながら、何も提案しないのはあまりにも無責任かも知れない。 だからと言って、「日本のIT産業はこうあるべきだ」などと部外者である私が本当の意味で影響力のある発言をするのはあまりにも難しい。特に、IT業界に限らず、一旦こういった階層構造が出来てしまうと、業界で力を持つ上位レイヤーの会社や人たちにとって、改革は自己否定にもつながりかねないので良いと分かってはいても自分からわざわざ着手できない、というジレンマがあるのが一層解決を困難にしている。 では、現時点でIT業界で苦しむSEやプログラマーの人たちは何をしたら良いのだろうか。 とても難しい問題では
Life is beautiful: ソフトウェアの仕様書は料理のレシピに似ている
先日、経済産業省向けの仕事をしている知り合いと食事をしたのだが、彼によると経済産業省の今の悩みは、「IT産業の階層化の弊害によっておこる下流のプログラマーの収入の低下」だそうである。「プライムベンダー」と呼ばれる「上流コンサルタント」たちがインドや中国にも仕事を発注できることを理由に、激しく値切り始めたために、今やわずか一人月３０万円というケースもあるという。 こんな話を聞くと本当に悲しくなる。まず第一に「プログラムを書く」という仕事は簡単な仕事ではない。数学的な頭を持っていないとかなり辛いし、基礎がしっかりと出来ていないとろくなソフトウェアは作れない。物価の安いインドや中国なら許せるが、米国よりも生活費の高い日本で一人月３０万円とはあまりにも低すぎる。 「彼らは下流のエンジニアで、詳細仕様書に従った通りのプログラムを書くだけの簡単な仕事をしているから給料が安い」という説明を聞いたことがあ
IT Pro Java/J2EE : 【連載◎開発現場から時代を眺める by arton】第5回
【連載◎開発現場から時代を眺める by arton】第5回 「動的言語と静的言語の交差点──RubyとJava/Seasar2の出会い」 オブジェクト指向言語を利用した開発が当たり前になり，早くもポスト・オブジェクト指向言語は何かという話題も出ているようだが，先日，具体的に今後の技術の一つの方向性を示す話を聞くことができたのでご紹介したいと思う。それは動的なオブジェクト指向言語のRubyと，静的なオブジェクト指向言語のJava，それぞれのフレームワークについての話だったのだが，意外なほど目指している方向性が近いようだ，と確認したということである。 結論を先に書くと，ソフトウエアの動的に決定したい部分を設定ファイルのようにソース・ファイルの外部に置かれる構成要素で解決するのではなく，言語とフレームワークの機能を利用してソース・ファイルの（文字通り）行間を補完することで解決するという方向だ。
仕事の心がけ
目次 はじめに こころとからだ 休息は大切 睡眠 夜型と朝型 眠るための儀式 食事を味わう 心の健康 無駄を無駄にしない工夫 誠実に 記録と計画 仕事の見積り 文章を書く、プログラムを書く 文章の書き方 日々の生活 習慣の力を借りる メモの取り方 整理・整頓 道具 書物 文房具 自分との調和、他人との協調 複数の仕事のコントロール 他の人と仕事する 残りの話題 読者のみなさんからのフィードバック ぜひ、感想をお送りください 更新履歴 リンク集 はじめに このページでは、 結城が仕事をする上で心がけていること、 心がけようとしていることをご紹介しています。 こころとからだ 休息は大切 仕事について書くのに、 「休息」から書きはじめるのは変でしょうか。 けれども私はそうは思いません。 私は、よい休息がとれているときにはじめて 充実した知的生活を営むことができるからです。 逆に、休息がきちんとと
kuranukiの日記 - ディフェンシブな開発 〜 SIビジネスの致命的欠陥
Rubyをはじめとするスクリプト言語ではなく、なぜJavaを選ぶのか。 そして、XPをはじめとするアジャイル開発ではなく、なぜウォーターフォールを選ぶのか。 そこには、言語の良し悪しや、開発プロセスの考え方などが理由の中心にあるわけではなくて、SIerというビジネスの仕事の仕方（ビジネスモデル）に起因している。 RubyやXPは、考え方や技術としてはとても良くて、生産性もあがるし、何よりもソフトウェアをクリエイティブに作り上げることができ、利用者にとっても使い勝手がよく、スポンサー（経営者）にとっても経営戦略に沿ったものが手に入り、開発者にとっては何よりも仕事に対してやりがいを感じることができる。すばらしい！・・・・が。。。 しかし、だからといって、誰でもRubyやXPを使って開発をするべきか、というとそうではない。もし、本質を理解しない誰かが、「やってみたいのだが・・・」と相談に来たら、
東葛人的視点 日経BP社
« またも東証のトラブル、改めて考 | メイン | プロジェクト・マネジメント「格 » 作る「バカ」と使う「バカ」が共振した東証のシステムトラブル ［2005年12月22日］ あるメーカーの幹部に言わせると、「バカよけのロジックがなかった」ということになる。もちろん、みずほ証券による誤発注騒動の件である。東京証券取引所の売買システムに、重大なヒューマン・エラーが起る可能性を想定した要件定義が盛り込まれていなかったのか、システム開発サイドの人間から言うと不思議でならない----その人はそう話を続けた。「バカよけ」とは言葉は悪いが、多くの技術者が同様の思いを持ったことは事実だろう。 確かに、情報システムはエラー処理ロジックの塊である。今回のような通常あり得ないような入力ミスも含め、あらゆる事態を想定して要件を定義し、それに対処するエラー処理のロジックを書かなければならない。通常の処理ロジックだ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
IBM Developer
