agile＋オフショアは非常に困難。 - プログラマーm-matsuokaの生存記録
http://d.hatena.ne.jp/nanoha3/20090305/1236232630 →今までコーディングにオフショア使ってたため、従業員にコーディングのスキルが育たなかった。ところでagile＋オフショアは無理な組み合わせ？ 非常に困難。 なぜなら、オフショア側からのフィードバックを受け取るのが難しいから。 オフショア側のコーディングミスや仕様理解の誤りなどのフィードバックを受け取ることが難しいため、そのフィードバックをもとにした改良も困難になる。 こちらの仕様や要求の変更をオフショア側に伝えるのも難しい。 （厳密な仕様を作って伝えるくらいなら、こちらでコードを書いた方が早いと思う） コーディングスキルが無ければ、オフショア側が作ったコードの品質もチェックできないだろうし。 ビデオ会議やメールで、相手の理解度のチェックや、こちらの仕様を理解させるのは非道く疲れることですし（
大規模プロジェクトでagileやった結果がこのざまだよ - World Digger
知り合いのIT会社のすんげー偉い人の話を聞いたのでmemo 問題になったら消します。 【状況】 ・某大企業でのとある大規模プロジェクトをagileでやった。開発人数は50〜80人。 ・クリティカルでないシステムだったため、SI側/会社側もagileでやることをOKした。 →クリティカルなシステム（例えば携帯電話会社の料金システムのような、カットオーバー日をずらせないシステム）をagileでやるのは、先が読めないからいかんとのこと。 【問題発生】 /結局SI側もクライアント側もあまりagileを理解してなかった系 ・今までウォーターフォール開発の進捗管理になれていた役員（意志決定者）が、プロジェクト開始後しばらくしても収束することのない将来予測に(((( ；ﾟДﾟ))))ｶﾞｸｶﾞｸﾌﾞﾙﾌﾞﾙ！→怖いからやめた。 ・必要とされるスキルに対して、個人のスキルが足りないケースが多かった。 →今
痛い目に合わないとわからない - masayang's diary
酔狂人の異説: ウォーターフォール型開発は最初から破綻している? そもそも、洗い出せていないリスクや問題点が存在しないって、どうして言えるんだろうか。存在しないことの証明は、「悪魔の証明」って言われるほどで、事実上不可能なのに。存在しないことの証明ができるなら、プログラムにバグの無いことの証明もできるだろう。最初から不可能なことをできると考える時点で、既にウォーターフォールは破綻しているということ。 そのとおり！ でもね... 洗い出せていないリスクや問題点を吸収できるだけの「ゲタ」を履かす事で、破綻する確率を下げる事ができる。 その「ゲタ」は例えば下記の通り： おびただしい量の成果物を記述するための労力分を余裕をみて請求する。 プロジェクト後半で発覚する問題点を押さえ込むための労力分を余裕をみて請求する。 それらのゲタを見越した顧客の値引き要求に対するさらなるゲタ。 その値引き要求に対す
ウォーターフォール型開発は最初から破綻している? - 酔狂人の異説(新館)
ウォーターフォール大好き人間達にいつも言われたことは 「リスクと問題点は全て洗い出して解決しなきゃいかんのです。 随時解決するなんてリスクはとれませんよ」 よくよく思えばやり始めていきなりわかるほうが対策が打てる分有利だよなとしみじみ思った。 そもそも、洗い出せていないリスクや問題点が存在しないって、どうして言えるんだろうか。存在しないことの証明は、「悪魔の証明」って言われるほどで、事実上不可能なのに。存在しないことの証明ができるなら、プログラムにバグの無いことの証明もできるだろう。最初から不可能なことをできると考える時点で、既にウォーターフォールは破綻しているということ。
ドメインモデリングよりもユーザーインターフェースを (arclamp.jp アークランプ)
S/N Ratioで紹介されていた「ソフトウェアアーキテクトが知っておくべき10のこと」が、いい感じです。佐藤さんの紹介をそのままに。 人がプラットフォーム (People are the platform) すべてのソリューションは時代遅れ (All solutions are obsolete) データは永遠だ (Data is forever) 柔軟性が複雑性を生む (Flexibility breeds complexity) 期待通り動くものはない (Nothing works as expected) ドキュメントは普遍的なソースコード (Documentation is the universal source code) ビジネスを知るべし (Know the business) ビジョンを維持せよ (Maintain the vision) ソフトウェアアーキテクトもコー
属人性？あれでしょ、その人じゃないとできないって奴 - プログラマーの脳みそ
「属人性？あれでしょ、その人じゃないとできないって奴」 じゃぁ問題。個人経営の病院があって、医者は一人しかいません。診察や医療行為は属人性が高いでしょうか？低いでしょうか？ 「その医者がいないとできないんだから属人性が高いんじゃないの」 違うんだよね。この場合は高いか低いかわからない。属人性ってのはそういう「その人じゃないとできない」じゃないんだよ。 「だって代われないじゃん」 いや、医師免許をもってる人なら代れるよ。属人性ってのはその仕事をやる技能や資格を持っているかどうかって話じゃないんだ。仕事のやり方が標準化されているかとか、マニュアル化されているかとか、引き継ぎできるかどうかって話題なんだよ。 「資格が必要でも引き継ぎができるなら属人性は低い？」 そうそう。 ソフトウェア開発の属人性の誤解 属人性の排除が狙うところってのは「その人しかやり方を知らないよ、秘密だよ」って作業をなくす話
OPC Diary: インハウス時代のソフト会社をうけての私考
« .NET 4.0 でのSystem.Shell.CommandLine Parsingを使用したコマンド列の解析 | メイン | お爺さんがテレビを射殺して逮捕、動機はアナログ停波 » 2009年02月23日 インハウス時代のソフト会社をうけての私考 スタロジ、羽生さんのBlogより 株式会社スターロジックの羽生章洋が書いてるブログ:インハウス時代のソフト会社 - livedoor Blog（ブログ） ここ数年、OSS（オープンソースソフトウェア）関連で講演させていただくときに「インハウス（内製）が復権する時代の到来」ということをお話させて頂いてます。 OSSというのは基本的に無償で入手できます。そして肝であるソースコードが公開されている、つまりオープンであるであるのが最大の特徴です。この特徴を活かすことで、少し知識のある人がいれば自社内でIT化を進めていけます。例えばこ
師匠の話をまたしましょうか - みねこあ
最近はやりのソフトウェア工学と属人性の話について。色々書いてみたのですが上手く書けなかったので、師匠の話をしてみます。 漫画家体制のはなし もともと組み込み屋さんからスタートしたわたしですが、Webの大規模な開発を経験するまで、漫画家体制の話は普通の話だと思ってました。 わたしの師匠なんか、わたしを含めて弟子を抱えてた感じです。で、その師匠が一番威力を発揮する仕事に専念させる作業が私たち弟子の仕事の一つでした。 電話番して居留守をつかったり、開発機材を手配したり（レンタルとか購入見積りとか）。そしていわゆる管理職的な仕事――勤怠申請に上長印を押したりも、当時新人だったわたしの仕事でした（師匠に預けられた師匠の判子を使ってバシバシ処理してましたヨ） 雑務はいろんなところに転がっていて、進捗管理はメンバーの仕事っぷりを把握することが本当の仕事で、ガントチャートを頻繁に更新したりするコト自体が仕
第1回 役に立たない情報システムができる本当の理由
経営者にとって、情報システムは頭痛の種になりがちだ。業務に必須だが投資に見合った効果が出るとは限らない。ほかの設備投資に比べて専門的で難解でもある。 野村総合研究所で約20年間勤務した後に、人材派遣大手スタッフサービスのCIO（最高情報責任者）を務め急成長を支えた著者が、ベンダーとユーザー両方の視点から、“システム屋”の思考回路と、上手な付き合い方を説く。 貴社は、金融危機に端を発したこの不況を乗り切るための施策として、何をお考えでしょうか？ 新たな顧客・販売チャネル開拓、低価格品の開発、間接部門のスリム化、あるいはリストラなど、様々な選択肢があるでしょう。 このような状況において、貴社の情報システムは効果を上げていますか？ 決断を下すのに当たって、顧客情報や製品・サービス情報は分析・洞察・予測を支援する形で提供されますか？ あるいは、そもそも不況が来る前、あるいは好況期において、情報シス
株式会社マジカジャパンの羽生章洋が書いてるブログ:インハウス時代のソフト会社 - livedoor Blog（ブログ）
ここ数年、OSS（オープンソースソフトウェア）関連で講演させていただくときに「インハウス（内製）が復権する時代の到来」ということをお話させて頂いてます。 このような事例があったりします。 ということは、逆に言うと弊社のようなオーダーメイドの業務システムを作っているソフトウェア会社は困ってしまうわけです。自分たちで出来るからお前らイラネ、ってことになってしまいかねません。 では、私たちは本当に無価値になってしまうのかというと、そこはまた違うと考えています。プロとして提供できる価値というものを考えていくことで、生き残っていけると考えています。逆に言うと、従来通りのままで大丈夫などと考えていると厳しい時代であるともいえます。端的に言うと、作る作業と手間に対しての対価を頂くのではない、別の収益構造を模索していく必要があるのでしょう。 そもそも作ること自体に対価をもらうのを前提とするならば、OSSな
設計書よりもユーザーマニュアルを書こう！ - レベルエンター山本大のブログ
僕が今やってる例のプロジェクト*1で、 この前、設計書を作ってお客さんに確認してもらった。 分厚い設計書で、何回も社内レビューをしてもらって、 メッセージＩＤのマッピングなど細かい点をイライラしながら直して 何度も印刷して、「最終版」、「最終版２」、「本当の最終版」という お馴染みのサブディレクトリができて、 やっとの思いでお客さんに提出したんだけど、どうやらぜんぜん見てくれてないみたいだ。 しかし、一緒に提出したユーザーマニュアルには、隅々まで目を通してくれていた。 お陰で、重要な仕様の誤解を発見することが出来た。 ユーザーマニュアルはそのままHTML化されて、 システムのHELPボタンから呼び出されるから、 お客さんとしても念入りにチェックしてくれたんだ。 ところで、設計書には大きく３つの役割がある。 ・お客さんが仕様を確認するため ・エンジニアが実装するため ・保守のため 僕は今回、
Javaにおける開発・Test（Unit/Web/負荷)環境のまとめ - よねのはてな
うちの母親でも知っているJavaにおけるオープンソースを活用した開発環境・Test環境について調査及び評価する必要があり意外と労力を要したので これからJavaでの開発において開発環境・Test環境を構築する際の参考になればとメモしておきます。 開発環境、ビルドツール、Test、Web Testing、負荷テストに重点を置いてあります。 インストールせずに使用出来るIDEのtIDEや、jythonでWebテストを記述するMaxQ、パフォーマンステストをjythonで記述するGrinder3、 Flexの負荷テストも可能なWebLOAD、Swingのテスト用のUISpec4j等、新しい発見もあったのでJava開発者の人にも参考になると嬉しいです。 それぞれライセンス、最新バージョン、個人的なお薦め度(5点満点)を合わせて明記してあります。 IDE name URL Ver. Licence
株式会社マジカジャパンの羽生章洋が書いてるブログ:適応力と競争力 - livedoor Blog（ブログ）
場所が違うと当然お客様も異なります。商習慣などもそうですがベースの価値基準も違っていたりします。例えば今まで大阪で商売してきて、それで上手くいっていたからといって全く同じやり方をして東京でも上手くいくかというと、それは断言できません。ということは、やはり現地・現場に合わせて変化していく必要があります。所謂適応力が重要になるわけです。 一方で、進出した先には当然ながら競合も存在します。単に変化するだけ・お客様に適応するだけではいけない。競合と比較されたときに負けないことが重要です。でなければ、自分たちを選んでもらえないからです。選んでもらえないのであれば、いくら変化しようと何だろうと存在価値などないのです。 適応力と競争力。会社をやっていくにおいて、強く意識しなければならないことだと考える次第です。 …余談ですが、スタロジはこの適応力の量産化を目指しています。メタなスキルなので難しいのですが
眠る開発屋blog｜最新オンラインカジノのニューカジノ情報
もしもこの世から「残業」が完全になくなったら ３年ぐらい前に読んだ本を思い出した。 １９８０−９０年代の話ですが、残業について、 「時間外・休日労働の弾力的運用が我が国の労使慣行の下で雇用維持の機能をはたしている」（１９８５年労働基準法研究会報告）とか、「我が国の労働慣行の実情に合うような上限設定が可能かどうか定かでない」（１９９２年同報告）と、雇用維持の為のコストとして恒常的な長時間労働を是認する考え方が主流でした。 需要の低下に応じて、生産水準を下げなくてはならなくなっても、バッファがあるから解雇せずに大丈夫でしょ、という。。。 まぁ、 ところが、その後、労働法政策が内部労働市場の雇用維持から外部労働市場における移動促進に徐々にシフトしていったにもかかわらず、この長時間労働哲学には疑問が呈されないまま２１世紀に至っているのです。 と著者は問題視しているわけだけど。 話変わって、最近友人
真のソフトウェア工学はもう存在している - Hello, world! - s21g
従来のソフトウェア工学が決定的に間違っている点 従来のソフトウェア工学が決定的に間違っている点は、 ソフトウェアを作るソフトウェアに関する工学ではない事だと思う。 100倍の生産性を達成するためには、ひとつ階段を上にのぼる必要がある。 従来のソフトウェアエンジニア人事工学が決定的に間違っている点 「やらなきゃいけない」仕事が20%で、残りの80%が「やりたいしごと」。たとえ単純作業でも、残り80%にそれが属しているのであれば嬉々としてやってしまう。彼らからこれを取り上げてしまうと、残り20%も小さくなってしまう。好きなようにやらせておくのが吉である。 つまらないコードを生成するコードを書く事は、 つまらないコードを書く事自体と比べて何倍も面白い。 手でコードを書くプログラマと、コードにコードを書かせるメタプログラマでは、 規模が大きな仕事になるほど差が開いていくと思う。 「ソフトウェア工学
自分たちで出来るなら、自分たちで作った方が効率いいよね - @katzchang.contexts
「下請けに出していた仕事の内製化でコスト削減」の謎 | 日経 xTECH（クロステック）より。 ソフトウェアシステム開発において下請けに仕事を発注する理由の一つとして、「専門分化されたソフトウェア技術に対する専門技術者を効率的に起用しよう」っていう言い訳があったはずだけど、フタ開けてみればそんな専門技術者なんて滅多に出会わないし、第一そんなのを必要とする案件自体が少ないというか、「属人性排除」の元に専門技術者への依存をなくして「誰でも出来る」ような開発プロセスを採用しよう！なんてのが主流になってるわけだけど。 内製で作れるなら、内製で作った方がコミュニケーションコストが激減するし、そりゃ安くできるよねと思ったんだけど、何か間違ってることってある？プログラマの質を問題にするなら、大手SIerの方がよっぽど優秀な人材がそろってるだろうし。 そう、「誰でも出来るように」と言われたら「誰でもって、
権限は要件か？ - masayang's diary
画面設計とか外部設計とか、もうやめようよにおいて 「権限」「ステータス」など、システム内部の話がでている。→明らかに実装と要件とを勘違いしている。 と書いたら「権限って要件じゃないの？」という問い合わせをいくつかいただいた。 できるだけ簡単・簡素に考えよう 例えば「水泳選手として、指定した水泳種目の記録を折れ線グラフで見ることができる」というストーリがあったとする。*1 ここで「水泳選手を特定するために認証を実装する必要がある」と考えちゃう時点で、余分なことを考えちゃっている、と言ってよい。 極端な話、マイケル・フェルプス専用の端末を用意し、彼しか入れない部屋にそれを設置すれば、認証の実装は不要なのである。 「そんなのインチキ」と思うかもしれない。 でも、実際に開発する場合には認証もへったくれもなしで実装・テストしておいて、後から権限や認証を実装するほうが、開発もテストもすっきりする...
ヒトもカネもなくともシステム内製はできる
「ヒトもカネもない中小企業でも，やればできる」---菅雄一氏は関西のある企業のたった一人のシステム担当である。従業員約200人の製造業で，ほぼ独力でネットワークを引きサーバーを立て，社内向けのグループウエアや顧客向けのQ＆A情報検索システム，販売システムなどを構築してきた。 ミドルウエアとして使っているのは，すべてオープンソース・ソフトウエア。ハードウエアの代金と回線料を除けば，費用はほぼ菅氏の人件費だけだ。 最初はエラーの連続 菅氏がシステム内製を始めたのは，2000年に同社がインターネットに接続したことがきっかけだった。この時，インテグレータから提案されたサーバーの費用は，営業所や本社のパソコンの設定変更，ファイアウオールなどを含めて100万円以上。それを見た菅氏は「10万円のパソコンにLinuxを入れればもっと安くできるのに」と思った。 菅氏は思っただけでなく，実際に行動した。自前で
パッケージインテグレーションとエコサイクル - GeekFactory
私はパッケージソリューションの企画手伝い and 開発 and 保守というお仕事をやっているので、お客様はいろんな業界に渡ります。官公庁であったり、銀行であったり、製造業であったりするわけです。得意分野のノウハウを価値として売っているため、お客様の業務内容に深く入り込むことはあまりありません。 http://d.hatena.ne.jp/int128/20090129/1233240746 昨日のエントリで上のように書いたものの、これではプロダクトを売っているように読めてしまいますね。私のところではプロダクト単体を売るのではなく、SIを行うことを前提にパッケージを売っています。基本的にはお客様の要件を実現することを優先します。 パッケージがお客様の要件を満たせない場合は、基本的には仕様の標準化を行ってパッケージに取り込みます。その仕様があまりにも特殊な場合はSI案件で個別にカスタマイズをし
株式会社マジカジャパンの羽生章洋が書いてるブログ:大雑把でもいい - livedoor Blog（ブログ）
システム化・IT化で失敗しがちなのは、これまで全くといっていいほど何も管理してこなかったのに、せっかく多額の予算を割くのだからといきなりものすごく詳細に精密に物事を管理しようとして運用が回らなくなるというケースです。 そういうとこれまた極端な話が出てきて、言わば0/1のような感じで「だったらやるだけ無駄だ」という風になってしまい現状追認で終わってしまうということも見受けられます。ですが現状のままであるということは問題はそのままなのが当然なので、それが自然に勝手に解決して欲しいと思っても、そこにはちょっと無理があるように思うのです。 いきなり精緻にやらなくてもいい。まずは大雑把でいい。出来る範囲だけでいい。始めることに意義があると考えて、実際にやることが重要だと思うのです。そして成果が出てくると、段々とやる気も高まってきます。 何も最初から無用に目標を高く設定する必要などないのです。本当に目
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
