プログラミングでメシを食わせろ!! 成功する開発チームのための技術と運営術

概 要

現役の開発チームリーダーが書いた、プログラマーを中心とした開発チームのチーム運営HowTo本です。開発チームを任され、プログラマーの集団を束ねるリーダーになったとき「どうやって優秀な人材を採用し、育てればよいのか」「皆が働きやすい環境はどうやれば作れるのか」「リーダーに必要な資質とはなにか」など誰もが悩む問題をわかりやすい言葉でやさしく解説します。チーム内の情報共有の方法、「ほうれんそう」ができない人への対策、「褒める」「叱る」ときの注意点、目標設定のコツ、プログラマー採用の際の基準、メンバーを評価するときのポイントなどを現場で得た経験を元に紹介。前著「プログラミングでメシが食えるか!? 成功するプログラマーの技術と仕事術」はプログラマー必見の一冊です。

著者 小俣光之
価格 本体1400円(税別)
ISBN 978-4-7980-2097-6
発売日 2008/10/22
判型 四六
色数 1色
ページ数 304
CD/DVD
対象読者 入門
シリーズ
表紙イメージ
購入 アマゾンで購入する
楽天で購入する

※リンク先によっては、販売ページが用意されていないことがあります。あらかじめご了承ください。

新しいウィンドウで開く 書籍購入のご案内

サポート

サポート情報は以下からご参照下さい。

サポート情報へのリンク

目次

プログラミングと意識―Programming & Consciousness

01 開発現場におけるリーダーの役割とは?

「発想力」

「交渉力」

「決断力」

「雰囲気作り」

まとめ

02 リーダーを任されたらどうする?

目標と展望を語ること

仲間を集めること

意志のある組織に変えること

メンバーに任せ舵を取ること

「ほうれんそう」を肝に銘じること

熱い思いがあるか

03 リーダーに求められるものは何か?

上からの要求=「結果」、下からの要求=「メリット」

「仕事しやすい環境作り」

「外部との交渉」

「率先して行動する」

「決めたことは続けること」

「力で押さえつけない」

「敵を作らない」

「スキを見せない」

「情報伝達」

「明るく振る舞う」

「メンバーにはできない部分を持つ」

「休まない」

まとめ

04 仕事で重要なものを理解しているか?

「信頼」を裏切らない行動とは

「信頼」を補強する「継続」の力とは

本を書くことも「継続」だ

05 リーダーは仕事のフローを理解しているか?

知っておきたいフローとは

フローを理解していないと

ミーティングをやればよいわけじゃない

技術的なベースのないリーダーは

技術に自信があればよいわけじゃない

06 リーダーはビジョンを示しているか?

組織の持つべきビジョンとは

それぞれの立場で持つビジョン

ビジョンは共有してこそ意味がある

ビジョンに向き合わせる

ビジョンをいかに伝えるか

07 マネージャーとの違いを理解しているか?

マネージャーがいれば十分か

チームの振る舞いを考える

メンバーの力を活かす

マネージャーよりリーダーを目指せ

チームをどうしたいか?を考える

08 プレイングにどれだけ時間を割けばよいか?

リーダーになった=リーダーの仕事のみ?

技術的アドバンテージは重要

どうやって技術を磨き続けるか

得意な分野で出番を残しておく

具体的なプレイングの時間は?

09 あなたにはいざというときに頼れる人がいるか?

リーダー自身が困った局面では

普段からのコミュニケーションが大事

ギブ・アンド・テイクの精神

自分から出て行く

意見に流さればかりいるな

10 リーダーは技術を磨くか運営に徹するか?

「プロ」レベルのものを捨てない

経営に必要なものはMBAか

技術者はやはり技術者であれ

社長が考えるべきこと

11 リーダーは自部門を上層部から守っているか?

なぜ上層部と戦うか

結果で納得させる

「ほうれんそう」で信頼させる

味方を増やしておく

12 リーダーは自ら営業マンでもあるべきか?

誰が営業をやったらいいか?

リーダー自らが営業を経験する

order getterになれるか

プログラミングと組織―Programming & Organization

13 開発のためのチームとはどういうものか?

共通の目的とは

技術志向=やりがい重視、事業志向=効率重視?

メンバーの志向を見極める

14 チームは情報を共有できているか?

自発的行動に必要な情報とは

どのように情報を伝えるか

15 チームは手順を標準化できているか?

