タグ

siに関するteikuのブックマーク (8)

  • プロジェクトマネジメントなう\(^O^)/ | ぽんぽんぺいんなう\(^O^)/

    20代後半から15年ほどSIプロジェクトのリーダー/マネージャーをやってきた経験から。 『 監督とは、 他人が打ったホームランで金を稼ぐことだ。 』 ケーシー・ステンゲル(MLB監督) ●ポリシー 1)全てのメンバーが目的・段取りのわからない仕事をしない/させない。 2)プロジェクトの成功には、短期的な成功と中長期的な成功がある。両方を意識すること。 3)プロジェクトの短期的な成功は、お客さんを満足させることと利益をあげること。 4)プロジェクトの中長期的な成功は、リーダーとメンバーが成長し、また一緒に仕事をしたいなと思い合うこと。 5)リーダーとメンバーがフラットでオープンな関係を築けなかったプロジェクトは、中長期的には失敗する。 6)みんなで得意なことを持ち寄って知恵を出し合ってやってみてダメだったらそれは僕らにはムリな仕事だったということ。 7)人は一人一人別人であり仕事に対するスタ

  • 受託開発とGPL

    GPLに対する代表的な誤解・・・というかむしろ謎のひとつに、受託開発(SI)におけるライセンスの扱いがある。この点が明確になっていないため、受託開発において無意味にGPLを回避しようとしたり、GPLに対するFUDを流布することに対する原因になっていたりするように思う。フリーソフトウェアおよびオープンソースソフトウェアを愛する者として、そのような状況は断じて見過ごすことができない!!というわけで、今日はGPLを受託開発(SI)において用いる場合の注意事項を説明しよう。 GPLの使いどころ受託開発においてGPL(とその仲間たち=LGPL、AGPL)が登場するのは、第三者、つまり発注側でも受託側でもない者が作成したGPLのソフトウェアを利用する場合である。例えばGPLが適用されたライブラリなどだ。周知の通り、GPLのソフトウェアをリンクしたソフトウェアを再配布する場合は、そのソフトウェア全体に対

    受託開発とGPL
  • 契約書のツボ(3)

    「システム開発契約書」とは、ソフトウェアの開発を委託または受託するときの契約書です。 自分が委託する側なのか、受託する側なのかによって大きく内容が変わってきますが、契約書を作成したり、内容を審査したりする際の重要なポイントとしては、以下のものがあります(書では基的に受託者側の立場で解説していますので、ご注意ください)。 なお、システム開発契約の参考書としては、(旧)社団法人日電子工業振興協会によるモデル契約書を解説した「ソフトウェア開発モデル契約解説書」が秀逸です。大手SI企業では、全SEに配布しているとか。これ一冊でシステム開発契約は万全です(プロジェクトマネジャは必携です)。

  • 経産省が脱・人月を目指す「情報システムのPBCに関する調査研究」報告書を公開

    報告書は「現行の人月をベースにした価格による契約では,ユーザーとベンダーの双方が価格に対して不信や不満を感じている」とし,「人月積算を前提とした固定価格のみでは,ベンダーの品質向上や創意工夫などへのモチベーションは生まれない。さらに,ユーザーにとって経営層に説明できない価格では,投資の妥当性を提示できず,投資意欲そのものを減退させてしまう」と,人月の問題を指摘している。 そしてPBCではユーザーにとっては「無駄な投資が減る等,適正な価格でのIT投資ができる」,「目的を共有することから,ベンダーの積極性を期待することができる」,ベンダーにとっては「システムの効果に応じた適正な対価を得ることができる」,「人月ベースの契約から脱却することで,付加価値の創出や効率化に対するモチベーションが向上する」といったメリットがあるとする。 PBCのデメリットとしては,ユーザーにとっては「契約時に価格が確定せ

    経産省が脱・人月を目指す「情報システムのPBCに関する調査研究」報告書を公開
  • スーパークリエイターがSI業界で即戦力になれない理由 - aikeの日記

    少し前に若いエンジニア達と話す機会があった。この春SI企業に入社してプログラミングの研修を受けているという。みんなそれぞれ能力が高い上に、学習の高速道路を爆走中といった感じでネット上で話題になっているような技術情報には十分詳しい。SICPを全部解いたとも言っていたし当はプログラミングの研修なんか必要ないのだろう。未踏に応募したり勉強会を開催したりするのはこういったタイプなんだろうかとか、いまどきのSI企業の人材獲得能力はすごいなとか思いつつ、でも彼らはこの業界に何を求めてどうなろうとしているのか少し気になったりもした。 これほど優秀で勉強もしてきた人達でも、SIerとしては即戦力にはならない。社会人マナーとか仕事の進め方の話ではなくて、単純に知識不足という意味で。そのため一緒に入社したプログラミング能力の低い社員と同じように扱われる可能性が高い。これはすごく不幸な状態だと思う。SI業界が

    スーパークリエイターがSI業界で即戦力になれない理由 - aikeの日記
  • 10年間泥のように働いて花が咲きました - ひがやすを技術ブログ

    蓮の素晴らしさを語りたかったら、まずは花を見せるべきなのだ。花がわかってはじめて泥の重要さがわかってくるんだから。 2008-05-29 - ひがやすを blog 小飼弾のアルファギークに逢ってきたのメンバーと学生会の討論会を開くのだ。 もちろん、司会は、ダンコーガイ。いいよね、弾さん。 もちろんOK。というよりもすでに同様の話がいくつも来ているので、この通りになるかとにかく、ちゃんと「花」がある討論会はできるだろうし実現するだろうしすでにいくつか実現している。 しかし、これはこれでどうしても偏りが出る。10年も泥の中にいた人というのはさすがにこのメンバーの中から見つけるのは難しい。そしてIT業界の広さを考えれば、当にそういう人がいてもおかしくないはずなのだ。 10年間SIerで泥のように働いたおいらが通りますよ。 おいらが、最初に就職したのは、電通国際システムという会社で、今のうちの会

    10年間泥のように働いて花が咲きました - ひがやすを技術ブログ
  • 404 Blog Not Found:惰訳 - 建築士がプログラマーのごとく働かねばならぬとしたら

    2007年10月26日01:45 カテゴリ翻訳/紹介Art 惰訳 - 建築士がプログラマーのごとく働かねばならぬとしたら 全プログラマーが泣いた。 If architects had to work like programmers... 実は一つだけ「ローカライズ」にあたって変えた前提があります。日ではこちらの方が実情に沿っているでしょう:) 建築士様、 家を一つ設計施行してくださいな。まだ何が必要か具体的なことはわからないので、そこはよきに計らう方向で。 寝室の数は、2から45までの間。寝室の追加と削除は簡単に出来るようにしといて下さいね。青写真が出来次第あたしが何が気に入ったかを最終判断します。それぞれの青写真について明細書を付けるのをお忘れなく。後で気に入ったのをピックアップできるように。 完成後の家の費用は、今住んでいる家よりも安上がりでないと駄目なことを留意してくださいな。そ

    404 Blog Not Found:惰訳 - 建築士がプログラマーのごとく働かねばならぬとしたら
  • 人月を超えるということ

    人月というのは文字通り働いた時間に応じて請求が行われるというもの。ブルーカラー的な労働をしている限りは人月で働くことは正当なわけです。 「作らない」という視点 人月を超えるためには時間に関係なく圧倒的な成果を挙げる方法を見つけなくてはいけません。でも、圧倒的に生産性をあげるという視点ではだめ。生産性を上げているというのは、あるプロセスの作業効率をあげて時間を短くしているに過ぎないので時間給の罠からは逃げられない。ありがちな話として3ヶ月かかるAさんよりも、2人月でできるBさんのほうが実入りが少ない。 では、どうするかというと「作らない」という視点になる必要性があります。作らないというのどういうことかというと「作ったものをいかに使いまわせすか」か「いかに他人に作ってもらうか」ということです。 作ったものをいかに使いまわせすか=レバレッジを効かす 使いまわすというのはレバレッジ(てこ)を効

  • 1