→ソフトウェア業界

→ソフト業界の労働環境

→日本のITユーザー

一般 †

  • IPAX 2008を見に行ってきた 2010.7.11
    • 有賀さん曰く、現在IT業界とよばれるところは80万人の雇用があるが、専門教育を受けたちゃんとした人材だけで仕事すれば8万人で済むとのこと。それぐらい、今のIT業界は専門教育を受けていない人材が含まれている、すなわち、それでちゃんと回るような社内教育システム、開発体制、長時間労働体制が構築されているということだと思う。
  • ガラパゴス化する日本の開発環境 2010.5.11
    • 日本以外のそれらの会社ではほとんど当たり前にやられている基本的なことが、日本企業の多くではまったくなされていないということになる。
    • 勿論各社毎に細かい違いはあるにせよ、ドキュメントを自動生成する仕組みや、ソース管理や、ユニットテストなどがきちんと出来ていないということは皆無であった。マネジメントやアーキテクトが居ないということもあり得なかった。
  • 効率化で消える人たち 2010.2.12
    • 現場のリーダーがため息をついておりました。プロジェクトは順調なのに……というか、かなり前倒しなのですが、なにをそんなに落ち込むことがあるの？ と不思議に思ってなにかあったのかと聞いてみました。
    • すると「予算を達成できそうにない」とのこと。
    • 末端場末のエンジニアにはその発言の意味がよくわからなかったのでちゃんと意味を聞いてみました。
    • 「今は月に30時間残業する計算で予算を出しているんだよ」
    • 「え？ なにか悪いことでもあるんですか？」
    • 「これだけコストが抑えられるのなら、人を削れっていわれるんだよね」
    • 人を削る＝その人にお仕事がなくなってしまうということです。
  • 「日本のIT業界に未来がない」のはデフォ 2010.1.27
    • 雇用調整助成金という名の生活保護を受けてる人を含めるともっと多い．しかも重要なのは，今後需要が増える見込みがほとんどない斜陽産業だということ．まるで炭鉱労働者を税金で食わしてるようなもんだよ
    • 日本のIT業界の不安は，勉強した人間が『全く』評価されないことも原因の一つ．
    • SIer以外のITビジネスは日本にはほとんどないというのが寂しい現実．
    • 「IT業界が実力主義」というのは幻想だと思うよ．だったらこんなに実力のない，胡散臭い奴らが跳梁跋扈するはずがないから．
    • むしろスキルを測るのがすごく難しく，スキルを測るのもスキルの一つ．にもかかわらずスキルの無い人が測ろうとするから，そこに矛盾が生じる．
    • 失業の不安はない？まるで数年前にJALを志望した学生のセリフのようだ
  • 日本ITの国際競争力
    • では資金力も技術力もある、富士通やNEC、日立製作所などのIT大手がイノベーションを起こすことはできないのか？　NTTはどうなんだ？という期待も出てくるかもしれない。しかし日本のIT大手には、先に述べたようなネットワークの発想が決定的に欠如している。いやもちろん、多くの企業幹部たちは「ネットワークこそが大事」ということは気づいてはいるものの、ではどうすれば自分たちが単なるハードメーカーではなくプラットフォーマーになることができるのかという問題にぶつかって、いまやお手上げの状態だ。ノーアイデアなのである。
  • 脱デスマーチ。IT業界構造改革に向けての緊急提言 2009.11.4
    • 結論を述べれば「デスマーチは経営ミス」です。「仕事を断る」ことも経営手腕の1つなのですから。
    • 短納期を希望する裏側に「遅すぎた発注」があります。これに「無償」で答える義理はありません。
    • そもそも「短納期」はクライアントの都合に過ぎず、追加料金を要求するのは当然です。
    • よその業界ではデスマーチは存在しません。人気ラーメン店の多くは「スープがなくなり次第終了」と客を断りますし、行列ができる焼き肉屋「スタミナ苑（東京都足立区）」は休日になると2〜3時間待ちですが、現時点では店舗拡張も支店出店も考えていないのは、「できる範囲」で対応するものであり、スタッフの犠牲的労働でデスマーチを成立させるIT業界が異常なのです。
  • IT業界での生々しい話を５つほど
    • 1. 2ch へのアクセス禁止で開発効率が大幅に低下
    • 2. 人事評価制度の歪みを解消するためにあえて優秀でない人材を採用
    • 3. 社内では使われない自社パッケージ
    • 4. 競合他社への販売禁止を条件に出されパッケージ販売を断念
    • 5. IPAのプロジェクトで間接業務に忙殺される
  • 【感想】１みたいな話は多くの現場で見られる。2chはともかくhatenaやniftyのブログにも有益な情報は多いのに閲覧禁止されて効率を落としているケースがある。最悪の愚行は、開発費をケチって開発者にまともなマシンを与えないことだと思う。今は６〜７万もあればそこそこのマシンが買える(2008年末現在)のにほんの目先の損得にこだわってCPUが遅くメモリが足りないような旧式マシンしか開発者に与えないなど。それで無駄になる時間に人件費をかけて何台の新品マシンが買えるか計算して見てほしい。
  • 元請けにこだわる理由 2008.10.17
    • お客様のお役に立つに当たって、人月である必要性などどこにもありません。単価を設定するという手間をさぼっている業界側の怠慢だと私は考えています。きちんと自分たちの「システム開発という業務」をIT化することで、頭数を揃えなくてもシステムを作れるようになります。今はハードウェアもネットワークも基盤となるソフトウェアも昔と比較すれば非常に安価に、およそタダと言っても良いくらいの価格で揃えられます。お客様のところに常駐派遣しなければならない理由などありません。であれば、私どものような小さな会社でも元請けがやれます。そして実際にやれています。
  • よかろう、ではIBMの実情について語ろう 2008.10.5
    • 下請けからしてみれば IBMがケツ拭いてくれないならなんでかなり中抜きされてまでIBM配下でやらなきゃならんのか、って思うよね。実際、責任は取らんわ契約するまで相談にも乗ってくれないわ(まあこれはそれが正しいけど)で何のために高い金払っているかわからんのですよ。
    • 顧客にしてみればIBMというでかい会社に任せるから、何かトラブっても何とかしてくれるし、その分高いお金(銀行なんかは下請け直接雇う倍は払っているでしょうね)を払っているわけだ。もう不満たらたらですよ。
  • 無責任感が漂うソフト開発の現場 2008.10.1
    • OSSを言い訳に使う人は、取引先に対しても、社会に対しても責任を放棄しているように見える。あるいはそこまで確信犯でなく、「食品偽装」くらいの感覚なのかもしれない。つまり、OSSを言い訳にして、とりあえずその場しのぎをしておいて、本当に問題が起きたその時は、自分でない他の誰かが何とかしてくれるだろう…こんな感覚である。
  • 開発コストにムダが多いIT業界、解決策は「分離発注」と「分割発注」 2008.8.7
    • ユーザー企業の担当者は，開発費用をミニマムにするようなプロジェクト運営の訓練を受けていませんし，開発費用を最低限に抑えても，だれに褒められるわけでもありません。むしろ，開発費用を絞ったために技術的なトラブルやベンダーとのトラブルが発生してスケジュールが遅れると，責任を追求されることがほとんどです。その結果，随意契約で発注したベンダーの言うことを聞いて，ベンダーに十分な費用的余裕を与え，リスクマネーを上乗せした形の予算を組んで発注する方向に傾きます。
    • フェーズを分けて分離発注しても，下流工程を1社のベンダーに発注する限り，システムの中身がブラックボックスになってしまうリスクは残るかもしれません。その場合に有効なのが「分割発注」です。
    • 高いスキルを持つ上流工程のベンダーを，まず競争見積もりで選定します。上流工程が終了したら，そのベンダーに下流工程用のRFP（Request for Proposal，提案依頼書）も作成してもらい，下流工程のベンダーを競争入札で選定します。そして必要に応じて，上流工程のベンダーに「マネジメント・コントラクタ」として下流工程の開発ベンダーをマネジメントしてもらうのです。
    • フェーズを分けて分離発注しても，下流工程を1社のベンダーに発注する限り，システムの中身がブラックボックスになってしまうリスクは残るかもしれません。その場合に有効なのが「分割発注」です。
    • これは，1社に“丸投げ”する代わりに，そこが使っている下請け企業を調べて，何社かの下請け企業に直接発注する方法です。元請け企業の“オーバーヘッド費用”を削減できるので，この方法を有効に活用できると，おおげさではなく，開発費用は半減します。
  • ベンダーの危機察知能力が落ちている 2008.6.23
    • 当社では元請けの大手ITベンダーに、プロジェクトの進捗管理まで頼ることをやめた。下請け会社に対しても、システム開発の進捗を我々自身がヒアリングするための会議を開くようにした。この会議で、プロジェクトマネジャーの知らない問題が明らかになったことも多い。
  • IT業界は成功するチャンスの多い夢のある業界 2008.6.6
    • ちょっとしたアイディアによって、運命が切り開かれていく。こんなチャンスがいっぱいある世界ってそうはないよ。しかも、学歴だとかコネとかお金だとか関係なく誰でも自由に参加できるのだ。
    • 「そんなのマッチョだけジャン」という人がいそうだけど、弾言しておこう。
    • 「がむしゃらに努力できない人は成功しない」「これはマッチョかどうかに関係ない」「どの業種かも関係ない」「がむしゃらに努力できる人だけが成功できるのだ」
  • 「受託中心と多重下請けが日本IT産業の低収益の要因」---経産省 情振課長 八尋俊英氏 2008.5.28
    • 日本の情報サービス業市場は世界第2位の規模だが，収益性は欧米IT企業に比べ低いだけでなく，インドIT企業よりも低い。その要因は受託開発中心の体質と多重下請け構造という情報サービス産業特有の問題点にある
    • IT産業のみならず，全産業の競争力向上のためにIT人材の高度化が必要だが，IT産業に魅力が欠如しているため優秀な人材が集まりにくくなっていると認識している。「どの大学でもコンピュータ・サイエンス（学科の入試合格点）は平均点以下。最も人気がないという大学もある」（八尋氏）。
    • その原因も，受託開発が中心で生産性・収益性が低いこと，長時間労働が常態化しているだけでなく，新たなフロンティアを開拓する発展性に乏しいことなどにあるとする。
  • SI業界もネット業界も世界に打って出られない理由 2008.5.11
    • 結局のところ雇用流動性だ。
    • それに限らず日本の場合は空気を読まないと産官からあの手この手で潰されるし、投資家も顧客企業もチキンだし、いくつか安定顧客を抱えながら収支をバランスさせる経営戦略でなければリスクをヘッジできず、そういうオーバーヘッドを抱えたまま、無謀を許され成長に応じた人材を容易に調達できるシリコンバレー組とグローバルで伍するのは極めて難しいのではないか。
  • 崩壊した人月からの脱却 2008.3.17
    • 話を総合すると，「人月からの脱却」の意味するところは，ベンダーが「ユーザーに“原価”を見せたくない」，ユーザーが「ベンダーの“残業代”を払いたくない」ということ。話がかみ合うはずはない。
  • 黒船の大砲がソフト業界に構造改革を迫る 2008.3.5
    • システムを一から作り上げるソフト会社が数多く存在する。しかも、みんなが食べられる多重下請け構造を形成した。
    • 山下氏は「ここに大きな問題がある」と指摘する。日本で開発されたソフトの品質や生産性は高いと言われているが、「腕のたつ職人が五重塔や神社を作っているような感じ」（山下氏）。確かに、特注品を1つひとつ作り上げるニーズはあるし、パッケージソフトの開発はその面が強くある。未踏の大規模システム開発を手がけるのも重要だが、海外ソフト会社に「五重塔が作れるか」と特注開発の技術を強調する意味は薄れている。ユーザー企業は競争に打ち勝つために短納期やコスト低減を求められているからでもある。
    • 今のソフト産業は同じようなシステムをあちこちで開発するというムダな作業を延々と続けている。この仕組みを根本から変えない限り、多重下請け構造や長時間残業などの問題を解決できない。技術の蓄積にも課題があるし、魅力ある産業にもならない。
    • このままの経営形態を続ければ、インドや中国など海外ソフト会社に買収されてしまう可能性すらある。時価総額3兆円のインド企業があることを考えれば、 100億円から1000億円程度の日本のソフト会社はいつでも買収対象になっても不思議ではない。ちなみに最大手のNTTデータでも1兆5000億円程度である。タタ コンサルタンシー サービシズ(TCS)やウィプロなどがM＆Aを視野に入れているようだ。TCSのスブラマニアン・ラマドライCEO兼社長は2月に来日したおり、日本向けプロジェクトを担当する技術者を今の2000人から6500人にすることを明らかにしている。ウィプロは現在のところ、その数は2500人である。
  • 御社の現場改善力鈍っていませんか 2008.2.27
    • 新人の育成などと悠長なことをいっていられないほどの切迫感で現場を切り盛りする中堅正社員の活躍ぶりだけが際立っているようです。いったい彼らの気合と体力がいつまで長続きするのか、誰も予想できないのではないでしょうか。新たな人材を育てる余裕を持たないことで、仕事をこなせる人材にさらなるしわ寄せが来る悪循環は、いずれ破たんすることは目に見えています。
    • 新人が実務経験を積むだけの時間と舞台が必要です。また作業者のお手本となる先輩社員（ロールモデルと呼ばれます）による指導や、もはやぜいたくな期待かもしれませんが、犯した失敗をフォローできるおおらかな職場環境もあるに越したことはありません。できれば目に見える財務的成果が期待されるテーマに取り組んだ方が対象者のやりがいも大きいでしょう。こうした人づくりの受け入れ態勢を作るためには、ある程度業務上の余裕（遊び）がなくてはなりません。人員削減の行き過ぎた現場では、この種の「遊び」がないために、前述の悪循環から抜け出せない状態が起こりやすいのです。
  • どうしてこんなにコミュニケーションが取れないのか？ 2008.2.26
    • スピード至上主義:リリースが早ければいいってものではない
    • オーバースペック:機能が多ければいいってものではない
    • 硬直化しつつもろくなった組織構造：分業が進み過ぎて、1つのチームとして機能しようという意識が希薄になっている
  • お持ち帰り問題 2008.2.1
    • 例えば金融機関向けのシステム開発はオンサイト、つまり客先で行うのが基本。請負であっても、案件を持ち帰って自社内で開発することは、セキュリティなどへの懸念から顧客が許さない。中央官庁もそうだし、大手製造業なんかもその傾向が強い。
    • そういうわけなので地方のITサービス会社は、こうした採算性の良い大口案件を下請けであれ、孫請けであれ、地元で請け負うことはほとんど不可能だ。必然的に地方のITサービス会社は、“東京の仕事”を求めて東京に支社・事業所を作るか、地方自治体など地場の限られた大口顧客に依存することになる。
    • ITなんだから技術者がどこにいても仕事ができるはずだ、と正論を言うのはたやすい。そして、それは世界の常識である。しかし日本の顧客は、ソフトウエアは目に見えないというITのもう一つの特性に不安を感じてきた。目に見えないから、せめて開発工程は目の前で行わせたい。ITサービス会社も「承りました」と御用を聞いちゃうものだから、絶対にオンサイトでないとダメという“非常識”がまかり通ってきた。
    • もちろん、最近では金融機関なんかにも外資が入ったりして、必ずしもオンサイトにこだわらない顧客も増えてきた。ところが、である。こうしたさばけた企業は、よりコスト削減効果を見込めるオフショア開発に走ってしまう。マクロ的には技術者不足とはいえ、景気に翳りが見えている中で、このままの状況が続けば地方のITサービス業は本当に危うい。
  • 進行基準が日本のIT企業のガラパゴス化を止める 2008.1.21
    • 進行基準では、プロジェクトの見積原価に対する進ちょく率に応じて、売り上げと損益を計上する。つまり、きちんと要件定義を済ませて仕様を確定させておかないと、当然のことながら精度の高い見積原価は算定できない。見積原価がいい加減なままプロジェクトをスタートさせたり、プロジェクト管理がずさんだったりすると、最終的な損益にしわ寄せが来る。要件を確定させないままプロジェクトを走らせる──などという、これまでありがちだったことは、今後は許されなくなる。
  • 情報サービス産業を救う銀の弾丸はない 2007.12.15
    • つまりユーザー企業の発注能力が低いとか、重層的な下請け構造とか、日本の情報サービス産業がおかしいと指摘されることの多くは雇用慣行への適応の結果であって、ユーザー企業やSIerの主体的な経営判断ではない。パッケージやSaaSの活用を更に進めるには、ユーザー企業とSIer双方のマインドセットやインセンティブが変わらなければならないが、いまの業界構造の背景にある解雇規制を取っ払っていかなければ、SOAとかSaaSも、昔の戦略情報システムとかオブジェクト指向のようにバズワードとして消費されて終わるのではないか
  • ソフトウェア改造力が足りない 2007.11.12
    • 【感想】改造力が足りないんじゃなくて、もとをただせば時間や予算が足りないんじゃないのか。安く上げようとして無理やりな改造を重ねて来た結果システムの保守性が落ちているのでは。それを開発者の能力だけのせいにするのはいかがなものか
  • IT業界の低迷の原因 2007.4.16
    • 国内ITサービス会社が価格決定力を失ったのは，
    • （1）技術革新の停滞，
    • （2）オフショア開発やパッケージソフトとの競合激化，
    • （3）省力化という視点での情報システム需要の一巡，
    • という環境変化が原因と見ている。いずれも短期的に反転が見込めないトレンドであり，ITサービス会社が「価格決定力」を取り戻すためにはこれらの変化への対応が必須となる。
  • IT業界の3K問題NTT社長はどう考える 2007.5.9
    • 要件定義が正しく行われないのが原因と浜口氏は見る。1度は要件を決めても顧客企業の都合で開発中に変更されてしまい、大幅な手戻りが起きてしまう
    • 強固な要件定義を行うためNTTデータはシステム開発の契約を2段階に分けることを始めている。1段階目では顧客とシステムデザイン契約を結び、コンサルティングにより、システム開発のグランドデザインや要件を決定する。要件定義を「見える化」し、顧客とNTTデータ側で意見の相違がないようにしておく。 2段階目で実際の開発請負契約を行う。NTTデータが開発した透明度が高い見積り手法を使うことで、顧客の理解度を上げる。SLAも導入し、システム開発を定量的に評価する。このように契約を2段階に分ける考えはフェージング契約と呼ばれる。
  • IT産業よ、工業化による品質向上でマトモな産業になれ」---CSK取締役 有賀貞一氏 2007.2.9
    • ソフトウエア開発の工学化についても，40年も前から重要性が叫ばれているが全然ダメと，バッサリ。下流工程でバグをつぶしている最悪の状況という。組み込み系の人材の少なさも問題という。世の中の工業製品を見渡すと，トヨタのレクサスは制御系で700万ステップ，カーナビ関係で700万ステップのソフトウエアを積んでいる。車もすでにソフトウエア商品になっているというわけだ。さらに，「2000億の売上があるのに利益がゼロだとか，1500億の売上に対して利益が10数億だとか，ソフトウエア企業はひどい有様。こんな業界に若者が来るわけがない」と指摘する。
  • 基本指針策定で政府のIT調達は変わることが出来るか? 2007.1.18
    • 実際の情報システムの調達に当たって、本当に「細部の細部」まで、最初の段階で明確に決まっているというようなことは、滅多にない。システム構築が始まってから新たな要請が出てきたり、仕様書に問題があったりして、手戻りがある… というようなことは日常茶飯事である。
    • このため、民間企業の場合、発注者側と受託者側が相互に情報を共有・交換しながら、ベストな解決を模索していく。
    • その間に、使用が変更になることもあれば、予算が変更になることもある。
    • 要するに、徹底的な「競争入札」よりも、「競争圧力が常に存在する随意契約」のような形を取っている場合に上手くいっていることが多い。
    • この「基本指針」においては、「システム改修などの要請に適時かつ柔軟に対応できることが望ましい」とは書かれているが、実際に政府の予算執行の段階になると、これは容易ではない。
    • このあたりは、予算ルール上は、システム構築に関する複数年度予算が認められていることになっているはずなのに、実際の事例がほとんどない…といった現状が示している