開発は個人プレーか

決めても運用できない

標準化で何がよくなるか

標準化すべきこととすべきでないこと

16 メンバーの得意分野を生かしているか?

若いメンバーには多様な分野を

役割という側面も考える

まとめ

17 目標をメンバーと一緒に作っているか?

あくまでもリーダーが決める

メンバーの意見も取り入れる

メンバーの目標設定は自発的に

あくまでも組織の目標が大事

18 メンバーに動機付けができているか?

報酬による動機付けはわかりやすい

「おもしろさ」を動機付けに利用する

「成長する楽しさ」を伝える

「よい」お客さんから刺激を受ける

リーダー自身が楽しく仕事をする

19 「ほうれんそう」ができないメンバーをどうするか?

悪い報告ほど重要

「連絡」することで共有できる

「相談」はさぼらない

5W1Hより5W2H

学校で習うのは5W1H

20 組織の問題発見を真っ先にできているか?

問題を定義する

問題をどのように受けるか

問題が表面化しやすい空気を作る

21 組織に巣くう問題児の扱いを心得ているか?

仕事で成果を出せない

仕事で邪魔をする

悪影響を与える

問題児はそもそも採用しない

22 外に出たがらないメンバーを連れ出すには?

外は営業に任せておけばよいか

技術者こそコミュニケーションが必要

外に出る状況を「強制」する

井の中の蛙にならない

生き残れる技術者になる

23 人脈が広がらないメンバーにできることとは?

ギブ・アンド・テイクの精神を守る

何がギブできるかを知る

上のレベルの人とコミュニケーションする

自分が媒介者になる

まずは自分自身で人脈を持つ

24 開発チームにブレーンストーミングは有効か?

ブレストに何を求めるか

どのように切り出すか

25 ストレスを抱えるメンバーをいかに癒すか?

7Kから脱却すればいいか

「やりがい」はストレスを駆逐する

26 チームワークのよいチームを作る秘訣はあるか?

チームが団結するとき

チームが団結しなくなるとき

27 明るく前向きな目標設定の秘訣とは?

目標は非現実的なものを考える

目標は二重に掲げる

目標を達成したらのイメージを作る

プログラミングと会話―Programming & Communication

28 コミュニケーションの基礎を理解しているか?

プログラマーはコミュニケーションが苦手?

コミュニケーションの基本はまず「聞く」こと

メールは便利だが依存しすぎると…

相手の意欲を引き出す

要はじっくり焦らないこと

29 コミュニケーションの方法を使い分けているか?

コミュニケーションにはいろんな種類がある

特徴を理解した上で使い分ける

作戦を考える

ケースを考えて対応する

気持ちを伝える+履歴を残す

30 双方向のコミュニケーションを心掛けているか?

指令はコミュニケーションではない

双方向のコミュニケーションではムード作り

雑談で真意を引き出す

割り込みを許容する

31 メンバーの性格をよく理解しようとしているか?

どう把握するか

「確実さ」を持っているか

良い面は活かし悪い面は補う

性格は変えられる

32 メンバーと一緒に考え行動しようとしているか?

意識合わせのコミュニケーションとはともに考えること

メンバー発の結論には納得感が生まれる

33 メンバーを常に見ているという気持ちがあるか?

邪魔されない環境で十分か

個性を理解して対応する

34 まず聞くということを心掛けているか?

聞き上手=気持ちよい?

沈黙するなら質問を

「聞く」ために必要なこと

35 叱咤激励を使い分けているか?

叱る場合はケースを考えて

褒める場合にはポイントを外さずに

方法を使い分けよう

叱る側の心得とは

具体的な報償と組み合わせる

36 メンバーを成長させようという気持ちがあるか?

メンバーの成功を心からうれしく思うか

スポンサーシップで成果を上げる

行きすぎた個人評価は禁物

成功体験を持たせよう

37 メンバーに考えさせる習慣を付けているか?

考えさせる=問いかける

「?」を5回繰り返す

面談では「?」で聞き出す

38 考える場に飛び込ませる

メンバーの金銭感覚をどう育てるか?

収支を考えて行動する

費用対効果を考える

金額の多寡で判断しない

39 メンバーの時間感覚をどう育てるか?

時間は管理すれば万全か

時間感覚=全体を見渡す

40 すぐ言い訳するメンバーに効く薬はあるか?

なぜ言い訳するのか

言い訳は聞かない、だけでよいか

