日経BP株式会社 日経BP 〒105-8308 東京都港区虎ノ門4丁目3番12号 →GoogleMapでみる ＜最寄り駅＞ 東京メトロ日比谷線「神谷町駅」4b出口より徒歩5分 東京メトロ南北線 「六本木一丁目駅」泉ガーデン出口より徒歩7分
金融大地震に世界がやるべきこと、日本ができること（１） / SAFETY JAPAN [大前 研一氏] / 日経BP社
第158回 金融大地震に世界がやるべきこと、日本ができること（１） 経営コンサルタント 大前 研一氏 2009年1月7日 わたしは全国の経営者を対象にした「向研会」という勉強会を主宰している。この会ではもう10年以上にわたって毎月一回、経営の世界で起こっていることに関してテーマを決めてわたしが話をするのだが、毎年12月はその年の経済・経営を振り返りながら来年の世界の経済状況の見通しを述べるのが習わしだ。わたしなりの分析を提供し、もって皆さんの経営のお役に立てていただこう、という狙いである。自分で言うのも口はばったいが、これはメンバーには大変な好評をもって迎えられている。 今回（昨年12月）の勉強会を準備するにあたっては、わたしもいささか頭を抱える仕儀となった。なにしろ「見通す」ことが難しいのである。理由は言うまでもない、例の世界的金融危機だ。昨年９月以降のダウ工業株30種平均株価の推移
チケット駆動開発の本質はバージョン・ファースト - プログラマの思索
チケット駆動開発(TiDD)について考えていることを書く。 ※注意：チケット駆動開発(Ticket Driven Develpment)の略語は、「TDD」だとテスト駆動開発(Test Driven Develpment)と間違えやすいので、「TiDD」と以降呼ぶことにする。(命名者：えと～さん) 【元ネタ】 チケット駆動開発は、まちゅさんによって提唱されている。 チケット駆動開発 … ITpro Challenge のライトニングトーク (4) 【1】チケット駆動開発のプラクティス チケット駆動開発は定義そのものがあやふやなのだが、僕は下記4個ののプラクティスがあると思う。 ※注意・下記のプラクティスはあくまでも僕個人の考えであることを断っておく。 【1-1】チケット・ファースト(Ticket First) プロジェクト内部の作業は、チケットを受け取ってから始まる。 つまり、工数が発生す
元請SIerがTracのような環境を提供できない３つの理由 - なからなLife
セキュアに公開されたソース管理システムと課題管理システム、つまりhttps接続のcvs/subversionとtrac/redmineを用意してほしい。 （略） 全てのプロジェクトメンバは計画と設計情報に対するアクセス手段を確保すべきだ。 元請け企業が用意すべきもの - @katzchang.contexts 激しく同意。 ツールの種類はともあれ、この手の情報は、 1箇所に集中 版の管理 セキュアなアクセス 誰でも参照できる を実現することよって、関係するすべての人にとって、作業負荷の軽減に寄与するものですから、さっさとやりましょうよ。 導入、周知、初期学習コストだけじゃん。 導入コストなんて、環境構築手順を確立して、場合によっては自動構築スクリプト化すればさくっと終わる話。 導入ノウハウなんて、みなさんいろんなところで公開してくれているわけだし。 初期学習コストなんて、初めて触る人だけの
ふりかえりを実践してみて - プログラマの思索
Redmineでチケット駆動開発を運用し始めてから、自然にふりかえりを取り入れることが多くなった。 ふりかえりでは、KPTという思考フレームワークを使うことが多い。 このKPTという手法で、開発チームと開発プロセスを大きく改善できた経験をしたので、振り返ってみる。 ＃ラフなメモ書き。後でまとめる。 【元ネタ】 初めてのプロジェクトリーダー（6） 「ふりかえり」でプロジェクトを改善する オブジェクト倶楽部の「プロジェクトファシリテーション 実践編 ふりかえりガイド」 【1】ふりかえりが無いチームは成長しない 成果物の品質が悪く、納期がズルズルと遅れる開発チームでは、同じ失敗を何度も繰り返す症状が多いだろう。 例えば、デグレ。 デグレが何度も起きると、その成果物そのものの信頼性が損なわれ、最終的には人間関係の信頼まで壊れてしまう。 そんな症状を見ると、駄目なチームはフィードバックプロセスが無い
Redmineを使って気づいたことpart3～チケット分割のタイミング - プログラマの思索
Redmineを運用して気づいたことを書いてみる。 【元ネタ】 Martin Fowler's Bliki in Japanese - 支払利息の見積もり PERFORCE ソフトウェア構成管理の高度な実践方法（ベストプラクティス） 【1】登録したチケットを分割するタイミングがある。 WBSから初期スケジュールを作成した時、機能追加だけの実装内容のチケットの工数は3人日を見積もったとする。 しかし、実際にチケットを担当した開発者の実績は5人日をオーバーする時がある。 何故遅延しているのか、開発者に聞いてみると、機能追加する前のリファクタリングに時間がかかっている。 理由は、元々のソースはロジックが余りにも入り組んでいるため、リファクタリングしないと機能追加できないから、と言う。 そんな時、僕は、そのチケットからリファクタリングだけの目的の別チケットを新規登録し、リファクタリングは別チケット
【公開】KOF2008講演資料「Redmineでチケット駆動開発を実践する～チケットに分割して統治せよ」 - プログラマの思索
関西Ruby会議01＠関西-KOF2008講演資料「Redmineでチケット駆動開発を実践する～チケットに分割して統治せよ」を公開します。 CC Attribution ライセンスとします。 【元ネタ】 チケット駆動開発 … ITpro Challenge のライトニングトーク (4) - まちゅダイアリー(2007-09-07) チケット駆動開発は、まちゅさんが最初に提唱された。 しかし、チケット駆動開発の概念はまだ曖昧で、一部でしか注目されていない。 僕は、Redmineというプロジェクト管理機能を持つBTSがプロジェクト管理をIT化してくれて、プロジェクト運営が大きく変わったことを経験した。 その体験をチケット駆動開発(Ticket Driven Development)という概念へ昇華できないか、考えた内容が上記の資料です。 コメントがあれば嬉しいです。 【参考】 Rubyist
複雑度と単体テストケース数の相関関係 - プログラマの思索
garyoさんから、ソースの複雑度と単体テストケース数について有益なアドバイスを示唆してもらったので、メモしておく。 ◆SourceMonitor Version 2.4 SourceMonitorはフリーで、以下の言語のソースのソフトウェア複雑度（McCabeのサイクロマチック数）を測定できる。 例：C++, C, C#, VB.NET, Java, Delphi, Visual Basic (VB6) or HTML ◆McCabe's cyclomatic complexity SourceMonitorで求められる複雑度（McCabeのサイクロマチック数）は、モジュール内の分岐の数（＋ループの数）で計算される。 複雑度の数値は、下記の意味を持つらしい。 10 以下であればよい構造 30 を越える場合，構造に疑問 50 を越える場合，テストが不可能 75 を越える場合，いかなる変更も
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
循環的複雑度