Trac Lightningで始めるチケット式開発「電撃」入門
“泥”開発に対する最終兵器「Trac」とは？ 誰もが必ず1度はイライラしたことがある「情報の囲い込み」問題 情報の共有はプロジェクトを円滑に進めるうえで重要な課題です。極端な例ですが、例えば、図1の例で見てみましょう。 分かりやすいよくある例で示すと、各開発者の作業状況はメールや手帳上に記されています。検討やヒアリングした結果は、メールでほかの人に問い合わせたならメールボックス上にたまっていきます。打ち合わせなどで相手に会ってヒアリングしたなら、手帳やノート上にメモとして残っていきます。こうして、各開発者が自分のタスクの情報をメールやメモ、あるいは頭の中で“囲い込み”ながら開発が進んでいきます。 ここで、開発者がある機能を実装するために、「別の作業の状況や進捗（しんちょく）を把握したい」とします。 「誰が情報を持っているのか分からない」 まず、誰が情報を持っているのか分からないので、ヒアリ
【6】プロジェクトを成功させる5つの土台：日経ビジネスオンライン
【ドングリ化について】 チャンスを逃さないためには、ぼんやりと考えていることを明確化し、まとめておくことが大切だ。 5分から10分ぐらいの短い時間で小さなメモに書き出してみる。 これを「ドングリ化」と呼ぶ（第1回「30秒ごとのチャンス」参照）。 今回は新しいプロジェクトのための要点をつかむドングリ化を実行する。 【同じ目標なのにかみ合わない現場】 「もっとプロジェクト規模を大きくしよう」 「いや、そりゃ無理だよ！」 と意見が対立している2人の、そのプロジェクト像、同じだろうか。 Aさんは、今の構想が70という規模だと考えている。Ｂさんは100だと考えている。 そこで、Aさんは、せめて100ぐらいの規模はないといけないと思って、大きくしようと提案する。 ところがBさんはすでに100の規模を想定しているので、さらに大きくしようという提案を聞いて、130ぐらいにしようと言われたと感じる。 完成像
組織の“リズム”を生み出す3つのポイント：日経ビジネスオンライン
個人のパフォーマンスの善し悪しを報酬に反映する──。 こんな成果主義を日本企業が導入した目的は、個人の高いパフォーマンスを引き出すことよりも、人件費を引き下げることの方が多かったと見ています。いずれにしても、結果として個人のパフォーマンスに焦点が当たり過ぎてしまった。 そうした状況を是正するため、多くの企業が職場のチームワークを重視する方向に再び動いています。ですが、それで成果主義の導入で生じた問題が解決するのでしょうか。 事はそう単純ではないと私は考えています。そもそも、「個人か組織か」という問いに対する正解はないからです。 「個人か組織か」に正解はない 突出した力を持った特定の個人が周囲を引っ張り上げ、組織全体のパフォーマンスをも高める。いや、特定の個人の力を突出させても、組織のパフォーマンス向上にはつながらない。だから、特定の個人よりも組織の力をきちんと高めないといけない。 ある時は
「戦う職場」の作り方：日経ビジネスオンライン
仕事柄、いろいろな会社の、いろいろな職場の様子について、見たり聞いたりする機会があります。 どんな職場が風通しがいいか、もちろん一言で語りきれるものではないのですが、最近1つの仮説を持つようになりました。 あえて簡単に言うと、次のようなものです。 明快な敵（競争相手）に向かって一緒に戦っていることを実感できる職場は、お互いのコミュニケーションが多く、結束力が強い。つまり、より風の通りがいい。 敵に勝つためには、一緒に戦略を構築する必要があるし、成功体験を共有する必要があるし、お互いを励ましあう必要があります。おのずと職場に活気が出てきます。それに対して、“戦場”から遠く離れ、一緒に戦っている実感を持ちにくい職場は、コミュニケーションが少なく、ムードもあまりよくありません。 先日、ある化粧品会社の営業の方が言っていました。 「今日、本社に行って驚きました。あまりにも職場が静かなもので。私がい
第12回 システム要員の安易な配置換えは志気低下を招く
現場の業務に精通させることを狙ってシステム要員を利用部門に配置する企業が少なくない。しかしこうした異動は，よほど周到に準備しないとせっかくの人材を潰してしまう。システムに詳しい若手が利用部門にいれば，雑用係として頼られてしまうからだ。このような安易な配置換えは，意欲や志気の低下を招きかねない。人員配置は会社全体の問題として捉え，育成方針と目標設定を目に見える形にすることが不可欠である。 本記事は日経コンピュータの連載をほぼそのまま再掲したものです。初出から数年が経過しており現在とは状況が異なる部分もありますが，この記事で焦点を当てたITマネジメントの本質は今でも変わりません。 専門商社のM社では，情報システム部門の生産性向上と人員適正化を狙って，部内の人員配置や担当を大幅に変更することになった。情報システム部門は約 50人の社員と外注要員を30人余り抱えており，各利用部門ごとに専属スタッフ
技術力の高いエンジニアをどこまで特別扱いすればいいのだろう - これ僕.com：行動分析学マニアがおくる行動戦略
malaがはてなを退職したって事で、原因は何だろう？ malaさんがはてなを辞めた理由は知らないけども、このエントリーを読んでて思い出したことがあった。 3年ほど前に私が15名ほどのチームでプロジェクトリーダーをしていたとき、一人だけずば抜けて技術力のあるエンジニアがいた（Aさんとする）。Aさんは私の1つ上の先輩で、その技術力の高さを見込んで、ライブラリだのフレームワークだのの開発や改善をお願いしていた。それについては、当然ながらチームに多大な貢献をしてくれたと思っているし、技術に意識の高いメンバーを彼に付けて作業させたので、他のメンバーの成長にも役立ったのは間違いない。 しかし、その時プロジェクトには、もっと単純だけど、時間がかかって根気の必要な、欠かすことの出来ない作業もあって、ほとんどのメンバーはそれに従事していた。多分、ライブラリだのをプログラミングするよりも、ずっとツマラナイ作業
強いチームワークこそ基本（267～273日）
今回はチームワークや連携の重要性について取り上げる。大規模システムの開発では大勢のメンバーが参加するため、プロジェクト・リーダーの先導の下、しっかりしたチームワークが不可欠だ。 プロジェクトが成功するためには、まずリーダーとメンバーの間にいいチームワークが成立する必要がある。そしてリーダーには、プロジェクトの方針を部下に分かりやすく説明する、先頭に立ってプロジェクトを引っ張る、部下とともに汗をかく、など多くのことが要求される。 だが、何より大事なことは、部下から人間的に尊敬されることであり、部下を信頼して仕事を任せることであり、そして任せられる仕事を割り当てることである。不幸にも任せた仕事がうまくいかなければ、一緒に考えたり手を貸したりしなければならない。 尊敬されるリーダーなら、部下は苦しくてもついてくるし、リーダーが信頼する部下は、少々無理があっても信頼を裏切らぬよう必死に努力するだろ
第23回 一見ヒマな“予備兵力”を確保せよ 管理職は悪者になる勇気を持て
筆者が銀行のシステム部門で2～3年の経験を積み，ようやく一人前の仕事がこなせるようになったころ，同じチームのメンバーの仕事振りを見ていて不思議に思ったことがある。12～13人程度の小さなチームだったが，大きな案件を抱えて皆大忙しだったにもかかわらず，なぜか暇そうにしているメンバーが2人いたのだ。しかも，2人とも超のつくベテランSEだった。 ほかのメンバーが毎日深夜まで残業しているのに，この2人はほぼ毎日，定時に帰宅していた。筆者は納得がいかなかったので，チームを統括する課長に「なぜあの人たちに，もっと仕事を割り振らないのか」と聞いたことがある。すると課長はニヤリと笑ってこう言った。「彼らは予備兵力なんだよ」。 課長が言うには，現在のプロジェクトに，チーム全員のマンパワーを100％使ってしまったら，“突発的な事態”が発生したときに身動きがとれなくなる。だから“平時”には80％のマンパワーしか
育成も考えて適材適所の配置を（260～266日）
前回に続き、プロジェクト編成の諸問題を取り上げる。目前の仕事を見てメンバーの配置を考えるだけでなく、新人や後継者の育成についてもローテーションを含めて真剣に考えることが、チームワークの強化につながってくる。 技術的に優れていても管理力に欠ける設計者がいる。大きなプロジェクトはいくら技術力があっても、自分一人で、全部をまとめることはできないため、どうしても取りまとめ力や管理力が必要になるのは当然だ。ほとんどのSEや設計者は、技術的経験を積むに従って、管理力も何とか付けられるように指導していかねばならない。 しかしなかには、どうしても管理には向かないが、技術面では優れた力を持つ人材もいる。こういう技術者に無理に管理させると、部下の仕事がやりにくくなり、やがてはモラールの低下につながってしまう。こうした人材は、本来の良さを十分発揮してもらえるよう、管理面は別のスタッフが補う工夫をしたほうが、組織
SEマネジャは自分の考えを部下に公にせよ
SEマネジャは自分の考えを部下に公にした方がよい。特に，今年度の自分の課（グループ）の目標は何かどんな方針でやるか，どんな点に力を入れるのか，そしてSEに日ごろ特に心がけてほしい点などを全SEに示すことが重要である。 例えば，これはあるSEマネジャの例である。方針では，(1)ビジネス目標の達成を死守する，(2)お客様のご満足を得る，(3)生産性の向上を図る，(4)ビジネスやSEの変革に挑戦する，(5)プロジェクトはノートラブルでやる，(6)先進アプリケーションを発掘する，など自分の課（グループ）が進むべく方向を示した。 心がける指針では，(1)お客様の立場で考えて行動する，(2)営業には迎合しない。(3)正論なら顧客とぶつかってもよい，(4)顧客の部課長とも話す，(5)IT技術はマニュアルに書いてある程度は知っておく，(6)仲間が困っていたら助ける，(7)自分でできると思ったら上司への報告
UCがこれまで企業に浸透しなかった理由
電話やメール，インスタント・メッセージ（IM），テレビ会議，Web会議など，様々なコミュニケーション手段を一つのアプリケーションで統合的に利用可能にするユニファイド・コミュニケーション（UC）。コミュニケーションを取りたい相手が在席しているのか電話中なのかといった状態（プレゼンス）を基に，そのシーンごとに最適な手段を選んでコミュニケーションができる（図1）。社員間のコミュニケーションの円滑化によって業務効率を向上させるソリューションとして，2000年前後から製品が登場している。 図1●多様なコミュニケーション手段を統合するユニファイド・コミュニケーション（UC） メールやインスタント・メッセージ（IM），電話，テレビ会議などを，コミュニケーション相手の状態などによって臨機応変に使い分けられる機能を持つ。 [画像のクリックで拡大表示] これまではNECや沖電気工業（OKI），米シスコなどの主
［進捗管理編］PMは座っていてはいけない
でんと机に構えて座り，全く動かないプロジェクト・マネージャ（PM）がいる。そこが開発現場の真っ直中ならまだしも，全く関係ない自分のデスクにかまえている場合すらある。そういうPMに限って，メンバーに対して報告を徹底させることに躍起となり，報告されていないことがあると叱咤する。すべての情報は自分に集まるべきとし，自分はその中心なのだから動かないと決めつけている。 確かに，PMはメンバーに対して安心感を与えるために大きく構えておく必要がある。しかしそれはPMの取るべき姿勢の話であり，実際に動くなという意味ではない。PMは開発の状況を，メンバーからの報告だけではなく，自分の肌で感じるべきなのだ。 動かないPM Iさんは中堅SIベンダーU社で中堅PMとして認められている技術者である。入社以来，プログラマ～SE～PMと順調にキャリアを積み重ね，数年前からPMとして活躍している。今回，Iさんは得意先であ
［進捗管理編］人月を入れ替えてはいけない
システム開発プロジェクトでは規模を表す単位として「人月」という単位がよく用いられる。これは技術者一人が1カ月労働することを意味し，人を数える助数詞「人」と，時間を数える単位「月」を掛け合わせたものである。数学的な見地から見ると「人」は分離量であり「月」は連続量である。この分離量と連続量の違いとは，例えば計算機について考えれば，分離量はデジタル計算機であり，連続量は計算尺である。つまり，「人月」とは分離量と連続量を掛け合わせた特殊な単位であり，どちらかというと「概念」に近い。 この「人月」という概念を「人」×「月」という単純な数式で考えると大きな失敗を犯す。例えば，プロジェクトの後半で問題が発覚し納期遅延が発生しそうな場合，あとどのくらいの工数が必要かを算定し，追加要員を投入して遅延を挽回しようとすることがある。 これは，遅延挽回対策として非常に危険な方法である。遅延を挽回できるどころか，当
［実践編］SEとBEとDEを区別する
前回，プロダクトに着目した要件，ビジネス・ルール，アプリケーションのアーキテクチャを明確にすることで，何をどう作るかということを明確にした。今回は，そのアーキテクチャに基づいて，プロセスの整備や分業体制をどうしたか，すなわちどのような手順でファクトリー化を進めたかを説明する。 【手順1】SEとBEとDEを区別する 【手順2】開発プロセスと工程と図面を関連づける 【手順3】プロダクト開発とプロダクトライン開発を分ける 【手順4】要求分析の達人を育てる 【手順1】SEとBEとDEを区別する BIGLOBEの情報システムを支える我々の仕事は，ソフトウエアを作るだけではなく，プロバイダとして，サービスを作って提供することである。要求者は事業部門に当たり，事業部門と共同で新しいサービスや業務を検討するというスタイルを取っている。 サービス企画や業務プロセスを考える人たちを「ビジネス・エンジニア（BE
現場力向上宣言！ IT業界の現場力は30点
「現場力」の提唱者である遠藤功氏に，本当の現場力とは何か，なぜそれが重要なのか，システム開発の現場をどう見ているかを聞いた。製造業と比べるとIT業界の現場力は見劣りがする。まずは目指すべき現場の姿を認識すること。その上で，システム開発の特性を踏まえた，問題解決の仕組みを整備することが大事だと指摘する（聞き手は日経SYSTEMS編集長，杉山裕幸）。 今，チームや個人の「現場力」が注目されています。ただ，その本質を理解せずに言葉が独り歩きしているようにも思います。遠藤さんが考える「現場力」の定義は何でしょうか。 “現場の自律的な問題解決能力”と定義しています。問題を解決できる能力と，当事者意識を持っていることがその根幹です。 「ウチにも現場力がある」という人はいます。いざとなったら徹夜でも何でもして何とかしてしまう，フットワークだけはむちゃくちゃよい，要は足腰が非常に強いことを現場力と言ってい
エンゲージメント
個人が目指す成長の方向性と組織が目指す成長の方向性がどれだけ連動している関係なのかを表す。組織に対する「ロイヤルティー（忠誠心）」を発展させたような概念。 若手社員の離職率の高さや優秀な中堅社員の流動化が問題視され始めています。この問題に対処すべく、「エンゲージメント」というキーワードに着目する企業が増えてきました。 人材・組織改革プログラム開発支援事業を手がけるヒューマンバリュー（神奈川県湯河原町）の高間邦男代表取締役によると、米国で毎年開催される世界最大級の人事イベント「ASTD（アメリカン・ソサイエティ・フォー・トレーニング・アンド・デベロップメント）国際コンファレンスエキスポ」でもここ数年、エンゲージメントに関するコンファレンスが盛況。同氏は「米国では社員がすぐ会社を辞めてしまうことが大きな問題となっているから」と指摘します。 効果◆目標の意識合わせ エンゲージメントという言葉は、
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