それでも言い訳してしまうときは

41 変化を嫌う保守的なメンバーを動かすには?

変化はむしろ願うもの

ライフサイクルを理解させる

42 年上のメンバーの処遇に特別なものはあるか?

仕事とプライベートの関係は違う

指示は組織に則って行われる

プログラミングと人―Programming & Person

43 プログラマーを採るとはどういうことか?

どのような人が応募してくるか

どんな基準で「採る」か

実技はやはり重要視する

一緒にできる気持ちになるか

44 プログラマーの年齢に何を求めるか?

「年齢」=「技術力」となるか

「年齢」に何を求めるか

キャリアをどう作るか

採用時「年齢」に求めるもの

45 プログラマーに向くのはどういう性格か?

プロの「プログラマー」のイメージ

「几帳面」VS「大ざっぱ」

とにかく何とかする

46 プログラマーに向かないのはどういう性格か?

コミュニケーション力はいつでも基礎となる

解決能力がない・抱え込む

完璧を目指すかほどほどか

やはり「信頼」がものをいう

47 プログラマーはプログラミングだけできればよいか?

プログラミングにどれだけ時間を割けるか

時間をかけられるだけかければよいか

ベテランの価値をどこに求めるか

48 成果を正しく評価しているか?

部下が不満を感じるとき

できる部下・できない部下・普通の部下

「公正」と「平等」を意識する

評価する側が心掛けること

49 育てるという観点でフィードバックしているか?

してはいけないフィードバック

成長させるために伝えること

叱るときに伝えること

「育てる」という観点を持つ

50 メンバーの言葉と行動が信用できるか?

メンバーに任せられる気持ちになるか

信用に外部を利用する

51 任せることの違いを理解しているか?

「任せる」は「やらせる」か

任せたら考えること

任せるコツは「のりしろ」?

52 後継者を意識して育てているか?

「人材」をどう育てる?

開発より難しいコミュニケーション

「育てる」場を作る

53 メンバーの本気度を測るにはどうするか?

理由を「なぜ?」責めにする

具体的な考えを要求する

メンバー同士で戦わせる

「その気」にさせられるか

「本気」が伝わってくるか

54 望む姿を「称号」として与えているか?

「称号」を与えることとは何か

「称号」とは「特別」を与えること

「称号」は自分で考える

55 資格は評価に値するか?

採用時に考える「資格」

査定時に考える「資格」

報償時に考える「資格」

いつ導入するか

56 OJTはスキルアップの早道か?

新人は入社までに「即戦力」とする

「教えない」という指導

OJTは人相手にこそ活きる

プログラミングと環境―Programming & Environment

57 プログラマーにとっての「働く」場所とは?

まず「静粛さ」が基本?

ゆったりスペースが欲しい

椅子や机は重要…?

いい意味で散らかっている

セキュリティ対策は身の丈にあった程度に

まとめ

58 プログラマーにプライベートスペースは必要か?

自分の席がなくても大丈夫

効率を考える

私的空間の誘惑

コミュニケーションの必要性

まとめ

59 個室と相部屋はどちらがよいか?

個室は実はプログラミングには向かない

営業との相部屋は避けた方がいい?

会議スペースは別途設ける

60 フレックスと定時制はどちらが効率的か?

時間が決まっていることには意味がある

フレックスタイムはやりにくいか

61 プログラマーにとっての「道具」とは?

プログラミングに当たり前に必要な道具とは

意外と考えない、道具の役目とは

「プログラマー」が必要な道具は違う

62 どのような道具を使わせるのがよいか?

仕事にこだわるには道具にこだわる

こだわりをどこまで認めるか

ハイレベルな道具をあえて使う

63 道具は現場で統一すべきか?

統一のメリットとデメリット

道具にはコストがかかる

統一がいい場合といらない場合

64 道具にうるさいメンバーをどうするか?

言い訳としての道具と趣味の道具

外との関係で必要になる道具

言葉で必要性を明確化する

65 道具自慢はほめられることか?

2つのやり方で道具が変わる

プロは道具を自ら選ぶべき

満足できる道具を

66 プログラマーの福利厚生をどう考えるか?

福利厚生を改めて考える

福利厚生は上司が率先して

見直されている福利厚生

福利厚生はメリットを考える

67 オフタイムにどう付き合うか?

「飲み」の効用はある?

「区切り」は意外と大事

PR

秀和システム