↑

実装技術の軽視 †

  • [考え事]今の日本の技術系企業には、何が欠けているんだろう 2012.1.6
    • あらゆるものが、その場しのぎで流れていく。社員教育といえば、実務を通して必要な知識を身に付けさせるというものばかりだ。確かにこれだと金儲けしながら勉強できるから、効率が良いように見える。でもそれは本当だったんだろうか。その方法の欠点が、今になって日本中で噴き出しているのではないのか。
  • ソフトウェア技術者軽視のシステム開発を続けるのはもう限界かもしれない 2012.1.25
    • クラウドの普及により、要件の定義から実現、運用までの期間が大幅に短縮できるようになったり、基盤構築など多くの仕事が自動化されることで、上流から下流まですべてを担当できるような真のソフトウェア技術者の役割がシステム開発で重要になってきているというところにあると思います。したがって、上流担当のSEだからといってプログラミング言語や基盤技術のことをまったく知らないといったことが許されない時代になってきている
  • SEとPG、どっちが頭がいい？ 2008.10.20
    • JavaによるWebアプリ開発でPG作業が軽視されている傾向は現在でも一向に変わりません。かえって強くなっているくらいです。特に大規模なアプリケーション開発では、いっそうそれが激しい。ということは、社会的に重要なシステムほど粗悪なプログラミングがなされている可能性が強い。事実わたしがうわさに聞く話では、あの大企業のシステムがそんな状態なのかということが多いのです。これは日本のIT産業におけるソフトウェア設計技術が構造的な原因から空洞化していることを意味しています。いくら見かけのドキュメントを整備しても、それは顧客の要求だけが精緻に文書化されたというに過ぎず、それによってソフトウェアの品質をコントロールしているわけではありません。大事なことはソースコードの品質なのです。にもかかわらず今日のIT業界は、ソースコードの品質を向上させるどころか、かえって悪くする方向に向かいつつあります。いったいなぜでしょう。
    • 前回も触れましたように、「PGは労働集約型の単純作業で、SEこそが高度な技術を担う職分だ」という、1960年代の職制がアウトソーシングによる固定費節減戦略に誤って適用されている傾向が、その原因の1つです。何度もいいますが、本来ソフトウェアの作成という仕事は設計とコーディングという作業に明確に分けることができません。それを無理やりに分けようとするなら、ネット社会を形成してきた数々の技術革新の成果はすべてPGに残り、SEはそれらから完全に疎外されることになりかねません。
  • 下流からみたIT業界 IT業界のシュールな現実
    • その２
    • ソフトウェア開発の業界では、PGよりSEのほうが単価が高いので、SIerは自分の社員をできるだけ早くSEにしようとします。そのためSIerには SEがたくさんいますが、実装技術が未熟な人も多い。わたしを担当したタカビーなSEのように、すこしばかりSQLをプログラミングしたというだけでSE の業務につかされるケースも出てきます。彼らがしてきた仕事はといえば、ほとんどが仕様書作成。わたしはあまり役にも立たない仕様書作りなどまともな仕事だとは思わないのですが、それだけを専門にしてきたSEはそれが正しい有意義なシステム開発の手法だと思い込んでいます。それを2、3年も続ければ、当然自分はさらに上流工程で仕事ができると思い込んでしまう。それが出世だと思い込んでいるし、そうしないと自分はいつまでもつまらない仕様書書きを続けさせられることになる。件のSEからは、実装作業に対する根拠のない侮りと、強烈な功名心と自分の置かれたポジションについての不満しか感じられませんでした（真の技術者はあまりポジションには執着しないものです。自分の技術が自分の価値を決めるのだと知っていますから）。
  • IBMの問題はアメリカナイズされた老害 2008.10.5
    • 今は昔と違って、プログラミング言語も進んでいていろんなことができます。事前に頭の中だけで考えることには限界があります。実際に作ってみないとわからないことが多いのです。それなのに、プログラムよりも先にプログラム設計書を書くってのは無理があるのです。
    • なぜ、こんなことが起きるかというと、IBMの上層部(今だとUS主体)がプログラミングは単純作業だと思っているからです。これは、日本のSIerの上層部にもいえることだけどね。
    • 老害に関しては、日本のSIerもIBMもそんなに変わらないんだけど、IBMはグローバル企業らしく、徹底的にオフショアを進めているのが悲劇の始まりです。日本のBPさんなら、だめなプログラミング設計書でも、なんとかがんばろうしようとしますが、オフショア先だと、そんながんばりはしないからね。
    • 日本のSIerもオフショア志向を強めているところが多いと思いますが、プログラミングだけを任せるやり方は、上記で書いたようにうまくいく可能性は低いと思うよ。
  • プログラマが仕様を決めればいい 2008.4.11
    • プログラマが仕様を決めちゃえばいいんだよ。そのほうがいいに決まってる。マネージャはユーザーの立場に立って要件を抽出しそれを固めていくことに邁進すればいい。プログラマはその要件を元に「それならこれで出来ます」という仕様を決めて、後は全部自分が実装までやればいい。本来、システム開発は要員が少ないほうがいいと思う。多すぎるとコミュニケーションコストが高すぎて死ねる。
  • なぜプログラミングが楽しくなくなったのか 2008.4.7
    • 日本のソフトウエア開発では、なぜか各工程に関わる職種のなかでもプログラマーの地位が低くなってしまっている。その労働環境の悪い一面が新３Ｋ（きつい、厳しい、帰れない）などと言われ、業界イメージ全体が悪くなっている。
    • 最近の大きなシステムでは、システム化できることがどんどん増えて複雑になっていて、コンピューターにやらせること、つまり仕様がなかなか決まらない。でも最終納期が決まっているので、後のほうの工程を受け持つプログラマーにしわ寄せがいってしまう傾向がある。
    • そして、当初想定してなかったような機能を後から足してくれと言われたりすると、美しく作ったはずのプログラムの構造がどんどん崩れていく。そして人とのやり取りや調整ばかりに時間が取られ、納期に追い立てられているとやらされ感のようなものばかりが残ってしまうという悪循環が生まれているのだと思う。
  • 日本のパッケージベンダーがダメな理由 2008.3.13
    • SIerが分業化すると、要件定義する会社、設計する会社、プログラミングする会社などのように分かれる。
    • だから、多重の下請け構造が発生し、コミュニケーションロスがプロジェクトマネジメントを阻害し、更には、元請が手配師しか脳のない集団になる。
    • 現代は、自社の内部でハードやライブラリを作りこむよりも、オープンソースをうまく使う方が実は品質もコストも良いと言う時代。
    • その体制を作り出すには、自社の技術者が常にオープンソースライブラリを調査して、その技術の先進性を見極めるという高度な能力を必要とする。
    • 手配師だけの会社では成り立たない。
  • プログラマー軽視のツケ 2007.3.23
    • 《技術者の能力低下も指摘されている。開発計画全体を管理するプロジェクトマネジャーを重用し、優秀なプログラマーを確保してこなかったことが問題とされる》
    • 「ソフトは最終的にはコーディング（プログラミング）で形作られる。コーディングしてテストをする工程がキーポイントだ。ところが分業化が進み、設計専門の技術者はプログラミングやテスト技術に明るくない状況が発生している。建築に例えると、ビル工事の現場を知らない技術者が設計しているわけだ」
    • −−ある電子部品会社の幹部が「ハンダゴテを使ったことがない社員がいる」と嘆いていました
    • 「プログラミングができない技術者も一緒だ。設計に当たる技術者に開発工程の問題点まで見通す力があれば、生産性も品質も高めることができる。日本のソフト業界はプログラマーを軽視した。能力のあるプログラマーにはいい報酬を支払い、品質や生産性を上げなければならないのに、そうしなかった。ある実験によると、できるプログラマーとそうでないプログラマーでは生産性に２０倍くらいの差がある。無論、できる人のプログラムは品質も高い」
    • −−システム構築にかける時間が短期化しているのも、技術者への圧迫要因と聞いています
    • 「お客さまのビジネスサイクルが速くなり、短期間でのシステム開発が要求される。技術者が時間に追われ、新しい技術を習得する余裕がなくなって、モチベーションと技術力低下を招いてしまっているケースがある」
