2017年1月のアップデート情報

いつもbearfruitsをご利用いただき、ありがとうございます。

2017年1月のアップデート情報です。

• ポートフォリオにGoogle Analytics トラッキングIDをセットできるようになりました

Settingsページからセットしていただけます。

バグ発見のお知らせやご要望などございましたら、 support@bearfruits.net までお気軽にご連絡ください。

今後ともbearfruitsをよろしくお願いいたします。

「Team Geek - Googleのギークたちはいかにしてチームを作るのか」

Team Geek ―Googleのギークたちはいかにしてチームを作るのか

読書感想文。いくつか書いてみてわかったけど、人が読むことはあんまり意識していなくて、自分が本を読んだことをかみしめるプロセスのよう。（そのため、何が言いたいのかよくわからない文章だし、読みにくい）

買ったときは気づかなかったがオライリー本だったようで、独特な日本語の言い回しでサクサク読み進められる感じ。

基本的には「チームをうまく機能させること」が書かれている本で、何が有害か、とか、有害な人への対処の仕方とかまで書かれている。

帯や本の中でも語られているとおり、「ギークでなくても読む価値がある」本だと思う。というか、どんなチームにおいてもこの本に書かれていることは当然念頭に置いておくべきで、実際書かれていることの半分くらいは自分のチームでも実践してきたことである。
では、この本のポイントはというと、

• チームを上手に機能させるテクニックをしっかりと言葉にしていること
• エンジニア（ギーク）とうまくやること

が書かれていることである。

今回は中でも特に印象に残った部分をいくつか紹介する。

三本柱

チームで働くときのポイントである。
我々が思い浮かべるチームと言えば、古来よりマネージャが存在していて、マネージャによって細かく管理された仕事をこなすものである。
しかし実際は一人ではできないこと、難しいことを複数人でやるための組織であって、工場の工程のようなひとつの作業ユニットではない。

• 謙虚（自分が常に正しいわけではない）
• 尊敬（相手を一人の人間として扱い、能力や功績を高く評価する）
• 信頼（自分以外の人は正しいことをすると信じれば、仕事を任せられる）

自分で運転できるバスに乗りたい

優秀なエンジニアに優れた仕事をしてもらうには、エンジニアが安全にアイデアを共有できて、意思決定プロセスに口を挟めるような文化を作らなければいけない。

思い通りにさせるということではなく、メンバー全員がチームの成功に責任をもつ状態を作るという意味だ。
確かに自分が決定に関わっていない仕事の責任はとりたくないし、とらなければならない理由も納得がいかない。

建設的な批判

「信頼」とは、フィードバックや批判をしないということではない。
建設的な批判は大変貴重なものであるが、多くの場合は避難したり嘲笑するよりも難しい。また、建設的な批判を頼むことも難しい。
建設的な批判をしてくれる相手を見つけたら、手放さないようにしたい。

アンチパターン：パフォーマンスの低い人を無視する

多くのチームリーダーは、歯を食いしばって目を背け、パフォーマンスの低い人が奇跡的に成長するか、どこかへ行くことを願っているだけだ。いずれの可能性も極端に低い。

パフォーマンスが低い人を放置することは、チームにとってはボトルネックになるので無視できない。「ザ・ゴール」にも書かれていたように、他の人がどれだけ高パフォーマンスを発揮してもチームのパフォーマンスはボトルネックに支配される。それに、パフォーマンスの低い人が高いパフォーマンスを発揮できる場所へ行く機会を奪うことにもなる。

わかるのだが、とは言っても「はいさようなら」とやめさせられることも多くはないので、実際にどうすべきかは悩みどころである。 そこで、特に参考になったのは「ではどうやってパフォーマンスの低い人をコーチングするのか」である。

「三本柱」がちゃんとある前提で、期限を設定して課題を決め、小さな成功を何度も経験させるといいらしい。うまくいかなければ、うまくいかないことが ２人に わかるし、うまくいけばそのまま改善させられるかもしれないということだ。ボトルネックに働きかけるということね。なるほど。

