特許庁のシステム開発が破綻した本当の理由
特許庁と東芝の新システム開発契約打ち切りについて、なぜこの開発プロジェクトが破綻したのかについて私なりの解説をしようとバックグラウンドを調べたところ、調べれば調べるほど、この問題の根底には（１）コスト意識が欠如し自分たちが「公僕」であることを忘れてしまった霞ヶ関官僚、（２）霞ヶ関から流れて来るお金にたかる IT ゼネコン、（３）そのお金の流れに対する影響力を利用して票を稼ぐ政治家、という原子力業界と全く同じような構図があることが明らかになり、ウンザリしてしまった。 破綻の原因は、ソフトウェア・アーキテクチャやプロジェクト・マネージメントにあったのではなく、「競争原理が正しく働かない社会構造」そのものにあるのだ。これではうまく行くはずがないし、たとえうまくいったとしてもやたらと高くつく。 そもそも破格だと言われた９９億円という落札価格も、私から見ればどうみても高すぎる。特許庁のシステムであれ
IT業界の「プロジェクト」は、いつから誤解されるようになったのか - ジャスミンソフト日記
私たちは主として業務アプリケーション開発という「プロジェクト」に関わる仕事をしています。ところで、このプロジェクトという言葉が持つイメージと、実際の開発現場との乖離に悩まされることも少なくありません。ここで、私の考え方を整理しておこうと思います。 「プロジェクト」とは、やったことがない、新しい業務のこと やり方がすでにわかっていて、マニュアル化されていればプロジェクトとは呼びません。 なぜ、そういう自明のことをあえて持ち出したかといえば、新しい業務は誰も経験したことがない分、「リスク」を伴うからです。 このリスクを誰が負担するかといえば、それはプロジェクトの成功によって恩恵を受ける側です。業務アプリケーション開発分野でいえば、それは発注者であるユーザー企業です。 しかし実際には、このリスクをゼロにしようという力学が働いています。それが「一括請負契約」であり、その実体は「丸投げ」です。 この
進捗管理が苦手な人におすすめしたい厳選フリーソフト・ツール - NAVER まとめ
サービス終了のお知らせ NAVERまとめは2020年9月30日をもちましてサービス終了いたしました。 約11年間、NAVERまとめをご利用・ご愛顧いただき誠にありがとうございました。
Redmine(or Trac or yet another ITS)でスケジュールを管理するのは有効か？ - こくぼ＠Everything is the experience.
有効ではないと思ってます。 〜 これが正解だとは思ってませんが以下、個人的に思ってることを書きます 〜 Redmineでは標準でガントチャート機能があってチケットの開始日、終了日にあわせてチャートを作ってくれます。初めてRedmineを見る人は、「これを使えば進捗管理ができるんじゃないか？」と思うことでしょう。ぼくも思ってた時期がありました*1。 しかし、実際にチケットをWBSみたいに運用するのはそれなりの労力を求められます。 なぜでしょうか。 スケジュールに変更が起こった時のメンテナンスコストが高い 開始日、終了日を簡単に変えられるUIではない メンテナンスに時間を取られることももちろんですが、日付を変える作業のめんどくささが半端なくてRedmineを使うのが精神的苦痛になります*2。個人的にはMS ProjectのUIでも満足できていません。(使いこなしてないだけなのかもしれませんけど
規模の大きなプロジェクトで使いたいプロジェクト管理·NavalPlan MOONGIFT
NavalPlanはエンタープライズクラスに向いたのJava製のプロジェクト管理システム。 NavalPlanはJava製/Webベースのオープンソース・ソフトウェア。企業規模によってプロジェクト管理に求めるものは変わってくる。小規模な組織であれば個人の裁量が大きく、コミュニケーションも活発なのでWeb上でまとめる情報はそれほど多くなくても良いかも知れない。 ガントチャート しかし何百人とプロジェクトに関わる人が増えてくるとそうも言っていられない。適切に管理を進めなければいざという時に大変なことになってしまう。そこで使えるのは大規模プロジェクト向けのNavalPlanだ。 NavalPlanはガントチャートが基本になるプロジェクト管理だ。WebベースなのでWebブラウザさえあれば誰でも見られるのが利点だ。一つのプロジェクトだけでなく、複数のプロジェクトを全体的に見ることができる。各人員のリ
詳説！Redmineを使ったスマートな開発プロセス改善（画面キャプチャ付き）
最近は、課題管理システム、チケット管理システムがメジャーになっており、私もこの種のツールをサービス開発、ソフトウェア開発で利用し、開発プロセス改善を試みています。 今回は、Shibuya.trac第12回勉強会 ～チケット管理システム大決戦 第二弾～で紹介させていただいた、Redmine利用事例の詳細解説を、共有させていただこうと思います。上記、勉強会の資料は、こちらに公開されています。各種ツールの事例が詰まった内容ですので、ぜひご確認ください。 Redmineのプロジェクト画面 上記が自社のRedmineのプロジェクト画面です。私のチームは「A-Team」といい、すべての作業は「A-Team」プロジェクトで管理しています。トップページには、勤怠の連絡や、Redmineを利用するときのルールなどがまとめてあり、資料を見ていただければわかると思いますが、プロジェクトメニューにはたくさんのモジ
見えてきた危機対応での「やってはいけない」
プロジェクトで危機的な状況に直面したとき、やってはいけないことが少なからずある。日経SYSTEMS5月号（4月26日発行）の特集記事「プロジェクトの危機 その時どうする」の取材では、このように感じる指摘を、ベテランのプロジェクトマネジャー（PM）から受けることができた。 特集記事で取り上げた危機的な状況には、「震災の影響によってプロジェクトが進められない」といったものに加えて、コストオーバーや納期遅延、品質の低下というものを含む。このとき、どのように対応すればよいかを、「人が足りない」「時間がない」「タスクが山積み」といった状況ごとに紹介している。 記者はこの特集の事例取材で、コストオーバーや納期遅れ、品質の低下といった危機的状況での対応を、主に担当した。これらの危機的な状況は、PMやリーダーが「順調に進んでいる」と思っている中で、急に判明することが少なくない。このとき、プロジェクトはかな
スクラム提唱者から学ぶ、チームの不幸を減らすたった2つの方法
スクラム提唱者から学ぶ、チームの不幸を減らすたった2つの方法：スクラム提唱者が教える、チームの不幸を減らす方法（1/2 ページ） スクラム提唱者のジェフ･サザーランド氏を講師に招いた、日本初の「スクラムアライアンス認定プロダクトオーナー研修 レポート」レポート。チームも顧客も不幸な状態をなくす方法は実にシンプルだ。 2011年はアジャイル実践者にとって歴史的な年となった デスマーチ続きでリリースは遅延、チームはプレッシャーを受けてマネージャはてんてこ舞い、顧客も不幸……そんな状態を良い方向に転換する方法はたった2つである――「スクラム」提唱者の1人である、ジェフ・サザーランド氏の言葉です。 1月11日と12日、サザーランド氏による日本初のスクラムアライアンス認定プロダクトオーナー研修（Certified Scrum Product Owner 研修、以下CSPO研修）が開催されました。翌日
［姿勢・資質編］プロジェクトにおけるPMの存在意義を忘れてはいけない
「PMの存在意義って、いったい何だろう？」――。システム開発プロジェクトにおけるPM（プロジェクトマネジャー）の存在意義について考えたことがあるだろうか。多くのPMは自問自答しながら成長するといえばそれまでなのだが、どこかで一度は「PMの存在意義」について確認し、頭の中で整理しておいたほうがよい。 プロジェクトにおけるPMの存在意義を突き詰めるには、PMの役割から考えてみる必要がある。PMの役割を文字通りに理解すれば、プロジェクトをマネジメントする人になる。ではプロジェクトをマネジメントするとはどういうことだろうか。これについてPMBOKでは次のように紹介している。 ・要求事項を特定すること ・明確で達成可能な目標を確立すること ・品質、スコープ、タイム、コストなど、競合する要求のバランスを取ること ・各種ステークホルダーの異なる関心と期待に対して、仕様、計画、取り組み方法を適応させること
目的と目標を混同するな
あなたは、自分が参加しているプロジェクトの目的や目標を意識しているだろうか。また、目的と目標の違いを、きちんと理解しているだろうか―。 多くの人はこう聞かれて、明確に答えるのが難しいだろう。なぜなら、「目的」と「目標」という言葉の定義は非常にあいまいであり、プロジェクト内で共有できていないことが多いからだ。しかし、目的と目標という言葉の意味は、全く違うものである。そして、それらはともに、プロジェクト内で具体的に設定する必要がある。そうしないと、プロジェクトは混乱し、やがて頓挫する。今回は、「目的と目標を混同するな」というルールについて紹介しよう。 1W1Hを「目的」で「目標」で4W 筆者もかつて、目的と目標を混同していた1人である。それを当時の上司から指摘され、その本質に気付かされた。目的と目標は辞書を引くと、ともに「目当て」や「目指す所」と書かれている。だが、本質的には大きな違いがある。
アジャイル開発 基本のキ - ヲトナ.backtrace
今、アジャイルの導入のお手伝いをさせてもらっている現場で「他のスタッフにもアジャイルについてざっくり教えてよ」というオーダーで勉強会をやりました。 そこで「アジャイル開発 基本のキ」と題し、実際の進め方の説明ではなく、その手前の考え方や心構えにフォーカスして話をしました。 20名ほどの人数向けに作った資料なのですが、普段アジャイルについてのイントロダクションの話をする時にいれるキーワードは大体盛り込んだ感じになったので、もしかすると誰かの役に立つかもしれないので公開しておきます。 ただし、勉強会のターゲットがエンジニアではなかったので、エンジニアリングについては薄くなっているのでご注意を。 Basic of Basics of Agile DevelopmentView more presentations from Nishimura Naoto. あと、話は変わりますが、普段アジャイル
2009-08-16
情報セキュリティ入門 | 日経 xTECH（クロステック） 会社の人に教えてもらったセキュリティの入門ページ。昼休みに読もうかな。 チーム開発継続中…。これが本当のサマーウォーズだ、というワケのわからないセリフがまわりで流行っています。夏休みはありませんがワタシは元気です。あいかわらず、一応、リーダー係です。 お盆の間に学んだことをメモ。 業務遂行に学習が必要なら、そのための工数を確保すること 顧客から「今のやり方じゃなくて、他の効率よいやり方調べてさー、ちゃっちゃと片づけちゃってよ」なんて軽〜くいわれたら、殴る…じゃなくて、調べるための時間をもらう。 顧客に言われるがままに担当者に振らない。もとの工数に収まるように、調査をしつつ作業もしろというのは無茶だし、担当者も嫌がる。 担当者は、調査や勉強をしたくないわけではない。むしろ、業務の中でスキルアップしたいと願っている人が多い。ただ、本来
案件ふりかえり - logiqboard
とある案件が終わった。相変わらずきっつい納期だったうえに、全メンバー片手間の情況でよくやれたなと自画自賛していいと思う。 ふりかえりをツイートしたら清水川大明神先生様に「それブログで」って言われたので、すこし整理してみた。 テスト テストを書く習慣が付いたのはつい数ヶ月前のことなのだが、この案件ではテストが非常に役立った。 もともとFlashゲームのバックエンドAPIサーバーを作る仕事だったのでサーバー側のテストがしやすいというのもあったが、初期からテストのしやすさを意識して書いた。 マイルストーン期日が押していても１機能に対して最低ひとつ、想定通りの値で想定通りの結果が返ることを確認するテストを書いた。 それだけでも下らないバグは十分に防げた。 目標設定 テストの数が50を越えた頃から、100テストを目標にしていた。 カバレッジとかは一切計算していないし、100という数字にも何の根拠もな
［品質編］かけがえのない人を作ってはいけない
どんなプロジェクトであれ、人が集まって何か事をなそうとする場合、多かれ少なかれ「2：8（にはち）の法則」が成り立つ。2：8の法則とは「利益の80％は、わずか20％のリソースによって生み出される」という一種の経験則である。 リチャード・コッチ氏（『人生を変える80対20の法則』の著者）に言わせれば、「10人の開発プロジェクトがあれば、わずか2人で全体量の80％を開発している」となる。少し言い過ぎのように思えるが、当たっている気がすると思うプロジェクトマネジャー（PM）は少なくないだろう。 この2：8の法則の「2」に該当する優秀な技術者の中で、さらに「かけがえのない人」を作ってしまうと、時としてプロジェクトの破綻を招いてしまうことがある。 ITに詳しい利用部門Aさんのケース 利用部門のAさんはIT部門出身だったので、業務もITも分かる「かけがえのない人」になった。その結果、プロジェクトはカット
プロジェクト推進者のための議事録の書き方 - 人と組織と、fukui's blog
2011年02月07日 02:53 カテゴリプロジェクトデザイン プロジェクト推進者のための議事録の書き方 Posted by fukuidayo Tweet プロジェクトを設計（デザイン）し、前に進める。という仕事に取り組み始めてから、ありがたい事に多くの仕事の相談や依頼を受けるようになった。やってみて感じるのは、企画するだけでなくて、ものごとを確実に前に進めてくれる人をどこの企業も求めているんだなー、ということ。 プロジェクトを設計し、前に進める。というと大層なことをやっているように思えるかもしれないけれど、実は僕がやっていることは本当に単純で、 ・アジェンダをつくり ・会議をファシリテートし ・議事録を作成する ということをしているだけだ。もちろんプロジェクトを円滑に進めるために必要であれば、情報共有やプロジェクト推進のツールを提供したりもするけれど、基本的には無料で利用でき、汎用性
PART2 進捗遅れを防ぐマネジメント
進捗遅れを防ぐには、チーム全員で危機感を共有し、遅れをいち早く見つけ、課題を確実に解消していくことが重要だ。この一連のマネジメントサイクルを回すにはどうすればよいのか。進捗遅れ対策で成果を上げている現場の工夫を紹介する。 進捗遅れを防ぐ上で、プロジェクトマネジャーが果たすべき役割は大きい。たとえ優秀なメンバーが集まったとしても、マネジメント不在では、進捗遅れを防ぐのは難しいだろう。メンバーがじっくり丁寧にタスクを行えば、それによって進捗遅れが発生しかねないからである。 そこでプロジェクトマネジャーにはチーム内で進捗遅れに対する危機感を共有し、適度な緊張感・プレッシャーを生み出すことが求められる。それでも、進捗遅れは必ず起こるものである。プロジェクトマネジャーは日ごろからメンバーの様子に目を光らせ、定例会での進捗報告を待つことなく、いち早く遅れを見つけ出したい。その上で、進捗遅れの原因となる
［覆面座談会］はびこる失敗アジャイル
アジャイルの適用が進む一方、失敗プロジェクトが増えている。アジャイル開発の経験が豊富な3人に、現場の様子を語ってもらった。いったいどんな失敗が起きているのか。（聞き手は日経SYSTEMS記者、池上俊也） 記者：最近、業務システムの開発にアジャイルを適用する事例が増えてきました。アジャイル開発の経験が豊富な皆さんは、こうした状況をどのようにご覧になりますか。 Aさん：以前は若い開発者が中心となって、Webシステムの開発でアジャイルを採用するケースが多かったと思います。しかし最近は、ちょっと違う。開発会社のトップや、ユーザー企業の担当者がアジャイル開発の採用を求め、トップダウン的に取り組むケースが多いようです。それもこれまでウォーターフォール型を適用していた業務システムのプロジェクトに適用する事例が目立ちます。 Bさん：より速く、より安くシステムを開発する手法として、アジャイルが広く認知された
現場の成功テクニック［コミュニケーション編、マネジメント編］
今回は、コミュニケーションとマネジメントに関する現場の成功テクニックを見ていく。また、記事の最後には、アジャイル常識度テストを掲載したので、ぜひ挑戦してみてほしい。 コミュニケーション編：座席を一変、昼会・夕会で補う メンバー同士がギクシャクする、ユーザーの協力を得られない、必要な情報を共有できない──。コミュニケーションの失敗は、こんな具合に表れる。もちろんウォーターフォール型でも見られることだが、報告や連絡、相談のほとんどを対面で行うアジャイルは、こうした失敗が発生しやすい。 座席レイアウト一つで円滑に クラウドサービスの開発でアジャイルを適用するユーフィットの林 伸哉氏（ソリューションビジネス事業部 ソリューション企画部 ナレジオン推進室 室長）は、メンバー間のコミュニケーションを円滑にしたいと考えていた。当時、各メンバーは向かい合わせに座っていたが、隣の人としか会話をしない。テスタ
［作業指示、進ちょく管理編］気付いたときにはもう遅い、手戻り・遅延は起こさない
今回は、「バッファー込みで作業をさせてはいけない」「報告を待ってはいけない」など、「作業指示」と「進ちょく管理」という2つの場面における、7種類の禁じ手を解説しよう。 作業指示：バッファー込みで作業をさせてはいけない PMはスケジュールを見積もるとき、問題が起こった場合などに備えて、作業や工程ごとに遅延を見込んだ「バッファー」を確保しておく。そしてそのスケジュールをユーザーと合意した上で、プロジェクトを進めていくことになる。 このときPMがやりがちなのは、バッファー込みのスケジュールを、バッファーが含まれていることを伝えないままチームリーダーやメンバーに示して、作業指示をしてしまうことだ。みずほ情報総研の百井氏は「PMが忙しいときは特に、ユーザーに見せたスケジュール表を、そのまま示しがちだ」という。 しかし、バッファー込みのスケジュールで、リーダーやメンバーに作業をさせてはいけない。「作業
複数人(2-3人)でウェブサービスを開発するコツ - リート開発者ブログ
こんにちは。開発ブログ言いだしっぺの satoshi です。リートでは、AddClips と Lancers というサービスが現在の主力サービスですが、AddClips は1人のエンジニアが担当し、Lancers は2-3人 のエンジニアが開発を担当しています。 当たり前ですが、1人と3人では開発スタイルが大きく異なり、気をつけるポイントも全く違います。当たり前の事が多いのですが、リートで特に気をつけていることをご紹介できればと思います。 開発環境 VMware ESXi を使って開発環境は5秒で用意する 通常、VMwareはLinuxやWindows上で動作しますが、VMware ESXi はその上で直接、複数のVmware（仮想化マシン）を立ち上げることができます。 Vmwareを導入するために、Linuxを導入したりする必要はなく、その容量も32MBとコンパクト。しかも無償で利用可能
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