↑

SI業界 †

  • 年金システム開発が1年以上停滞 2012.3.15
    • ITコスト削減のために分割発注の手法を取り入れ、安値で入札したITベンダーに発注した結果、ITベンダーの経験不足が露呈し、プロジェクトの成功が遠のく――。この構図は、1月に中止を決めた特許庁のシステム刷新と同じだ。
  • 日本とインドのシステムインテグレータの決定的な違いと日本の行く末 2009.11.24
    • 日本とインドのシステムインテグレータは非常に似通っているという話をしたが、今回は決定的に違う点を1点指摘したい。英語力だ。インドのシステムインテグレータの規模は10万人程度と紹介したが、10万人全てが例外なく英語を話し、全てのプロジェクトが英語で進行する、これは日本のシステムインテグレータとの大きな違いだ。
    • 日本のシステムインテグレータが、ソフトやハードのベンダーに「おたくは日本語の資料が充実していない」と不平を言っている間も、インドのシステムインテグレータは充実した英語の資料を読み、粛々と仕事を進めていくのだ。
    • 今から英語力でインドに追い付くのは容易ではないが、インドにも隙はある。というのも、メールでやりとりしている分には彼らは限りなくネイティヴなのだが、話してみると「これで英語が話せると言えるのか・・・」と思うくらい彼らのインドなまりの英語はわかりにくい。アメリカ人ですらたまにわからず、インド人との会議の最後にこそっと「次回は英語で会議をやりたいな・・・」などと言うシーンもしばしば。インドはもはや英語を話す人が世界で最も多い国となってしまったので、彼らが発音を直すことは日本人が英語を習得するより多分難しい。学校の英語でフォニックスなどを導入して、日本人がきちんとした発音ができるようになれば、まだ挽回の余地は十分にある。
  • 開発生産性が低い方が収入が多いって変だよね 2008.7.24
    • 大手SIerの開発手法が、生産性よりも失敗しないことを重視するのは、この事実が原因なのは間違いありません。失敗せずに多くの工数をかけたほうが売上が増えるのです。
    • 一定の利益率がないと受注しない会社は、一時的には、稼働率が下がることもありますが、暇なときに社員が休暇をとることもできますし、忙しいときにはできないような研究テーマをやる余裕も出てきます。このような余裕は、会社の活力を上げるためには必要なものです。
  • SIerが必要としているのは業務知識だという都市伝説 2008.6.20
    • 豊富な業務知識を事前に持っていないとSIができないというのは、金融以外では都市伝説
    • にもかかわらず、SIerにいくと技術的なスキルより業務知識のほうが重要だと思っている人が圧倒的に多いのは事実です。どうしてかというと、そのように教え込まれたからです。刷り込みですね。
    • 汎用機の世界では、技術的な部分で差がつくことはほとんどなかった。だから、差別化のために業務知識が重要視されたのです。
    • このようなプログラミングを軽視し業務知識を重要視する考えが、SIerでは、先輩から後輩へ脈々と受け継がれています。今では、プログラミングは発達し、人によって大きく生産性は違ってくるのに、その事実を知る機会がないのです。
    • 新人のころから、「プログラミングは付加価値の低いものだ。付加価値をつけるためには業務知識を身につけなければならない。」そう教え込まれたら、誰でもそうなるでしょう。
    • でも、現実はそうではない。(私の知ってる限りは)金融以外の業務知識は、プロジェクトが始まってから勉強しても十分間に合います。工数の見積もりをする人が、業務知識をあらかじめ持っていればそれで十分なのです。
    • それよりは、技術的なスキルを身につけ、ユーザの要件をいかにシステムに落としこめるかを知っていることが重要です。要件を技術に落とし込むスキルは、勉強しても身につかない。経験をつむしかありません。でも、技術的なスキルは、勉強して身につけることができます。SIerに入る前に身につけた技術的なスキルが、無駄になることはないのです。
  • SI業界の老害が若手と下請けを蝕む理由 2008.6.2
    • 実際にC/S以降何が起こったかというと、RAD、オブジェクト指向、Webアプリケーションなどの技術がプログラミングの世界を大きく変えることになりました。プログラミングは高度になり、プログラマの実力によって、生産性は大きく左右されるようになりました。
    • 一方、プログラミングが高度になったことにより、プログラミングを知らずに上流工程はできなくなってしまったのです。
    • 悲劇はここから始まります。経営層は、時代が大きく変わったことを認識できていないので、「上流工程は自分たちが行い」「下流工程は下請けに任せよう」とします。
    • ここで、老害による悲劇が起こります。プログラミングを軽視し、若手にプログラミングを教えないのです。
  • 大手ほどSI力の衰えが目立つ 2008.4.17
    • 一昔前は、発注先になるITベンダーのSEと打ち合わせれば、要件のあいまいさを補うことができたので、大きな支障はなかった。ITベンダーの読解力に期待できたからこそ、開発を外注化し、スタッフはシステムの企画や要件の取りまとめに専念できた。
    • ところが最近は違う。特に開発の「オフショア化」で風向きが変わったように思う。オフショア先と我々をつなぐ「ブリッジSE」が、往々にして要求を「読解」できないのか、通訳の役割を果たしてくれないのだ。
  • プログラミングできない元請けがプログラム設計書をレビューするという矛盾 2008.4.15
    • プログラミングが苦手な人にプログラム設計書を書かせても意味がない
      • 論理的に考えることができないから
    • プログラミングができない人にプログラム設計書をレビューさせても意味がない
      • 日本語を眺めているだけで、書いている内容を理解できないから
    • プログラミングができる人にプログラム設計書を書かせても意味がない
      • できる人の作業効率を下げるだけ
    • こんな非効率・非常識なことを改善するだけで、日本のSI業界はもっとよくなる
  • SIerのジレンマ 2008.2.29
    • 優秀な人には雑務と質問という不毛な負荷が集中する。まるでパチンコの右下にどこにも引っかからなかったパチンコ玉が落ちるように，誰も拾わなかった困難が集中する。
