開発チームを育てあげよう

開発を成功に導くためには、開発チームを育てあげていくことが大切です。
(この文章にはあたりまえのことしか書いていないはずです。)

人を募集する、マネジャーを募集するだけでは、チームになりません。

• マネジャーは自分の判断をメンバーに従わせるには、納得性を重視してください。
• それぞれのメンバーが何を得意とするのか理解しましょう。
• 欠点だらけの自分ですから、欠点だらけの他のメンバー を好きになってみましょう。
• 気軽に雑談をできる場所を確保してください。
  • 雑談もできない状況では、アイディアを交換するのもうまくいかなくなります。
  • 電子メールのように記録が残るようなことは、質問・相談できないことがあります。
  • 「いっしょに夕飯でも食べませんか。」そう話しかけてくる人は、大事な話をしたがっているのかもしれません

起こりうる困難を避ける方法をともに考えてください。

• 各人のもつ技術的な背景が違えば、思いつく方法は違ってきます。メンバーの力を活用しましょう。
  • 困難に立ち向かうよりも、困難を避けるのが得策です。
  • 克服しなければなならない困難なら、どうやって問題を小さくするか考えましょう。
    • 発生頻度を減らす。起きたときの自動化できる対処方法でカバーする。

• 起こりうる困難は、技術的な内容とだけは限りません。組織運営上の困難があります。

  • その組織運営上の困難を解決できるのは、その組織のメンバーだけです。
  • ある手法を実際に開発プロセスで使用してもらうための部分には人的（あるいは組織的）な要因があります。

• 必要なのはトラブルシューティングではありません。トラブルを発生させないために事前に手をうっておくことです

  • 自分の担当分以外で、事前に手をうってことは、自分にはできません。
  • そのため、他のメンバーに事前に手をうっておくことの大切さに気づいてほしいと願います。
  • 「この手順なら絶対成功する」と言える手順書を作って共有して、メンテナンスすることです。

• 開発の全体像を示した上で担当業務を説明してください。

  • 特に、担当業務に関連して、何については誰に質問すればよいのかを分かるように名前と顔と担当業務とを一致させるようにすること。
    • 組織表とメールアドレスだけ与えても、その人にどう話しかけていいのか悪いのかわかりません。
    • 今週加わったメンバーがいる状況では、「私の名前はみんな知っていて当然だろう」式の話し方ではなく、「（所属）の（だれそれ）です。○○○なので、あとでだれそれまで連絡ください）」
  • ちょっと分野が違うので、ミーティングで同じになることもない人と話せる職場を作って いきましょう。
    • 同じ部屋にいるけれども、名前も何をしている人かも知らない状況をほったらかしにしていくと、「チームとしてプロジェクトを成功させていくんだ。」という意識の低下に直結します。
    • 人数が増えれば増える分だけ、「それ自分の作業じゃないよ」と考える人が増えて、作業漏れを発生させやすくなります。

チームとしての仕事は、メンバーの力を理解すること、メンバーの力を育てることから始まります。

• 仕事をメンバーの割り当てようと思います。そのとき、そのメンバーにはどんな力があって、どううまくやり切れるのかを知っていなければなりません。
  • やっていた分野は同じでも、使用するツールが違えば戸惑うこともあって結果が出しにくいこともあります。
  • 自分の仕事の結果の品質に対する姿勢は、人によって違っています。
  • いい結果を出すには、それだけの力をチームとして持つこと。
    • よい手法を共有すること。
    • お互いに学びあうこと。
    • トリッキーではなく標準的なアプローチをしよう。
    • あなたが知らない未来の誰かがあなたのコードを引継ぐことを想像してみよう。

ソースコードの全体像、担当する分野で使われているライブラリについての説明をしてあげましょう

• Doxygen を使って、ソースコードの全体像がどうなっているのかをわかりやすく説明しましょう。
• 担当する分野によっては、その分野で頻繁に用いるライブラリについて説明しましょう。
  • 「import pandas as pd と書いている行でスクリプトが停止したけど、どうしたらいいの？」などはpythonユーザーでなければわかりません。

定期的に学び続ける習慣を維持しましょう。

• どのような手法が最近有効な手法としてあるのかは、定期的に外部のセミナーで学ばないと、それを知らないために無駄な作業を生じさせてしまうことがあります。
• 役にたつ技術書を紹介しあいましょう。
• 今までのソースコードを理解する上で必要なライブラリや文法などを共有しておきましょう。

仕事としての責任を果たせるコードを書くこと

• 仕様の理解
• 実装
• テストの仕方
• 組み込み
• ドキュメンテーション

追記：

不安を減らそう。

新規に加わったメンバーは、加わった後で知った課題のために大いに不安になりやすいものです。
ですから、メンバーにとっての不安を減らすことが大事になります。なまじっか、その分野についての経験があるほど、物事の難しさが見えてしまいます。不安がある状況では、本来の力も発揮されにくくなってしまいます。むしろ根拠に若干とぼしい楽観主義の方が力を発揮しやすい可能性があります。一度に解決できるのは１つの課題です。それなのに、複数の課題に目を奪われてしまって、その力を分散させてしまって、物事を解決できなくしてしまう恐れがあります。
　ですから、新たに加わったメンバーの不安を取り除くことが大切です。
不安を減らすには、「実際に課題を１つ解決できた」という経験を積むことです。課題を少しづつ解決できるという経験は、不安を減らすことに有効です。

誠実な質問には誠実な返答を

開発計画を実現していこうとするなかで、様々な質問が出てくることでしょう。そのときに、責任ある立場の人は誠実な返答に心がけてください。
　誠実な生き方をあなた自身がしているかどうかを、一緒に仕事をしている部下・同僚はみています。理不尽な状況は、仕事をしている限り常にあるでしょう。少しでも誠実な生き方をしようとして、個人的な損得では、得にならない行動をしたこともあります。はたして、その行動は、開発チームを育てあげることに役立ってくれているでしょうか。
戦争時において（部下を）『何千人殺せば、どこがとれる』と答えている人があることを知りました。そのような状況は人間として誠実な生き方とは私には思えません。
　最後には、自分本位とならざるをえない状況でも、誠実でありたいと私は思います。
　

---

以下の本が述べているような注意が有効だろう。

人を動かす

◇PART3 人を説得する十二原則
1 議論を避ける
2 誤りを指摘しない
3 誤りを認める
4 穏やかに話す
5 〝イエス〟と答えられる問題を選ぶ
6 しゃべらせる
7 思いつかせる
8 人の身になる
9 同情を寄せる
10 美しい心情に呼びかける
11 演出を考える
12 対抗意識を刺激する