タグ

システム開発に関するtadashi_shimizuのブックマーク (12)

  • 特許庁のシステム開発が破綻した本当の理由

    特許庁と東芝の新システム開発契約打ち切りについて、なぜこの開発プロジェクトが破綻したのかについて私なりの解説をしようとバックグラウンドを調べたところ、調べれば調べるほど、この問題の根底には(1)コスト意識が欠如し自分たちが「公僕」であることを忘れてしまった霞ヶ関官僚、(2)霞ヶ関から流れて来るお金にたかる IT ゼネコン、(3)そのお金の流れに対する影響力を利用して票を稼ぐ政治家、という原子力業界と全く同じような構図があることが明らかになり、ウンザリしてしまった。 破綻の原因は、ソフトウェア・アーキテクチャやプロジェクト・マネージメントにあったのではなく、「競争原理が正しく働かない社会構造」そのものにあるのだ。これではうまく行くはずがないし、たとえうまくいったとしてもやたらと高くつく。 そもそも破格だと言われた99億円という落札価格も、私から見ればどうみても高すぎる。特許庁のシステムであれ

    特許庁のシステム開発が破綻した本当の理由
    tadashi_shimizu
    tadashi_shimizu 2013/01/07
    引用「 特許庁のシステムであれ ば、優秀なエンジニアを10人集めることが出来れば1〜 2年程度で作れる 」←流石にこれはない。
  • SI屋さんとSIと、直近の課題について。 - 急がば回れ、選ぶなら近道

    某セッションでちょっとしゃべったことをつらつらと。SIの現状と近い将来について思うところをまとめておきます。自分自身の立ち位置も確認していくという意味で。 結論的にいうと、SI自体は必要とされていますが、SI屋さんのビジネスモデルは成立しないという状況になるので、旧来の「SI屋さんの方法」ではうまくいきません。なので、別のやり方でSIをどうやっていくか?という議論が必要になりますね、という話です。 まずSI事業は人月稼働で商売をしています。スタート地点はそうではなかったのですが、一旦大きな人数を抱えると、わせる必要があるため、より大きな仕事を取る羽目になります。要は稼働させる事、それ自体が目的になります。稼働を維持させる事で、収入を確保する事ができ、確保された収入で稼働のための人員を維持できる。そもそもそういう循環をベースに組織の目的が、「結果として」形成されてしまっています。 副作用と

    SI屋さんとSIと、直近の課題について。 - 急がば回れ、選ぶなら近道
  • システム開発の入門者から中級者にステップアップするための10のティップス - builder by ZDNet Japan

    ある読者との電子メールのやり取りの中で出てきた話である。彼は、開発者向けのブログや記事、雑誌の内容が2種類に分類できるということを述べていた。その2種類とは入門者向けのもの("Hello World"に代表されるもの)とエキスパート向けのもの(MSDN Magazineのようなもの)である。 これはなかなか鋭いポイントを突いている。開発者が入門レベルから中級レベルにステップアップするうえで役立てることのできる情報がほとんどないのだ。以下は、こういったステップアップを実現するための10のティップスである。 #1:新たなプログラミング言語を学習する 新たなプログラミング言語を学習することは、それがどのような言語であったとしても、より優れた開発者になるための近道となるのである(このことは、あなたが既に多くのプログラミング言語を修得していたとしても成立することである)。言語を選択する際には、あなた

    システム開発の入門者から中級者にステップアップするための10のティップス - builder by ZDNet Japan
  • プログラマーの開発速度は「はまる」時間の長さで決まる : 小野和俊のブログ

    プログラミングを始めてから今日に至るまで、 様々なタイプのプログラマーと開発を共にしてきたが、 驚くべき速度で高い品質のソフトウェアを作り上げるプログラマーには、 一つ共通の特徴があるように思える。 それは、「はまる」時間が極端に短い、ということである。 風のプログラマー」を指向しており、開発速度を重要視している。 例えば平成14年未踏ソフトウェア創造事業「PICSY」では、 発表直前に知人でプロジェクトリーダーの鈴木健にレスキュー隊として呼ばれて 2,3日でGUI全般と、クライアント/サーバー通信部分の設計と実装を終わらせたのだが、 このときなどは、大体の要件を口頭で聞いた後は、 ほぼまったく手が止まらずコードを書き続ける感じで開発をしていた。 「はまる」時間の長さは開発速度に直結するわけだが、 プログラマーが「はまる」場合にはある程度の傾向があると思うので、 今日は「はまる」プログラマ

    プログラマーの開発速度は「はまる」時間の長さで決まる : 小野和俊のブログ
  • エンジニアがタイトル買い、著者買いすべき本 - Fight the Future

    著者買いすべき! ファウラー、ジョエルは知名度もあり、改めて僕がどうこう紹介する必要はないと思うけど、ここではスティーブ・マコネルを特に推したい。 読んだ人には非常に高い評価を得ているけれど、その分厚さや価格もあってなかなか広まっていない。 特にCode Completeはすべてのエンジニアが必ず読むべきだと思ってる。 これを読んで理解する/しないが(職業プログラマとしての)初級と中級の境界だと言えるくらい。 タイトルにはCodeとあるけど、別にコーディングをターゲットにしたではない。 設計、テストも含めてコーディングを考えている。当たり前だがコーディングだけではコーディングはできないからだ。 上下巻1,200ページの大作だし、2冊で12,000円だがその価値は大いにある。 スティーブ・マコネル ソフトウェア見積り―人月の暗黙知を解き明かす 作者: スティーブマコネル,久手堅憲之,S

    エンジニアがタイトル買い、著者買いすべき本 - Fight the Future
  • エンジニアの勉強法について

    ヤフー株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。LINEヤフー Tech Blog こんにちは。 サービス統括部に所属しております、堀 邦明と申します。 普段はYahoo! JAPANトップページのフロントエンドエンジニアとして、JavaScriptPHP,Perlといった言語を利用して開発しています。 この度、デベロッパーズサミット2009というイベントにおいてエンジニア勉強法というテーマでJavaScript勉強法についてお話をさせていただきました。 今回は、そのときのお話について発表しきれなかった部分も含めてご紹介できればと思います。 勉強の分類 勉強には大きく分類して2つのステップがあると思います。 1. 情報収集 1つは情報収集です。 技術書やウェブサイト、ブログを読んだり、勉強会やセミナーに参加

    エンジニアの勉強法について
  • Webサービスを公開し、運用するために - 今日とは違う明日

    会社でプログラミングはしてるけど、プライベートでWebサービスを作って公開するには、どうすればいいんだか・・・という過去の私みたいな人のために。 とりあえず、前提として。 Webサービスを構築するためのある程度のスキルはある 何を作りたいかも決まっている でも、自分でゼロからスタートして公開までの段取りがよく分からん 1.開発言語、フレームワーク、データベースを決める 何はともあれ。持ってるスキルにあっているものが良いと思うけど、新しい言語やフレームワークにチャレンジするのも楽しいかも。お好きなものをどうぞ。ただ、all in oneなフレームワークだと、色々揃えなくてもいいから楽。 言語を決めたら、それに合わせた開発環境を用意して、Hello Worldが動く程度には動作を確認しておく。 私の場合は 言語はruby フレームワークはRuby on Rails データベースはpostgre

    Webサービスを公開し、運用するために - 今日とは違う明日
  • Webフレームワークが嫌いなので、こういう風になって欲しい。

    妙なカスタムタグよりも先にHTMLJavaScriptを書きたくなる人には、Webフレームワークは厳しい? ASP.NET Webアプリ開発の裏事情 > エピソード9:「モバイル対応」と闘う ある意味、問題点はこのリンクに集約されているかな。Strutsを使ってて感じるのは、 ・今まで当たり前のようにできていたことが、できにくくなった。 (正確に言うと、統一感を得る代わりに、ユーザビリティ主体にできていた個別のメッセージハンドリングやリンク制御とかが、Strutsのアーキテクチャに従った結果、自在に制御するのが「面倒くさい」。設計の問題なのは重々承知で、あえて書くが。) ・タグが覚えられない。HTMLを書いたほうが速いので、もどかしい。 (Strutsのattribute規則は直感的でないと思う。スキーマに機能を無理やりあわせこんだ感じがプンプンする。) ・同様にJavaScriptとH

  • 「50%の完成度でサービスを出す」という言葉を誤解してはいけない

    はてなの近藤社長の、「50%完成度でサービスを出す」という指摘は、まさに「ソフトウェアはサービス」の時代を反映する、ものすごく意味のある言葉だが、万が一勘違いする人がいると困るので、自戒も含めて補足しておく。 ここで言う「50%の完成度」とは、「サービスとして『完成品』と呼ぶにはまだ機能が十分揃っていない」という意味の完成度を指し、決して「アーキテクチャーや不完全だったり、明らかなバグがあるのにサービスインしてかまわない」という意味ではないので注意が必要だ。 少し前に、私の会社で外部のエンジニアを使ってあるウェブ・サービスを作ったことがあるのだが、慣れていない人にプロジェクトのマネージメントをさせてしまったために(これは私のミス)、一応外見上は動いているものが出来てきたものの、スケーラビリティに明らかな問題があり、ユーザーの数が増えたときに破綻するようなものが出来てきてしまったのだ。 担当

  • Life is beautiful: Windows95と地上の星

    Windows95の開発の総責任者であるDavid Coleから開発の主要メンバーに緊急召集がかけられたのは、Windows95の開発も大詰めを迎えた1994年末のことである。 Shell(デスクトップ、エクスプローラ、スタートメニューなどのユーザーインターフェイス)の開発を担当していたSatoshiは、いままでの経験からこの手の緊急招集が良い知らせでないことはないことは知っていた。 David Coleが深刻な顔をして緊急招集の理由を説明し始める。Windows95そのものの開発は順調に進んでいるが、Windows3.1との互換性の維持が思うように進んでいないのである。 「このままだと、95年中にリリースすることはできない」 深刻な問題である。既に当初の予定より1年以上遅れているWindows95のリリースをさらに遅らせて95年のクリスマスシーズンを逃すことはOffice95を同時にリリ

  • 日経SYSTEMS:お役立ちWebサイト101

    IBM東京基礎研究所 IBMディスティングイシュト・エンジニア 最年少で日IBMのエンジニアの最高峰であるディスティングイシュト・エンジニア(その上にはフェローがあるが世界で610人くらいしかいない)に登りつめた。日を代表するITアーキテクト。

  • 「渡された仕様書を実装するサラリーマンプログラマ」の悲哀

    @ITの「業務用途でRubyを使う上での課題 」を読んでなんだか悲しくなった。 チーム開発でRubyを使ったときに今後起こりえる問題として、サン・マイクロシステムズ システム技術統括部 チーフテクノロジストの下道高志氏は、こう指摘する。「他人の書いたPHPコードのメンテナンスはできない。Rubyはどうかといえば、現状はいい。しかし今後“職業プログラマ”ではなく、渡された仕様書を実装する“サラリーマンプログラマ”が増えてくると、コードのスパゲッティ化は避けられないだろう」。 【業務用途でRubyを使う上での課題 − @ITより引用】 これは言語の問題ではなく、日のソフトウェア産業全体が抱える問題。以前にも「ソフトウェアの仕様書は料理レシピに似ている」というエントリーで書いたが、来のソフトウェア作りとは、絵を描いたり、音楽を作ったり、建物をデザインするのと同じ「創作活動」である。ドラッ

  • 1