↑

業界イメージの悪化問題 †

  • イメージはそんなに悪くない 2008.2.29
    • 学生が就職を希望する業界としてIT業界は全24業種の中で8位。
    • 「今後の日本を支えていく」業種を尋ねる質問では5位と上位にランクされるものの、「人気が高くて就職が難しい」では10位、「働いている人の満足度が高い」でも10位、「優秀な学生が就職する」でも11位と中位。情報系の学生ではいずれの質問に対しても平均よりも上位に来ているが、文系と情報系以外の理系の学生の答えがもう1つだった。
  • 復活果たしたITサービス業界がこの５年で失ったもの 2007.7.20
    • 1.業界への若者の好感度
    • 2.業界の成長性
      • かつてのような右肩上がりの成長シナリオを描けるソリューションプロバイダは少ない。既に金融業界向けでは，顧客の旺盛な引き合いに応えられず，一部の仕事をやむなく断るケースも続出している。「攻めに出たいが，人を抱えるリスクはITバブル期に思い知った。そもそも新人・経験者を含め，募集をかけても人が集まらない」−−。あるソリューションプロバイダ幹部の述懐から，売り上げをマンパワーに依存する典型的なITサービス企業の限界が見える。
  • IT業界不人気の理由は？現役学生が語るそのネガティブイメージ 2007.10.31
    • そもそもどんな仕事をやってるのかイメージが湧かない
    • いくつか挙げられたIT業界のイメージは実にネガティブな内容だった。いわく「きつい、帰れない、給料が安いの3K」に加えて、「規則が厳しい、休暇がとれない、化粧がのらない、結婚できない」の“7K”というイメージだ。学生は、ほかの業界と比べて「IT業界は特に帰れない」というネガティブな印象を強く持っているようだ。
    • 「工程ごとにいろんな呼称があるが、ITコーディネータやITアーキテクトなど、具体的に何をやっているのかさっぱり分からない。
    • 参考：http://d.hatena.ne.jp/JavaBlack/20071102/p1
トップ   編集 凍結 差分 バックアップ 添付 複製 名前変更 リロード   新規 一覧 単語検索 最終更新   ヘルプ   最終更新のRSS
Last-modified: 2012-06-01 (金) 21:42:17 (6d)