さいごに

この本に書かれているいい話はすごくたくさんあって、まぁすごくたくさんあるので紹介しきれないからこのあたりにしておこうと思う。
「チームをうまくやる」本ではあるが、「チームでうまくやる」ためにも役立つし、本当にギークじゃなくても役に立つと思う。
エンジニアに何も言わずに「リーダブルコード」をおすすめするように、誰でも一度は読んでみてほしい一冊です。

Team Geek ―Googleのギークたちはいかにしてチームを作るのか

「ザ・ゴール - 企業の究極の目的とは何か」

ザ・ゴール ― 企業の究極の目的とは何か

読書感想文である。

よくおすすめされるので、本の圧倒的分厚さに恐々としながらも読んでみることにした。

この本では、閉鎖の危機に直面したある工場を、業界一と言えるほどの利益を出すまでに復活させるといったストーリーが用いられている。 私事だが、この一年間この本に取り上げられているような工場を対象にしたソフトウェアを開発する仕事をしていたので、機械の名前や工場の様子など、親近感がわいた。

1. 「今本当に目指しているものはなんなのか」をしっかりと定義すること.
2. ボトルネックを見つけ出し、スループットを改善する.
3. 生産だけでなく、営業なども含めて全体をみるべきである.

読書感想文なので、今年の仕事を振り返りながら本書の内容と照らし合わせてみる。

本当にやらなければならないこと

まず、（特に）スタートアップにおいては、本当にやらなければならないこと 以外のことをする余裕はないから、物事の優先順位を決め、「時間をかけるべきところ」、「かけるべきでないところ」をしっかりと見極めていく必要がある。
もちろんいつまでも同じところに時間をかけるべきではないので、本当にやらなければならないことは定期的に考え直す必要がある。

ボトルネックの改善

我々のチームではITスタートアップらしくSlackを使ってリモートワーク中のコミュニケーションを行っていた。チャットコミュニケーションに慣れた開発チームではSlack上の会話は弾んでいたが、これは開発チームだけでのことであった。
というのも、当初なぜかSlackのチームは「開発」と「プロダクト・営業」でまるっきり二つに分かれていて（全員で10人にも満たないのに）、その間をつなぐ人間は１人しかいなかったのである。
その結果、プロダクトチームから出された要求が１人を通して開発に伝えられ、開発から上がった質問や提案がまたその一人を通してプロダクトチームに伝えられるといった構造を作り出していた。
この本ではボトルネックとは、「スループットを決定する制約条件」とされていてある機械が取り上げられていたが、我々のチームにおいてはまさにSlack上のコミュニケーションがボトルネックになっていたのであった。
今ではSlackのチームはひとつに統合され、雑談や仕事に関係のない日記に近い日報を書いたり、お互いのチームの会話がお互いに見えるようにしたりといった取り組みをして、お互いがお互いの考えていること、仕事ぶりを理解してかなり円滑に物事を決定できるようになったと感じている。

個々の最適化だけでは意味がない

この本を読んだのは今年の最後なので結果論的ではあるが、上で述べたとおりSlackチームを統合したことが全体の最適化に一役買ったと感じている。
営業と開発は全く別の仕事なので、お互いの仕事にお互いが口を出しにくいし、知見やレポートが共有されにくいが、せっかく10人程度の規模なのだから、積極的に共有していくように働きかけた。 結果、客の要求に対して開発チームから提案ができるようになったり、営業チームではみんなで一つのエクセルシートに書き込んでその管理に難儀していたりしたのを、開発チームが使っているツールを使って円滑にレポートを共有できるようになった。

さいごに

冒頭で述べた仕事はまさに今年から動き始めたスタートアップ企業でのことで、ほぼ創業当時から関わってきた。特定のオフィスをもたず、基本的にみなリモートワークで進めている。 もちろんソフトウェアを作っているので工場の改善をしているのとは訳が違うが、がむしゃらに頑張ってきた今年を振り返るのにいい一冊であった。

ザ・ゴール ― 企業の究極の目的とは何か