タグ

システムに関するkonoのブックマーク (11)

  • お見積りは無料です | タイム・コンサルタントの日誌から

    最近、電車に乗っていると、ときどき壁面上部の広告欄に空きスペースを見かけるようになった。さすがに、つり革広告はまだフルに使われているようだが、少しずつ車内広告の量が減少しているらしい。テレビ局や雑誌社も広告収入の減少で青息吐息の状態だ。 情報というものが無料で手に入る、と広く信じられるようになったのは、20世紀後半のことかもしれない。それまでは、だろうが新聞だろうが、一応の対価を払って手に入れていた。それが、ラジオが普及し、さらにテレビが後を追って、受信料を取るNHKをのぞく民放はすべて無料で番組を提供する時代になった。これは広告という新しい産業のおかげである。私は子供の頃、テレビが家にきたのをかろうじて覚えている世代に属するが、おそらく40代以下の人たちは、生まれたときから家にTVがあって、無償でさまざまな情報が送られてくるのを、空気を呼吸するのと同じ感覚で受け止めているにちがいない。

    お見積りは無料です | タイム・コンサルタントの日誌から
  • グループウェア担当者の現場業務への関心は低い:ナレッジ!?情報共有・・・永遠の課題への挑戦:オルタナティブ・ブログ

    先日ITRが発表した調査によると、企業のグループウェア製品については4割近くの企業が10年以上、5年以上使い続ける企業が65%以上となっている。(参考記事:「グループウェアを10年以上使い続けている企業が4割、次はクラウド化?」) この記事の中で館野氏が、「コラボレーションツールへの投資意欲が上昇」、「長期的ビジョンが不可欠」と述べているのには同意するが、「自社開発システムが多い背景には、現場のニーズを優先させる風土があるため」というのにはちょっと首をかしげた。 仕事の担当の関係上企業のコラボレーションツールの担当者と話をすることが多いが、コラボレーションツールの担当者の大半が自社の情報共有基盤が実際にどう使われているかを理解していることは少ない。そして自社の業務の中でどう情報を活用すべきかの理想像やあるべき姿、別の言い方をするとグループウェアを使って日々の業務をどう改善するかに興味を持っ

    グループウェア担当者の現場業務への関心は低い:ナレッジ!?情報共有・・・永遠の課題への挑戦:オルタナティブ・ブログ
  • 内製開発を考えているSI技術者が知っておくべき内製アンチパターン - aike’s blog

    数年前から、ゼネコン的なSIerの業態に構造的な限界を感じ社内のエンジニアによる自社開発(内製)を見直す動きが見られます。自分の場合も少し前にSI企業を辞めて今は内製をしていますし、知り合いの技術者にも何人かそのような転職をした人がいます。しかし、彼らの話を聞くと良いことばかりではないようです。 そんなわけで、今回は内製に潜むアンチパターンをまとめてみました。なお、ここでは一般向けプロダクト開発ではなく、社内向け業務システムの開発を想定しています。 ■そこは異業種ですよ 内製ということは、ほとんどの場合その会社はシステム開発会社ではなく、異業種に転職することになります。そのため想像以上に開発の常識が通じないことにとまどう技術者も多いようです。SIのとき、システム開発に理解がないゆえに無茶を言う顧客にあたった経験があるかと思いますが、自分以外の社員が全員そのような人であるおそれもあります。

    内製開発を考えているSI技術者が知っておくべき内製アンチパターン - aike’s blog
  • ERPの落とし穴part1~SW開発ではない。要求開発だ! - プログラマの思索

    今まで数々のERP開発に携わってきたけれど、正直楽しかったと言う印象はあまりない。 開発者が想像するソフトウェア開発とは何か違う。 そんな時に梅田弘之さんの「グラス片手にデータベース設計~販売管理システム編 (DBMagazine SELECTION)」を再読して、ERPについて色々と感じるものがあった。 ERPの落とし穴やポイントについて考えたことをメモ。 【1】ERP開発はソフトウェア開発ではない。要求開発だ! ERPは基幹系業務システムのためにある。 その開発スタイルは正直ソフトウェア開発ではないと直感している。 開発者がイメージするソフトウェア開発は、問題やタスクをプログラミングやサーバー構築などの技術で解決していくこと。 その作業は大変だが、やりがいはある。 しかし、ERP開発では、顧客から要求を収集し、要件として定義して後続の設計作業に落とし込む作業期間が非常に長い。 開発でき

    ERPの落とし穴part1~SW開発ではない。要求開発だ! - プログラマの思索
  • 人材の流動化か囲い込みか

    最近、日のSI企業と仕事をする機会あった。 久々に衝撃的な体験だった。 とあるシステム案件の下請け的開発依頼だったのだが、 1.アーキテクチャがおかしい ビジネス系の人が直接実装担当のエンジニアに指示を出している。丸投げである。よってアーキテクチャが根的におかしいのだが修正できない。 アーキテクト不在。 2.ドキュメントが無茶苦茶 基なぜかエクセルで書いている。読みにくいことこの上ない。さらにバージョン管理が無茶苦茶である。ほとんど読んでも意味の無い古いドキュメントだらけで解読が非常に難しい。アプリのバージョン、開発環境などもドキュメント毎に違っている。ビルドするとドキュメントが自動生成されるなんてことは一切ない。 ドキュメント担当不在。 3.プロダクトのソース管理が無茶苦茶 ソース管理ソフトはつかっているものの、理解不能なブランチに分かれていて同等製品が複数派生している。修正に手間

    人材の流動化か囲い込みか
  • ソフトウェアのアウトソース

    渡辺千賀さんのエントリーにはシリコンバレーではアウトソースが間に合わないのでどんどん内製していくという話が紹介されている。 最先端のウェブサービス開発の現場は、とてもアウトソースなんかできない状況になっている。「仕様書を文章で作って、それを誰かが作る」なんていう悠長なやり方は通用しない。どんどん機能開発して、どんどんリリースして、ユーザーのフィードバックを元にさらに進化させる、というのを、毎日行い続けないとならない。私が働いていたカナダのベンチャーもNZのテレコム系の会社も下請け、孫受けである。 どちらもインフラ系のシステムで、業務内容が大規模、複雑で仕様が比較的安定しているためか、仕様書ベースでのシステム納品を行っている。ウェブサービスのスタイルとは違う。 しかし、下請けといっても日のそれとはかなり違っていることが経験してみて分かった。 ・上から下への丸投げはない。 ・社員の給料は上も

    ソフトウェアのアウトソース
  • 業務をアウトソーシングした後の社員は何をするの:ナレッジ!?情報共有・・・永遠の課題への挑戦:オルタナティブ・ブログ

    ずいぶん前の話だが、ある会社から現在運用しているインフラ系システムのひとつをアウトソーシング(今流行のSaaS)にしたいという引き合いをうけて訪問した。対象のシステムは24H365Dの稼働が求められるため運用が大変で自社の運用管理者を貼り付けておくのが勿体ないというのがきっかけで、システム名を聞く限りどこの会社にもある一般的で共通的なシステムだったので、この意見にさもありなんと同意をして訪問することにした。 当日詳しく話を聞いてみると、このシステムには今でも自社の開発者が数名はり付いて継続的に追加開発やメンテナンスを行っいるとのこと。採用していたプロダクトが独自アーキテクチャーだったことも影響しているのだろうが、ユーザからのきめ細かい要望に対応する為に自社SEをそこに特化させて抱え込んでいたようだ。 ところが社の企画部門から情報子会社に異動してきたという担当者が声高に叫んでいるのは「単純

    業務をアウトソーシングした後の社員は何をするの:ナレッジ!?情報共有・・・永遠の課題への挑戦:オルタナティブ・ブログ
  • 権力を分散して物事を進める仕組み - アンカテ

    権力を分散することは簡単なことで、全ての要職を日替わりの当番制にすればいい。 難しいのは、権力を分散して物事をきちんと進めていくことで、三権分立っていうのは、それができるから重要なこととされている。 権力が集中するってことは恐しいことだけど、物事が進まないってことも、かなり恐ろしい結果につながることがある。 だから、権力を分散して物事を進めるシステムっていうのは、非常に貴重なものであって大事にしていかなきゃいけないものと思う。 インターネットの中には、分散して物事を進めるシステムがいっぱいある。 たとえば、DNSがそうだ。www.apple.comというホスト名は実は最後に一つピリオドが省略されていて、www.apple.com.なんだけど、そのピリオド一つごとに管理する主体がある。ルートDNSの管理と、.comと.apple.com の 管理は皆違う人がやっている。 ピリオドごとに管理者

    権力を分散して物事を進める仕組み - アンカテ
    kono
    kono 2010/04/11
    今回の方針変更は「何をやってもいいが俺の気に食わないことはやってはいけない」としか読み取れない。
  • 仮想パネル:ソフトウェアアーキテクチャの文書化について

    Len Bass氏, SEI (Software Engineering Institute)のテクニカルスタッフのシニアメンバ、Software Architecture in Practiceと、もうすぐ第2版の出る "Documenting Software Architectures: Views and Beyond"の共著者。 Grady Booch氏, IBMフェロー、 Webサイト"Handbook of Software Architecture"の著者 Paulo Merson氏, SEI (Software Engineering Institute)のテクニカルスタッフのシニアメンバ、"Documenting Software Architectures: Views and Beyond"の共著者 Eoin Woods氏, Barclays Global Inve

    仮想パネル:ソフトウェアアーキテクチャの文書化について
  • http://as400bks.rochester.ibm.com/html/as400/v5r1/ic2962/info/nls/rbagsdefaultsysval2.htm

  • 失敗からの脱却――日本の宇宙開発はなぜ成功し続けるのか

    ロケットの相次ぐ打ち上げ失敗など、2000年前後の日の宇宙開発は実に厳しい状況が続いていました。ところが一転、ここ5年間は連戦連勝の成果を収めています。その背景には一体何が隠されているのでしょうか。 好調な日の宇宙開発 最近、日の宇宙開発が好調です。宇宙航空研究開発機構(JAXA)は、昨年、国際宇宙ステーション(ISS)の日実験棟「きぼう」の建設を完成させました。若田光一宇宙飛行士に続いて、現在、野口聡一宇宙飛行士がISSに長期滞在しています。また、H-IIAロケットやその能力増強型ロケットであるH-IIB試験機1号機の打ち上げも連続して成功し、それらによって打ち上げられた月周回衛星「かぐや」や温室効果ガス観測技術衛星「いぶき」、宇宙ステーション補給機(HTV)技術実証機も成果を上げ、世界各国から高い評価を受けています。 例えば、いぶきは地球温暖化の要因となる二酸化炭素やメタンガス

    失敗からの脱却――日本の宇宙開発はなぜ成功し続けるのか
    kono
    kono 2010/01/27
    テーマは大変興味ある。今後に期待。
  • 1