危機に瀕するIT業界の「モラル」
「いやぁ，以前と全く変わってないですね。むしろ悪くなっているんじゃないですか」。独立系コンサルタントのA氏に「ITエンジニアやプロジェクト・マネジャ，営業担当者などITプロフェッショナルのモラル（責任感や倫理観）はいま，どのような状況にあると思うか」を尋ねたところ，A氏は記者にこう答えた。 A氏は，銀行の情報システム部門に10数年にわたり在籍した後に独立。現在は，企業の大小を問わず情報化のコンサルティングに全国を飛び回っている。 取材の場では，日経コンピュータが2001年4月に掲載した「IT業界のモラルハザード」と題した特集に，まず目を通してもらった。IT業界におけるモラルの崩壊ぶりをレポートしたものだ。その上で，A氏に現状についての感想を聞いたところ，出てきたのが冒頭のコメントである。 A氏は，こう続ける。「最近では，ユーザー企業のシステム子会社にモラル欠如の例を見ることが多いですね。親
それでも開発は続くよ（人月見積は正しい）
前回、前々回と少しづつ見積に触れてきた。 そこで、人月見積の正しさについて少し話しておこうと思う。 一般的には、ファンクションポイント、ＦＰ法が正確であるということになっているが、現実は違う。 ＦＰ法の元は、これこれの作業をこのスキルの人間にやらせると標準値として、、、である。現場には「このスキルの人」はいない。このレベルの人、は測れない。 無い袖は振れない現場 現場にはスーパーマンが現れることはない。 持ち駒の全てで勝負するしかない。どこかにいる、スーパーＳＥを当てにしたＷＢＳなど書けはしないのだ。今のスキルを総合してＷＢＳに落とす。 それしかできないのである。 いかに数値的に正しい見積でも、現場の開発見積では有り得ない。 そもそも開発するためのファンクションを導き出したときの現場スキルが、期間となってくるのは自明の理だ。 前回の話だと、次にリリースできたとしても３ヶ月後、これには全ての
IT失敗学の研究
2つの意味でたいへんタメになった。ひとつめは、破綻プロジェクト事例集として。ふたつめは、「くれない君」の言い訳の反面教師として。 「動かないコンピュータ」と不条理プロジェクト 日経コンピュータの「動かないコンピュータ」なら比較的単純なストーリーだ。さまざまな要因で初期の目的を達成できなかったプロジェクトだからだ。予期しない不具合や無謀な計画が原因なのだが、通常これらは事態を収拾するための「火消し」が続き、なんらかのエンディングがある。『IT失敗学の研究』は違う。曰く「最初から動かす気がなかったし、動くはずもなかった」「どうみても計画に合理性がなかった」「危ない危ないと思っているうちに破局を迎えた」…といった不条理プロジェクト集だからだ。 したがって、「動かないコンピュータ」というエンディングすら迎えない。どう見ても不可能なのに、予算がつくからとムリに存続させるプロジェクトや、検収・納品→動
現場の叫びで分かった嫌われるプロマネの正体 － ＠IT自分戦略研究所
プロジェクトをマネジメントするどころか、メンバーを地獄に陥れるようなプロマネの正体を暴く。現場の悲痛な叫びはプロマネに届いているだろうか。（Tech総研／リクルートの記事を再編集して掲載） 複雑化・高度化した現代の技術。1人のエンジニアが、1つの案件を仕上げることができるケースなどほとんどない。そこで重要になってくるのが、メンバーを率い、プロジェクトをまとめ上げるプロジェクトマネージャ（プロマネ）の力量だ。しかし……。 Tech総研が、主にIT分野のエンジニア100人に行ったアンケート調査によれば、これまでにプロマネの下でスムーズに進めることができたプロジェクトは5割に満たないと答えたエンジニアが、何と88％にも上っている（図1）。しかも、そのうち79％が、別のプロマネであればうまくいったはずと答えているのである（図2）。
わたしが知らないスゴ本は、きっとあなたが読んでいる: ウォーターフォールはこう使え（その1）
ウォーターフォール・モデル悪玉論が幅を利かせている。一方でスパイラル・モデルやアジャイル・モデルがもてはやされている、銀の弾丸のごとく。 曰く、 この無駄な成果物を作らされているのはウォーターフォールだから あいまいな仕様と理不尽な要求に振り回されているのはウォーターフォールだから スケジュール後半になって追い立てられるのはウォーターフォールだから いつまでたっても品質が向上しないのはウォーターフォールだから 赤字プロジェクトが垂れ流されているのはウォーターフォールだから このプロジェクトがデスマってるのはウォーターフォールだから 偉大な（?）グルの尻馬に乗って叩く。まるでウォーターフォールという軛がボクの創造性と可能性をことごとくダメにしていると言わんばかりに。何かに責任転嫁して考えを止めるのは楽だけど、その「何か」が真の原因で無い限り、解決にはならない。 仕事ができないのは道具が悪いと
[を] スクラム(scrum)という言葉を聞き及んだのでメモ
スクラム(scrum)という言葉を聞き及んだのでメモ 2006-02-14-4 [仕事] はてなダイアリー - スクラムとは <http://d.hatena.ne.jp/keyword/%a5%b9%a5%af%a5%e9%a5%e0> アジャイル開発手法の一つ。[...] プロジェクト管理が弱いとされるeXtreme Programming (XP)を補完される 形で併用されることが多い。 主なプラクティスは - スプリント：30日間のイテレーション - 日次スクラム：毎朝行う15分程度のミーティング - プロダクトバックログ：優先順位付けされた製品の仕掛かりリスト - スプリントバックログ：スプリント中に行う仕掛かりリスト なるほど！ そもそもどういう位置づけのものなのか、が分かった！ Technologic Arts Incorporated--推進技術
自己組織化プロジェクトの育て方（1） ― ＠IT
混乱するプロジェクトを1から10までガチガチに管理するのではなく、うまくいくようにそっと手を貸してやること。そんな発想の転換が実はいまどきのプロジェクトを上手に運営するコツなのかもしれない。本連載では「自己組織化」という概念をプロジェクト運営に応用するノウハウをお伝えする。（＠IT編集部） 1. プロローグ～大火事プロジェクトの火消し役が計画した、あるひそかな実験 昨年、火が付いたプロジェクトに火消しマネージャとして参画することになりました。チームメンバーは連日の徹夜で疲弊し切っていました。マネージャ陣との信頼関係すら怪しい状況でした。クライアントからは怒声が飛び、連日のように詳細な進ちょく状況報告を求められます。報告作業自体が開発スケジュールを圧迫していました。データベースのテーブル定義でもめている段階なのにもかかわらず、カットオーバー予定日は目前に迫っていました。タフな判断と徹夜の作業
アリの生態にみる自己組織化のルール ― ＠IT情報マネジメント
働きアリが巣を作って餌を集め、その巣の中心には働きアリを産んでいる女王アリが鎮座している……。長い間、女王アリによる中央コントロールがアリの集団を支配していると考えられてきたが、実情はことなる。女王アリは命令なんかまったくしないのである。 第1回のまとめ：自己組織化を促すために 前回「プロジェクトを管理しないという発想」の内容のまとめから始めましょう。 『システム開発が複雑で変化が激しいものになっている』ということの真の意味は何か？ 現在のプロジェクトの問題点である『複雑さ』とは、プロジェクトを構成する『もの』＝『粒』が増えたことによる、粒同士の関係、ネットワークの爆発にある。 昔のプロジェクトと現在のプロジェクトを比較し、現在は、プロジェクトを構成するものの数が増えていることで、関係性＝ネットワークの複雑さが爆発的に増えていることを示しました。 自己組織化を目指す解決案 プロジェクトを、
KPT法
ここまでの連載でも何回か触れていたのですが、プロジェクトの運営には、「より良く・より使える」方式への改善が重要です。今回は、さまざまな場面で改善を行うのに有効な、「ふりかえり」の実践です。最近メジャーになってきた感のあるKPT法の使い方、バリエーションについて主に説明していきます。 KPT法とは KPTは、それぞれKeep、Problem、Tryの頭文字で、それまでの活動を、それぞれ、良かったので次もやりたいこと（Keep）、問題だったので次はやめたいこと（Problem）、次にやってみたいこと（Try）の3つの軸で整理する方法です。 この方式の主な特徴は、 シンプルで分かりやすく、理解しやすいこと アナログ的で親しみやすく、参加しやすいこと 「見える化」されているので、外部の人でも状況が分かりやすいこと なところが挙げられます。そのせいか、参加者の「食いつき」が良いようで、次々と利用者が
アジャイルな引継ぎ - babie, you're my home
アジャイル + 運用で漂っていたら出てきました。「内製フレームワーク - LazyLoadLife」にも関連。 少量高品質なドキュメント 私の言う SYNOPSIS、ジョエルの言う big picture、だけじゃ足りないけど、あればいいってもんじゃない。ドキュメントは大量にあったら読まれない。 必要になってから読むけど。そして肝心なことが書いてなくてガッカリするけど。結局ソース読むけど。 あ、ドキュメントよりソース読むのが先かも知れない。んで、矛盾してたら主(ぬし)にどっちか正しいか聞くの。 サポート／保守チームを開発チームと一緒に働かせる 引継ぎは未だに徒弟制度だなぁ。良い方法に思えるが、もうちょっと考えたい。 私的には、開発チームがそのまま運用チームにスライドすればベストだと思うが、イヤーンな人が多いだろうな。どうよ？運用やってみない？スリリングだぜ？ドッグフードの皿の味も乙なもんだ
正しいことをし、行動力を発揮するココロ － ＠IT自分戦略研究所
将来に不安を感じないITエンジニアはいない。新しいハードウェアやソフトウェア、開発方法論、さらには管理職になるときなど――。さまざまな場面でエンジニアは悩む。それらに対して誰にも当てはまる絶対的な解はないかもしれない。本連載では、あるプロジェクトマネージャ個人の視点＝“私点”からそれらの悩みの背後にあるものに迫り、ＩＴエンジニアを続けるうえでのヒントや参考になればと願っている。 ■リーダーシップトライアングルの中心は「ココロ」 前回の「ソフトウェアは目に見えない」で、リーダーシップトライアングルの構成要素の「Vision」（ビジョン）／「Management」（マネジメント）について説明しました。今回の記事では予定どおり、リーダーシップトライアングルの中心をなす構成要素、「Love」（ココロ）を解説します。 リーダーシップトライアングルでは、リーダーシップの基礎であるコミュニケーションの上
＠IT：ソフトウェア開発をちゃんと考える（2） 開発者の集合はどのように形作られているか
ソフトウェア開発の効率性を考えていると、いつかは必ず人の問題に突き当たる。プロジェクトチームという開発者の集合はどのように形作られ、どのように動いていくものなのだろうか。そこには必ず何らかの機構（メカニズム）があるはずだ。（＠IT編集部） アーキテクチャといえば、普通はプロダクトの、あるいはソフトウェアのアーキテクチャを思い浮かべるわけだけれど、システムやソフトウェアを作っていく過程ではプロジェクトのアーキテクチャ、つまり開発に主体的にかかわっている人たちの集合がどのように形作られるかも、とても重要な要素になる。 なんでこんなことをいい始めたかというと、たまたま「フューチャー・オブ・ワーク」を読んだからなのだ。なんで、こんな本を読んだかというと、 著者のマローンは米マサチューセッツ工科大学で「The MIT Process Handbook Project」［注］というプロジェクトをやって
JavaScriptで読み込むCSSファイルをまるっと[7korobi8oki.com]
代表中山陽平 ブログ「苦手意識を無くせばWeb活用はうまくいく」弊社では「がんばる中小企業」のWeb活用をサポートしています。今の時代、第3者である、制作会社や代理店におまかせでは勝てません。同じような商品・サービスが溢れる中、選んでもらうためのコンセプトを立て、それを実現するためにネットもリアルも総動員しながら戦う必要があります。 みなさんが世の中に・自社の従業員に実現したい幸せや提供価値を、しっかりと実現していくためには、みなさん自身が主役になり、私達のような専門会社が側面支援するのがベストです。 このブログでは御社が中心となってウェブ活用できるヒントを配信しています。お悩みの方はお気軽に問い合わせフォームからご相談ください。 最新の記事一覧
![JavaScriptで読み込むCSSファイルをまるっと[7korobi8oki.com]](https://cdn-ak-scissors.b.st-hatena.com/image/square/e43158a9b02ff4438d55128491865b833395bd4d/height=288;version=1;width=512/https%3A%2F%2Froundup-inc.co.jp%2Fwp-content%2Fuploads%2F2019%2F09%2F9106fa4d7b0fdf2534aa97dea102e186.png)
プロジェクト・ファシリテーション－ファシリテータ型リーダの資質：An Agile Way：オルタナティブ・ブログ
プロジェクトの場作り（ファシリテーション）を行い、チームメンバーの能力を１００％以上発揮させ、１＋１を２以上にする、新しい形のリーダーシップが必要だ。そのたの人材像について、考えている。株式会社ITイノベーションに伺ったとき、Harvard Business Review をパラパラと見ていたら、こんな文章が！ 人々に学び 人々と一緒に計画し 人々が持っているもので始め 人々が知っていることの上に築きなさい。 リーダーが真に優れていれば、 終わってみると 人々は口々にこういう 「自分たちの力でやり遂げた」と。 －老子 うーん、まさに、これが理想だ。。。 ITイノベーションの林衛さんには、前回のオブジェクト倶楽部で主賓講演を頂きました。今回は、「ザ・プロジェクトマネジャーズ」のインタビューを私が受けました。 http://topic.promane.com/iti/dtdisp.asp?en
朝会を15分で終わらせるには理由がある
前回（第2回 「なにはともあれ、まずはチームビルディング」）はチームの基本的な作り方を解説しました。今回のテーマはチームの運営に不可欠な「会議」の上手な行い方です。 会議・会議・会議 プロジェクトにかかわる以上、会議は避けて通れません。特にリーダーなら、なおさらです。いままでは、どこかしら「関係ないや」と感じていた会議にも参加しなくてはいけません。会議にも大小さまざまありますが、今回はその中から、「朝会」「進捗（しんちょく）会」を取り上げて、それぞれの運営のコツをお話しします。 ・朝会 まずは小さな会議代表として、朝会です。朝会は、チームの状況をチーム内部で素早く共有することを目的とした、非常に短時間の会議です。最近何かと話題の朝会ですが、その理由として、「手軽に、すぐに始められる」「効果が見えやすい」「ソフトウェア開発チーム以外にも有効」などがあるでしょう。以下、概要だけ説明します。 朝
KPTを使ったプロセス改善：An Agile Way：オルタナティブ・ブログ
ソフトウェア開発の繰り返し単位（イテレーション）ごとに、そのタイムボックスで行なったことを反省し、未来に生かせるように口に出してみる、という活動を行なう。これは、反省会、回顧、Retropective、Reflection、などと呼ばれる（ぼくは「ふりかえり」という言葉が好きだ）。 アジャイル開発ではこの「ふりかえり」が「KAIZEN加速装置」となる。 これを行なうときに使うフォーマットを写真に示した。ぼくはこれをKPT（ケプト）と呼ぶ（Keep/Problem/Try）。Alistair Cockburnから教えてもらったもので、ぼくはこのフォーマットのヘビーユーザー。 ホワイトボードが３つのセクションに分かれており、Keep（このまま続けること）、Problem（問題点）、Try（次に試してみたいこと）と名前が付けられている。全員参加のふりかえりミーティングを開き、そこで、今回のイテレ
ITエンジニアを続けるうえでのヒント～あるプロジェクトマネージャの“私点”（5）
将来に不安を感じないITエンジニアはいない。新しいハードウェアやソフトウェア、開発方法論、さらには管理職になるときなど――。さまざまな場面でエンジニアは悩む。それらに対して誰にも当てはまる絶対的な解はないかもしれない。本連載では、あるプロジェクトマネージャ個人の視点＝“私点”からそれらの悩みの背後にあるものに迫り、ＩＴエンジニアを続けるうえでのヒントや参考になればと願っている。 ■リーダーシップのスキルは生まれつきのものか この連載も今回で5回目になりました。連載の趣旨は、プロジェクトマネージャ、およびプロジェクトマネージャになりたい人のための心構えを解説することです。いい換えれば、プロジェクトマネージャに必要な「リーダーシップ」の解説を意図しています。 連載開始以来、さまざまなご意見をいただきました。リーダーシップに関するご意見の中には、「前向きにリーダーシップを身に付けたい！」というも
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
TRICHORD
http://log.giantech.jp/daylist_html?year=2005&month=8&day=23
サービス終了のお知らせ