全員が「明るい、楽しい」と感じるチームにしたい ― ＠IT情報マネジメント
前回「優秀なプロマネはメンタルな働きかけもうまい」から少し間が空いてしまいましたが、第2回目の今回は、リーダーに求める心の在り方をお伝えしたいと思います。といっても、1回目をご覧いただいた方であればお分かりだと思いますが、道徳的な話をするつもりはありません。結果として道徳的な話と同じ内容となるかもしれませんが、心理的な裏付けによって、チームのパワーを最大化するために必要な心の在り方にフォーカスしています。 2つのコミュニケーション コミュニケーションは、コミュニケーションを取る相手の違いから2つに分類されます。1つは、他者とのコミュニケーション。もう1つは自分自身とのコミュニケーションです。 前者については、ビジネス書などでも「説得術」「販売テクニック」「リーダーシップ」といったキーワードを基に書かれることが多いので、普段からなじみがある方もいると思います。一方で後者は、どちらかというと、
「SIerよ！ リスクを取れ」と言っても、リスク管理ができてなければ・・・
少し前の話だが9月20日に、日立情報システムズが9月中間期の業績予測を下方修正した。なんでも連結経常利益が従来予想より15億円下回る32億円となり、増益見通しから一転減益となるという。まあ業績予測の下方修正なんか日常茶飯事だから、投資家でもなければ大した話ではないのだが、「将来を見据えたチャレンジングな案件で躓いた」といった趣旨の説明を見つけ、あれっと思った。 ITサービス会社も今、リスクを取るべき時だ。プロジェクトの失敗を過度に恐れるあまり、ガチガチの管理ばかりをやっていては未来がない。そんな話を以前書いたことがある。だから、チャレンジングな案件に挑戦して失敗するのは、ある程度は仕方がない。だが、経営トップが投資家に頭を下げなければいけない業績予想の下方修正となると、ちょっと穏やかではない。「ほら見たことか」という声も聞こえてきそうである。 で、少し詳しく話を聞いてみた。中堅・中小企業向
真髄を語る 経営者がITを理解できない本当の理由
佐藤正史 氏 JTB情報システム 代表取締役社長 当サイトにおいて、企業情報システムにかかわってきたベテランが引退する、いわゆる「2007年問題」について色々な議論がされております。私は1971年にJTBに入社して以来、ほぼ一貫して情報システムの仕事に従事してきました。私が情報システムに関係してきた期間は、日本における約40年の企業情報システムの歴史と概ね重なっております。 2001年から取締役（情報システム担当）として、CIO（最高情報責任者）の仕事をし、現在はJTBの情報システム関連会社の社長を務めています。おそらく、あと数年で2007年問題の一方の主役として、この舞台を去ることになるでしょう。まもなく企業人生を終えようとする一介のシステム屋ではありますが、ぜひとも多くの方に申し上げたいことがあり、この場を借りて思うところを綴ってみます。 私は今、日本のITを巡る状況に大変な危機感
チームリーダー日記 : [メモ]1枚紙設計書(特大サイズ)
キノトロープさんのサイト 制作するWebサイトにおけるシステムの流れを表すWebサイトの設計図。 http://www.kinotrope.co.jp/service/output08/index.shtml webサイトの全部の画面遷移を一枚で書ききる。 A0とかのサイズになったりするとか（以前、どこかのサイトに、詳しく書いてあったんだけど、URL失念です）。 とにかく、これが完成すれば全体の70%は完了、とか書いてた気がする。 ----- 日経システム構築、改め、日経Systemsのこの号では、設計書を1枚（特大サイズ）で書いたよ(with 苦労)、という話が載っていた。(A3×n枚だったかも) http://bpstore.nikkeibp.co.jp/mokuji/nos161.html ---- 一枚紙設計書(特大サイズ)の、僕が依然からしているイメージにもっとも近いのは、 go
上流設計 - essence-s
会場が会社の近くだったのもあって、行ってきました「上流設計セミナー」。 またまた、いろいろ刺激になった。 どろくさいケーススタディがおもしろいですねー。 とりあえずキーワード。注釈はあとで。 経営戦略と施策からITへの要求定義への関連づけを見える化 要求が迷子のスキーヤーになる現象に注意 ITが目的のターミナル駅になる現象に注意 カスタムメイドではなくレディーメイドの準備 仕様変更は変更でないかもしれない→はっきりしただけで変更ではない。 そもそも、きっちり決める事できるんだっけ？ Asisならできるかもでも作る意味はない。ToBeの要求をどうしたらいいのか。 結局反復をちゃんとやろうよ。 ユーザーの要求粒度がまちまちなので既存のインフォメーションモデルはなりたたない ユーザーの要求粒度によって判断してはいけない 要件確定時ぬけおちる情報に変更可能性が隠れている 量の絶対値ではなく量の変化
クリティカルチェーン・プロジェクトマネジメント（くりてぃかるちぇーん・ぷろじぇくとまねじめんと）
不確定要素の多いプロジェクト型業務に、TOC（注1）の基本原理を適用したプロジェクト管理手法。クリティカルチェーン（注2）という制約条件の下、プロジェクト各工程の締め切り厳守を積み上げるアプローチではなく、プロジェクト全体の納期を守ること（あるいは短縮すること）を目的に、TOCの提唱者エリヤフ・M・ゴールドラット博士（Dr. Eliyahu M. Goldratt）によって開発されたTOCプロジェクトマネジメント（注3）ともいう。 PERT（注4）に由来する従来のプロジェクトマネジメント手法が大規模プロジェクトにおける複雑なスケジューリング問題の数理的最適化を志向しているのに対して、プロジェクトという不確定度の高い作業を行う場合の人間心理や行動特性、および社会的・組織的問題に配慮して、全体最適なプロジェクト管理（スケジューリング、タスクの実行、進ちょく管理）を行う実践的手法である。 従来の
40歳前後の技術者が不足！ そこからITサービス業界の事情を読む
最近、ある証券アナリストの人から、「ITサービス会社の年齢別の人員構成に着目すると、いろんなことが見えてくる」という話を聞いた。特に興味深かったのは、38～42歳の人員に凹みがあるITサービス会社が多く、プロジェクト・マネジャー不足の懸念があるというくだり。では、何故その世代の人員が少ないのか。その話を聞いて、私はピンと来るものがあった。 この世代の技術者が少ない理由を、彼らの新卒採用時にまで遡る必要はあるまい。15年前の1991年が「ダウンサイジング元年」で、オープン系への流れが加速するのはそれ以降の話なので、彼らの採用されたのは、まだ平和な“メインフレームの時代”だ。それよりも直近、ユーザー企業がIT投資額を抑制し、「ITデフレだ、オフショアだ」と騒いでいたころの出来事の影響の方が大きいだろう。 その頃、彼らの年齢はちょうど30歳台後半に収まる。そこで思い出されるのは、ITサービス業界
プロジェクトチームのリーダーに向く人、向かない人 ― ＠IT情報マネジメント
チームで遂行されるプロジェクトにおいて、優秀なリーダーの存在は極めて重要です。そこで今回から、リーダーについて考えてみることにします。リーダーシップの具体的な技術に関してはコーチングなどの記事を参考にしていただくことにして、ここではもっとベーシックなところをターゲットにします。なお対象としては、ユーザーサイドに限らずプロジェクト一般についての話となります。 誰でも持っているリーダーの素質 よく話題になることに、リーダーにはリーダーとしての素質がなければならないのか、ということがあります。ある程度の素質は必要でしょうが、それは大多数の人が持っているはずです。そのように考えられる根拠はあります。 例えば、ふさわしい人が地位に就くのではなく、「地位が人を育てる」ケースはよく知られています（年功序列主義の会社ではよく見られることです）。これは、リーダーとして特別な素質がないと思われたり、思い込んだ
『技術空洞』を読んで考えたリーダーシップの意味 - R30::マーケティング社会時評
このブログでもこれまで時々ソニーの経営について書いてきたが、ハコフグマン氏のブログで同世代の元ソニー技術者による告発本『技術空洞 Lost Technical Capabilities』が紹介されていたので、さっそく入手して読んでみた。 んでもって、自分が以前の取材などでも得ていた印象とほとんど同じだったので、がっかりといえばがっかり、納得といえば納得。今さらそれ以上書くこともないかなあと思いつつ、とはいえいろいろと思うところもある本だったので、書評でも書こうかと気を取り直してメモ作ったり他に書評しているブログを探したりして徘徊していたら、僕の思ったことと同じことをこれ以上ないくらいに簡潔にまとめたブログを見つけてしまい、書評を書く気が完全に失せた。そこで、今回はこの本を読んで思い浮かんだことについて書いてみたい。 著者の宮崎氏は、こちらのブログでもまとめられているように、技術系ソニー社員
チームリーダー日記 : [メモ]プロマネを独りにしないでね
恐怖！現場の叫びでわかった嫌われるプロマネの正体／Ｔｅｃｈ総研 ただ読むだけじゃなくて、どうすればこういう問題を解決できるかを考えないとな。 ちょっとだけ書くと･･･ 苦闘しているプロマネに対して、会社が出来ること プロマネを孤独にしないでね。 物理的に近くに、同じような立場の人（出来れば、何かしらのつながりのある人）を配置してね。周りに部下しかいないと、ちょっとした相談相手にもならないから。 プロマネに、機動力のある懐刀を1人は付けてあげてね。プロマネの頭を出来るだけクリアに保つために。 ちょっとしたレビューをこまめにやると、費用対効果が結構いい感じになります。 それと同じで、相談ごとも、ちょっとずつ、こまめにやるといい感じ（だと私は思ってます） ---
NTTデータなど6社が作る「お客にも分かるシステム仕様」、その意味するもの
このメンバーなら、最初に適用するのは東京証券取引所の新システムだろうな----「NTTデータ、富士通など6社、顧客にも分かるシステム仕様作りで協力」なるニュースは、そんな妄想をたくましくさせる話だった。 なんでもNTTデータ、富士通に加えて、NEC、日立製作所、東芝ソリューション、構造計画研究所が「発注者ビュー検討会」を作り、ユーザー企業から受注する際の「業務システム仕様」について、標準的な記述方法などを共同で検討するらしい。要は、お客にもシステム仕様を分かりやすくし、双方に誤解なきようにして、後のトラブルの芽を未然に防ごうということらしい。 最初は、要件定義のあたりまで視野に入れているのかとか、エンドユーザーには理解不能なUMLに取って代わるものを作るのかなどと思ったが、それは違った。あくまでも要件定義後のシステムの仕様作りでの話だし、別にUMLをリプレースする話でもない。出来上がり予定
モデル部分の工数見積もりの難しさは開発リスクだと思うが、そもそもモデルの複雑さって、どう測る？ - ウィリアムのいたずらの、まちあるき、たべあるき
ウィリアムのいたずらが、街歩き、食べ物、音楽等の個人的見解を主に書くブログです（たま～にコンピューター関係も） 開発工数の見積もりとしては、FPとか（そう、ウィリアムのいたずらももっているふぁいなんしゃるぷらんなー、じゃなくって、ファンクションポイント）まあ、いろいろあるわけだけど、あれって、帳票数とか入出力項目、そのたもろもろってなかんじだとおもう。 でも、その辺が自動化されてくると、実際の開発で、開発期間のウエイトが増えてくる＆リスク要因が増えてくるのが、モデルの部分だと思う。 つまり、業務モデルの複雑さによって、コーディング量も、仕様書のまとめる期間も、プロトタイプでアジャイルっぽくやるんなら、スパイラルをまわす回数も、規定されてくるんだと思うけど、そもそも、モデルの複雑さって、ドーハカルの？ このへんの、モデルの複雑さがきまんないと、モデルにかかる工数も決まんなくなってくるわけで、
アジャイルだとリファクタリングが必要な理由＆アジャイルする意味をなくす営業・ＰＭの態度 - ウィリアムのいたずらの、まちあるき、たべあるき
ウィリアムのいたずらが、街歩き、食べ物、音楽等の個人的見解を主に書くブログです（たま～にコンピューター関係も） アジャイルが使われる多くの理由は、「仕様が固められない」という部分が多いと思う。 あ、あとは、できるのを見ないと怖いとか。。 っていうことで、アジャイルではじめる場合、初めから「共通部分を抜き出して」ということをやれないケースもあるし、やると危険なケースがおおい。 話が進んでいったら、「ぜんぜん共通じゃないじゃーん！！」っていうことになり、その部分を作り直しとなったりするから。 オブジェクト指向な人は、「そーいう部分のために、派生があるんです」というとおもうけど、派生する意味ないくらい、共通じゃない（見た目は共通だけど、中身は共通じゃない）というケースがあるので、やっぱ、オブジェクト指向を採用しても、共通化すると、作り直しになってしまったりする。 てなわけで、いったん全体を作って
チームリーダー日記 : [メモ]初見メンバーへの仕事の割り当て方
-前提 各個人の 仕事の能力は様々。 今回の案件への相性は様々。 メンバー間の相性は様々。 現在の体調は様々。 各仕事の 難易度は様々。 input資料の充実度は様々。 ボリュームは様々。 隠れ作業は様々。 人数と仕事 8人（初対面） 8つの仕事 ■案１ 1人に1仕事ずつ割り当てる。 大ハマリしてしまう仕事が出る可能性あり。 一斉にフィードバックが発生してしまう可能性あり。 →修正とか横展開が追いつかなくなる。 ■案２ まず、2人ペアに1仕事ずつ割り当てる。 1/3の時点で、全員の適性を見る。 （最初の時点よりも、もっとわかりやすくなってるはず） 1/3くらいまで仕事を進めた時点で担当の編成を考え、場合によっては組み替える。 例えば、その仕事が軌道に乗っているなら、適性の低いほうの人を継続担当にする。 適性の高い人に残りの仕事を割り当てて、一気に開拓してもらう。 つまり、適性の高い人は、最
■ - wisboot’s diary
仕事では、ソース管理にVB6やVB.NETと親和性の高いVSSを利用している。VSSはVSSでなかなか使い勝手がよく（特にソース差分を閲覧するとき）、重宝している。 しかし、以前からもう１つ気になるオープンソースのバージョン管理システムがあった。SubVersionだ。 なぜ気になったのかというと、こんなの(xdocfdiff)があったからだ。 ファイル形式には２つの種類がある。テキスト形式とバイナリ形式だ。テキスト形式は文字コードから構成されるファイルのため、差分を取りやすい。しかし、バイナリ形式になると差分を取ることは不可能に近い。せいぜい、変化があったかどうかがわかるぐらいである。 しかし、上に挙げた「xdocfdiff」というツールは、SubVersionのWindowsシェル拡張を利用したクライアントソフトであるTortoiseSVNで利用することが出来る。このxdocfdiff
チームリーダー日記 : [仮説]ストレスとスケジュール遅延の原因もロングテール
「web進化論」を読んだり、いろんな出来事があったり、ちょっとした会話をしたり、いろいろ観察してるうちに、こんな２つの仮説をでっちあげました。 おいおい検証していきます(やっぱ、実際に試さないとね)。 ■易しいが大量のタスクと、仕事上のストレスの関係 タスクの難易度、勤務時間ではなくて、タスク数に連動する。 ひとつひとつのタスクは易しくても、数が多いと、単純に積分した面積以上のストレスをもたらす。 それは、「タスク数が増えると、関連する人の数が増える」からかもしれない。 易しいタスクでも、ロングテールでかき集めると、人へのダメージは深刻になる。 ▼ これは、検証方法というか、実戦方法も少し考えました。 デヂエで仕事時間を入力したり、wikiでチーム内のことを書きまくってる現チームが前提ですが･･･ 微小なタスクから大きなタスク、難易度も様々なタスク、とにかく、ぜーんぶ、デヂエの表に突っ込む
チームリーダー日記 : [メモ]機能と目的
[仮定]無理な開発スケジュールを立てないようにするために、自動でスケジュールを作るアプリを使うことにしたとする。 自動生成された期間より短くするには、それなりの対策が採られていないといけない。 というのも、理由もなく、期間を短くすることは、もう、間違えの原因だからである。 ■ここからが分かれ目。 １．理由を入力しないと、期間を変更できないアプリ。 ２．理由を入力しなくても、期間を変更できるアプリ。 ■１のその後 現場ではどうにもこうにもならなくて、適当な理由を（時間を浪費しながら）作って入力する。 もしくは、建前としてアプリを使い、別に本音のスケジュールを 作る。つまり、無駄な作業と化す。 ■２のその後（かつ、良い機能を持ってる場合） とりあえず、願望が入ったスケジュールに変更できる。 最初の自動算出したスケジュールとの対比を常に見ることができる。 願望スケジュールを立てたけど、結局、実態
NameBright - Coming Soon
michys.com is coming soon This domain is managed at
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
MPUF (Microsoft Project Users Forum)
恐怖！現場の叫びでわかった嫌われるプロマネの正体｜【Tech総研】