www.shoeisha.co.jp
過去にアリエル・ネットワーク (以下アリエル) という会社で働いていました。これはもう10年前の話で、アリエルはオンプレミスで運用するパッケージベンダーの会社だったので、昨今の SaaS のようなプロダクト開発とは状況が大きく異なります。そういった時代背景の違いを考慮して本稿を読むように注意してください。
当時の課題管理や開発方法論が、その前もその後も、10社以上、十数の開発チームで働いた私の経験の中ではもっとも開発の生産性も開発体験 (Developer Experience) も優れたものでした。
たまたま、というよりは、私がお願いして、当時の上司と雑談してみました。当時のアリエルの課題管理システムには、自社パッケージの開発に関する内容 (プロダクトの機能開発や不具合など) だけでなく、顧客からの問い合わせや開発者のTODOやシステム管理のメモなど、会社の多くの情報が入っていました。プロダクト開発に関するすべての情報はたった1つのプラットフォームに集約されていたので情報の一元管理という視点からみると非常に強力なプラクティスでした。
多くの情報が課題管理システムに入っているので、営業もコンサルタント (アリエルでは顧客と開発者の仲介役) も、マネージャーも開発者も、そのチケット上でコミュニケーションをしていました。最近だと、チャットツールで他チームや他部署の人たちとコミュニケーションを取ることが多いと思いますが、アリエルでは課題管理システム上のチケットで行われていました。当時も Skype のグループチャットはあったものの、課題管理システムがコミュニケーションのメインで Skype はアナウンスなど補足的な用途でした。
そんな話題を上司としていたとき、あのやり方は Joel on Software に由来するのだと教えてもらいました。具体的には次の記事です (この記事は本書には含まれてなかった) 。
www.joelonsoftware.com
そんなきっかけで、私が Joel on Software に興味をもち、本書を読んでみた次第です。本書は2000年代に書かれた内容を出版したものなので、いまとなっては古典のような内容も多いです。とくに特定の技術について言及している内容は、当時の状況ではそうみられていたんだなとか、歴史的な読みものとして理解することも多いでしょう。本稿ではなるべくいまでも通用しそうな内容に絞って紹介することにします。私はいまマネジメントに関心があるのでその内容が多くなります。
第2章 優れた開発者を見つけるには
基本的に転職市場には優れた開発者がいないという前提を述べた後、次の方法を提案しています。
こちらから出向く
- ホットな新技術のカンファレンスに出かけて廊下をぶらぶらして会う人に声をかける
- 優秀そうな人をみかけたらスカウトする
インターンシップ
自分のコミュニティを作る
- 似た考えをもつ優秀な開発者のコミュニティを会社の周りに作り上げる
- できればうまくいくが、コミュニティを作るのがとても難しい
これらはいまでも採用活動の一環として行われているようにみえます。最後のコミュニティを作るというのは、多くの会社がテックブログを書いていて、読者となる開発者の興味・関心を集めようとしているのがもう少し簡単な施策かなと思います。
またリファラル採用について、著者はそれほどこの採用方式を信用していないと述べています。
- 優秀な社員が優秀な開発者の友だちをもっているのは事実だが、優秀じゃない友だちもたくさんもっている
- 不採用になると友人関係にヒビが入るから本当の友だちを紹介しようとしない
- 最初の採用プロセスをパスする程度で新規採用のソースとしては最も弱いもの
- あくまで通常の採用プロセスをすべて通過するかどうかを判断基準にしている
リファラル採用よりも自社の採用プロセスを重視していることが伺えます。リファラルによって採用のバーが変わらないという点が大事なのかなと私は理解しました。
第3章 開発者観察ガイド
同僚はどんな人たちか？
著者がマイクロソフト社からもってきた採用ルールに、自分たちが付け加えたルールが次になります。
嫌なやつでないこと
アリエルの CTO もたしか飲み会のときに「アリエルの開発には嫌な人がいない」が仰っていた気がします。私も辞めるときにそのことを意図的に書いているので間違いないです。
開発者の視点からみたとき、一緒に働いている同僚に嫌な人がいなくて、同僚の技術スキルが高いというのが魅力的です。
アリエル・ネットワークを退職しました - forest book
昨今ではコンプライアンス対策からハラスメントを禁止する風潮もあり、若い人にとっては嫌な人がいないのが当たり前の職場しか経験していないかもしれません。それはよいことだと思います。いまは、技術スキルが高くて優秀な嫌な人になるのが難しい属性になっているように私は思います。それは技術の発展に伴う多様化・複雑化が要因の1つではないかと考えます。
2000年代はまだ1人の開発者がその事業部やチームがやっている技術の大半を把握しているといったことが、いまよりは可能でした。嫌な人だけど、技術スキルが高いから誰も文句言えないといった人が職場にちらほらいた気がします。
いまは技術の要素が多岐に渡り、それぞれが専門化・分業化したことでその事業部やチームがやっている業務すべてに熟達するのが難しくなっています。特定分野の技術スキルが高くても、他チームと協調したりお願いしたりすることが昔より増えました。結果として、嫌な人は活躍できなくなってしまい、そういう態度を取るデメリットの方が大きく、採用時点でも嫌な人特性を排除することを重視するようになり、いまでは淘汰されてしまったのではないかと私は思います。
いまは逆に、心理的安全性の文脈で、同僚に適切な厳しい指摘をするのが難しくなってしまった雰囲気はありますが。
誤解を招く表現だったので補足します。本来の心理的安全性の文脈では、同僚同士で適切な厳しい指摘をし合える関係のことを指します。しかし、それはお互いの信頼関係が前提になっています。そうじゃない状況において相手を尊重し、信頼関係を築いていくことから始めるでしょう。問題なのはそれがずっと続いてしまい、そのまま、ぬるま湯のチームが出来上がってしまうことです。メンバーが誰も厳しいことを言わないチームは永遠に問題ばかりをエスカレーションして、ビジネスの問題解決力に劣ったチームになってしまいます。
独立性と自律性
この考え方は、会社や組織、チームによっても解釈が変わってきそうな気がします。著者は優秀な開発者を次のように扱うべきだと述べています。
基本的に、頭の良い人を雇おうとするなら、彼らがその能力を仕事に適用できるようにしてやる必要がある。マネージャはアドバイスできるし、自由にそうしてかまわないが、その「アドバイス」が命令と受け取られないよう、細心の注意を払う必要がある。
(中略)
開発者は自らの能力によって雇われ、専門家として遇され、その専門領域に関しては決断させてもらえることを望んでいるものだ。
先日、上司と雑談したときも、課題管理システムの他者が担当者のチケットにコメントすると若い人は「命令」と受け取ってしまうのであまりしないようにしているといった話しを聞きました。チームで相談したり議論したりすることは良いことだと思いますが、なにかを決断するとき、その担当開発者が決められるようになっているか。みなさんの組織ではどうでしょうか。
政治がないこと
プログラミングの世界は非常に公正で、非常に厳格に秩序立てられている。そもそもプログラミングの世界に入ってくる人がそうする理由は、多くの場合、公正で、秩序があり、厳格に能力主義で、議論は単純に 正しいほうが勝つ ような場所にいたいと思うからなのだ。
プログラマが「政治」について文句を言うとき、それが正確に意味していることは、技術面よりも個人的な考えが重視されているということだ。
これも営業やビジネス部門がめちゃくちゃな機能や納期を要求してくるといったことは減ってきて、開発者が目の前の課題に集中しやすいようになってきたのではないかと、私の周りではそう思えます。しかし、業界や業種に依るのかもしれません。
彼らはお金を気にかけない。あなたが別なことでひどいことをしない限りは。
誤解のないよう、著者はプログラマの給与を低くしてかまわないということを主張していません。前述した通り、プログラマは公正さを気にかけるので、業務や能力に応じた適正な給与でないと怒りを覚えると補足しています。そのため、本節の内容は適正な給与を支払った上での前提であることに注意してください。
給与よりも業務内容や職場環境の居心地の良さを優先するので、給与の多寡は優先順位が低いことを理解しておく必要性を説いています。もう1つ、興味深かったのは、プログラマがこれまで不満を述べていなかった給与に言及するようになったら、その本音は給与ではなく、やっている仕事に不満をもっているという兆候であると述べています。要はやりたくない仕事をする代わりに見合う対価がほしいといった理屈だそうです。
さらっと書いてあったのですが、ソフトウェア会社の経営者は考慮しておくとよさそうに思えました。
第7章 一体化マネジメント法
著者の知っているマネジメント方法として3つあげています。
- 指揮統制マネジメント法 (軍隊のようなやり方)
- 入門経済学マネジメント法 (経済合理性を重視したやり方)
- 一体化マネジメント法
前の2つもそれぞれ章を割いて説明していますが、本稿では省略します。著者は自分の会社で一体化マネジメント法と呼ぶマネジメントのスタイルを取っているようです。いま聞くと、よく知られたプラクティスが背景に思い浮かぶ人も多いと思います。著者の名誉のために言及しておくと、この記事が書かれたのは2006年8月10日です。
入門経済学マネジメント法でやっちゃいけないマネジメントとして、内発的動機づけを外発的動機づけに置き換えてはいけないと強調されています。例えば、プログラマが自分からやりたいと考え、自律的に行動して改善した行動に報酬を支払うといったインセンティブを与えることです。これは 過剰正当化効果 と呼ばれるそうです。
余談ですが、最近、メタ認知に関する認知心理学の入門書を読みました。この本の中でも動機づけは次のような順番になるのがよいと書かれています。
- やる気のない段階 → 外発的動機づけ段階 → 内発的動機づけ段階
内発的動機づけによる行動に報酬を与えると、内発的動機づけを外発的動機づけに置き換えてしまい、外発的動機づけは内発的動機づけよりもずっと弱い動機になるので意欲を失わせてしまうことにつながるというわけです。その入門書では副作用のない安全な報酬として、ことばで褒めることを紹介しています。ことばで褒めても動機づけは置き換わらないことが知られています。但し、能力を褒めると失敗できないとプレッシャーになってしまう人もいるので、成果そのものを褒めるようにした方がよいそうです。
note.com
著者の言う、一体化マネジメント法は、この内発的動機づけを最大限発揮できるよう、社員の自律的に行動した結果が組織の目標につながるようにマネジメントの工夫をしているということでしょう。そのための施策として著者は次の2つをあげています。
- 昼食を同僚と共にする
- みんなに情報を渡す
後者は「情報の透明性」について言っていて、ホラクラシーやティール組織を成功させる要素の1つにもなっています。私の周りでは、比較的、小規模な組織では原則すべての情報を社員に開示することがプラクティスとして浸透している気がします。意図的にしろ、そうでないにしろ、情報の非対称性は組織の理不尽を増幅してしまうと組織論の本で読んだこともあります。これについてはあまり説明の必要はないでしょう。
前者の同僚と昼食を共にするというのどうでしょうか。私も過去に働いてきた会社では、だいたい同僚と一緒に昼食をとっていました。いま思い返すと、昼食を共にしていた上長や同僚と業務で対立したことがないことに気付きました。私は理屈の通らない業務やマネジメントにはクレームする方だったので、何度か上長と業務で険悪になってしまったこともあります。しかし、一緒に昼食をとっていた上長と険悪になったことは1度もありません。もしかしたら私の性格や考え方を上長が汲んでくれて、私が不満に感じないようなマネジメントをしてくれていたのかもしれません。
これもたまたまかもしれませんが、一緒に昼食を共にしていた同僚とは会社を辞めてからも繋がっていてやり取りしたりすることが多いです。昼食を共にしているうちに仲良くなるのか、仲が良いから昼食を共にするのか、どちらが真であっても、昼食を共にすることが悪い結果をもたらすことはないように私は経験から思います。意識したことはなかったのですが、本章を読んでいて、そういえばと気付いた次第です。
当然、著者もこのマネジメント法は難しく、うまくやるにはある種の深い対人スキルも要求されると述べています。そして、多くの職場では、場当たり的な、日により人により変わる「何でもあり」の方法でマネジメントされているという言葉で締め括っています。大企業では同じ会社でもマネージャーによってマネジメントが大きく異なるのが容易に想像できます。
いくつかあるアドバイスの中で私が関心をもったもののみを紹介します。
卒業するまでに文章の書き方を学ぶこと
最も大きな権力や影響力をもつプログラマは、明確に、説得力をもって、やすやすと書き、話せる人間だ。
まぁまぁのプログラマと優れたプログラマの間にある違いは、アイデアについてコミュニケートできるかどうかという点にある。他の人を説得することで、彼らは力を得るのだ。
日記やウェブログをつけはじめるといい。書けば書くほど、書くのは楽になる。そして書くのが楽になれば、もっとたくさん書けるようになるという、プラスのサイクルができる。
私はいま「書くこと」そのものを再考しています。再考というほど、過去にちゃんと考えたことがあったのか問われると曖昧です。しかし、意識的に書く機会を設け、書く時間を割いて何かを考えるようにしています。あるとき、生産性の低い開発チームをみていて、ふと思ったことがあります。
よいプロダクトはよい開発文化から生まれる。よい開発文化は書くことから醸成されていくのではないか？
私は、いくつかの会社やチームで課題管理システムの利用を推奨し、日々のやっていることをチケットに書くことを促してきました。そして、自然に課題管理システムを使いこなす開発者が半分ぐらいしかいないという現実をみてきました。ここでは書かない人たちの理由は追求しませんが、情報の一元化や情報共有の文脈から書くことのメリットは大きいです。情報の非対称性が組織にとって弊害があることを多くの人が実感しているはずです。それでも書かない人たちはいるのです。
経験則では、書かない人たちと技術の多寡は相関がありません。そして、いま思い返すと、書かない人たちはチームで孤立しがちになります。これは周りが避けているわけではなく、その人は何をしているのか、何を考えているのかわからないので必然的に協働する機会が減り、結果として接する距離が縮まらないせいではないかと思います。
口頭と文章によるコミュニケーションでは次の特性があります。
- 口頭: 同期的で複雑ではない内容に対して数人程度でしか成り立たない
- 文章: 非同期でも可能で、複雑な内容も不特定多数へ伝えられる
つまり、口頭によるコミュニケーションコストはとても高いということです。そのため、チームのメンバー間で毎日やっていることや業務で考えていることを口頭で双方向に共有することは現実的にできません。例えば、それを課題管理システムのチケットにコメントとして書き込むのであれば、それぞれのメンバーの余裕のあるときに読めるのです。無論、読むかどうかはメンバー次第ですが。
その日々の積み重ねが中長期で開発の生産性をあげたり、チームの協調性を高めていくのに役立ちます。そのためにはメンバーが自律的に書ける必要があります。
もう1つ書くことのメリットをあげてみます。
後藤貴子の米国ハイテク事情 は Alan Kay 氏へのインタビューの内容です。その中で次のことを発言しています。
過去1世紀の電子技術のほとんどは退行的だ。というのは電子技術の多くは書くことよりオーラルコミュニケーションを奨励するからだ。昔、人々に読み書きを強いた多くのものは今は存在しない。楽しみのために読まなければ、恐らく必要になったときには読む鍛錬が足りていないだろう。書くこともどんどん不要になっている。将来はもっと、コンピュータが、“学ばないこと”の言い訳になるかもしれない。米国の多くの学校は、子供がGoogleで何かを見つけコピーすると、それで学んでいると思っている。しかし私は、子供がそれについての作文を書かない限り学んだことにならないと主張している。作文は思考を組織化する。単に博物館の展示物を集めるだけではない。しかしほとんどの学校はその違いを分からない。
氏は「作文を書かない限り学んだことにならない」と主張しています。書くことは記憶の定着とも関連するので学びの質を高めるように読めます。もし学んだことを自分の言葉で書けないのだとしたら、その内容について理解が欠けていることを自身で容易に判断できます。
これは私自身への戒めとして、このブログのアーカイブ数をみると、2009年から年間の記事数が減っていっていることがわかります。この理由の1つに、勤めていた企業のテックブログや他のプラットフォームで記事を書いたりしていたこともあげられますが、近年、私は書くことを軽視している傾向がありました。学びが減っているのと怠惰になっていることの両方あると考えています。
ミクロ経済学はビジネスで重要な理論すべての基礎となっている。需要と供給とか、競争優位とか、NPV とか割り引きとか限界効能について知らなければ、ビジネスの仕組みが全然理解できないからだ。
マクロ経済学は、当たっているよりもはずれていることの方が多い。スキップしてよい。
ビジネスの基礎を理解しているプログラマは、理解していないプログラマよりもビジネスにおいてずっと価値が高いからだ。
私自身、いま会社の経営も考えたりするので経済の基本的なことをもっと昔に学んでおくべきだったと振り返っています。著者によるとミクロ経済学より先の経済学はどんどん悪くなっていくのでやらなくてよいとのことです。本節を読んで入門本を読んでみようと思いました。後述する第34章でソフトウェアの価格づけを考察するときにミクロ経済学の用語も出てきます。
仕事がみんなインドに行ってしまうと心配するのをやめること
第1にビジネスの現在の流行に基づいて職を選択するというのはばかげている。第2に、仮にすべてのプログラミングの職がインドや中国に行ったとしても、プログラミングというのは、ビジネスプロセスエンジニアリングになる。第3に、これは信じてもらいたいのだが、非常に優れたプログラマというのはアメリカでもインドでもすごく不足している。
オフショア開発 - Wikipedia によると、1970-1980年代ぐらいにオフショア開発という移転が始まったそうです。2000年代はオフショア開発する企業が増えてきて、先進国でプログラマーの仕事がなくなるのではないか？という話題もあったように私も思います。しかし、いまはすべての業界の会社がソフトウェアを活用するようになった結果、プログラマの需要はまだまだ衰える様子はみられません。日本においても当面、プログラミングのお仕事は売り手市場になるのではないでしょうか。
そこには (少なくともユーザビリティのプロには) 恐ろしい一片の真実があった: 人々が本当に欲する何か本当にすごいことをやるアプリケーションであれば、無惨なほど使いにくかったとしてもヒットしてしまうのだ。そして世界で最も簡単に使えるアプリケーションであっても、みんなが望むことを何もしないのであれば失敗することになる。
多くの場合、ユーザビリティは実際オプショナルだということだ。
著者の会社は課題管理システムを開発しているので業務アプリケーションに近いパッケージベンダーになります。時代が大きく異なるので当時は見た目や操作性よりも機能の方が重要視されたように私も思います。バックエンドの機能がビジネスの差別化に直結していました。
ちなみにユーザービリティとユーザー体験 (UX) とは別の概念であると次の記事で説明されています。ユーザビリティはソフトウェア側の視点からの、特定のユーザーや用途において使いやすいことを指しているそうです。
ユーザビリティは「モノが持つ品質的特性」（実用的品質）であり、UXは「人が体験する感性的品質」であると言えます。
www.cresco.co.jp
本章で著者が言及しているのは、ソフトウェアデザインの次の段階で、ユーザーインターフェースを正しく作ったら、ソーシャルインターフェースのデザインの方が重要であると言及しています。当時はソーシャルインターフェースのデザインについて系統だった学問はなく、新しい分野なので試行錯誤しているように読めました。
FogBugz では多くのデザイン上の決定が、1人で使っても有用であるようになされている。そしてチームの他のメンバにもだんだんと広まっていくのを促すようにデザインされた機能がたくさん組み込まれている。
FogBugz (課題管理システム) の顧客で、バグトラッキングシステムを全然使っていなかった顧客に FogBugz を導入して常用するようになった事例が紹介されていて、利用者がチームで仕事をするやり方が変わったことによると説明されています。ここでいうソーシャルインターフェースというのは、SNS のソーシャルではなく、チームのメンバー同士が協調する上で必要な機能やデザインを指しているように思います。
当時から10年以上経ってチームで協調して使うソフトウェアは進化したのでしょうか。私からみて課題管理システムに限って言えば、大きな変革があったようにはあまりみえないですね。
第20章 エビデンスベーススケジューリング (EBS)
途中まではアジャイル開発で言うところのベロシティを計測して、その値から見積もりの精度を上げる話しであろうと読み進めていました。課題を小さいタスクに分割し、個々のタスクの見積もりと実際の作業時間から速度を算出します。見積もりが正確であれば、速度は 1.0 に近付きます。例えば、見積もりより2倍の時間を要すれば、速度は 0.5 となります。見積もりと実際の作業時間がずれるのはよくあることなので速度の値がバラけることになります。ここでおもしろかったのが、速度をランダム値として、実際にかかる作業時間をモンテカルロシミュレーションで複数生成して、多少のズレがあってもどのぐらいの範囲の日程で終わりそうかの分布を確率的に求めていくというシミュレーション手法です。
スクラムなどでは次のスプリントで何ができるか、その達成に全力を尽くすというスタイルなのでスプリントを5回やれば何ができているかということは分かりません。著者の提案する EBS はちょっと先の未来を開発者が勘と経験で見積もるより信頼できる予測をモンテカルロシミュレーションで算出するといったものです。私は課題管理システムでこういった機能をみたことがありませんでした。プロジェクト管理の文脈ではいくつか記事が検索にヒットするのでこういった機能があるのですね。見積もりの精度が悪いチームではやってみるとおもしろいかもしれません。
その他、個人的に納得感が高いものが自分のスケジュールに次のためのバッファを用意しておくと述べているところです。
- 新しい機能のアイディア
- 競合への対応
- インテグレーション (他メンバーの作ったものと協調して動くようにする作業)
- デバッグのための時間
- ユーザビリティテスト (および、その結果を製品に反映させる)
- ベータテスト
もしかしたらパッケージベンダーだからこそ可能なバッファなのかもしれませんが、アリエルでも近いスケジュール管理をしていました。イテレーションにおける Feature freeze までの1.5ヶ月に対して必須機能を開発者に割り振り、それらを実装すれば、個々の開発者が (バックログから) 好みの新機能を自由に実装してよいというやり方でした。私の場合、2-3個の必須機能、2-3個の好みの機能、合計で5個前後ぐらいの新機能を実装していました。私の記憶では、3年間で開発チームが必須機能を期間内に実装できなかったのは1つだけだった気がします。つまり3年間でプロダクトとしての機能開発の遅れはほとんどなかったと言えます。
精度の悪い見積もりがためにスケジュールの引き直しを何度もやっているプロジェクトをみかけたことがあります。スケジュール調整のための管理コストもかかってしまうので適切なバッファの持ち方もマネージャーやプログラマに一定の経験を要求するのかもしれません。
第27章 バイオニックオフィス
開発チームのマネージャーはいいオフィス空間がどういうものであるかを知っているが、マネージャーの権限でオフィスを引っ越ししたり改装したりできるものではないのでどうすることもできないものだと考えていると述べられています。著者は経営者なので自分の会社のオフィス空間をいいものにしたいというこだわりが伺える内容でおもしろいです。建築士にブリーフ (ソフトウェア開発で言う要件) として提示した内容が次になります。
- 1人1人にちゃんとドアの付いた個室があることが絶対条件
- コンセントがたくさん必要、プログラマが新しいおもちゃを机の上でつなげられる
- データケーブル (電話、LAN、ケーブルテレビ、警報、その他) を床を這い回らずにつなげられる
- ペアプログラミングが可能であること (L字型の大きい机を用意する)
- 遠くのものを眺めて目を休められるよう窓を設け、ディスプレイを壁に向かって置いてはいけない
- オフィスはそこで時を過ごすのが快適なたまり場のような場所であるべき
現代ではデータケーブルの接続インターフェースはなくてもよさそうですね。一定規模以上の従業員が働く会社では個室は幹部のみでしょうし、最近は社員間の協調を優先してオープンなオフィス環境を重視しているイメージが私にはあります。たまり場について、日本人は休憩用途でたまたまそこにいる人たちとコミュニケーションを取ったりすることはあまりないように思います。それよりも、ちょっとした打ち合わせや小さい勉強会に、普段の会議室とは違う、ややくつろいだ雰囲気で行えるスペースがあるとよいように私は思います。
私はいまシェアオフィスを借りています。ドアのある個室で8割ほど満足しているのですが、2年近く使っていて、唯一不満だと思い始めたのがまさに窓がないことでした。窓がないと1日の時間の経過、天候の変化、季節の移り変わりに疎くなります。直接、業務には関係ありませんが、外から受ける刺激が少なく自然な気分転換にならないように感じるようになりました。次に引っ越しするときは窓のある部屋を借りようと考えています。
フィリップ・グリーンスパンは、はっきりこう言っている。「会社の成功は、ある部分までプログラマが実質オフィスに暮らすようになるかどうかにかかっている。オフィスが平均的なプログラマの家よりも素敵な場所である必要がある。そうする方法は2つある。すごくみすぼらしいアパートに住んでいるプログラマを雇うというのが1つで、もう1つは素敵なオフィスを作るかということだ」
Managing Software Engineers
学生時代に研究室に入り浸って過ごした人たちには馴染みがあるかもしれません。過去、私もオフィスに泊まり込みで働いたこともあったので環境がよいに越したことはないというのは理解できます。私は自宅で仕事をしない人だったので、自宅とオフィスの目的を明確にわけていました。一方で IT 業界ではリモートワークが普及しつつあり、私の周りではオフィスよりも自宅環境が快適で満足しているという友だちも少なからずいます。自宅とオフィスのどちらがよいか、個人差があるかもしれません。
ソフトウェア開発の本でカスタマーサービスについて言及している内容を私はあまり読んだことがないように思います。それだけで希少価値があるように感じますし、実際に内容も示唆を与えるものでした。
問題はすべて2通りの方法で解決する
- テクニカルサポートは開発チームと接触できることが必須、つまりテクニカルサポートはアウトソースできない
- やがて一般的な単純な問題はすべて解消され、奇妙で難しい問題だけが残る
- 新人によくある10種類の対応方法を教えておけばいいわけであはない、デバッグの仕方を教える必要がある
- アリエルでもサポート問い合わせはリリースマネージャーやコンサルが一次受けして、わからないときはエスカレーションされてプロダクトの開発者がシフトで調査していた
ホコリを払うように勧める
- ユーザーに回答するときに言い方を工夫して相手を怒らせないようにするという話し
- キーボードが効かないというユーザーに「ちゃんとつながっていますか？」と聞くと、ユーザーは確認もせずにバカにしているように感じる
- 「接点のゴミがついていると接続が弱くなる。接点のゴミを吹き払ってからつなぎ直してもらえますか？」というと、自然にやってもらえる
顧客をファンにする
- 顧客が問題を抱えている時、それを解決してあげたなら、彼らは始めから問題なんかなかった場合よりもいっそう満足を覚える
- 私も過去にトラブル対応をして逆に顧客の信頼を得たことがあるのでこの考え方は支持します、ピンチはチャンス
責めを負う
- 鍵のトラブルで「私のミスです。」と行った鍵前屋に対して著者は怒りの感情がなくなってしまった話し
- ミスを認めない姿勢や態度そのものにさらに腹が立つという話しに読める
言いにくい言葉を覚えておく
- 顧客からクレームがあったときの返す大事な言葉は覚えておいて、それを言う練習をしておく
- 例えば「私のミスです」、「申し訳ありませんでした。お代は結構です。」
- 心から言っていることが伝わる必要がある。だから練習をするのだ
操り人形の練習する
- 怒れる顧客の相手を感情的に切り抜ける唯一の方法は、彼らが怒っている相手は自分ではないのだということを認識することだ
- 怒られているのは自分という自然人ではなく、会社という法人だと置き換える
- 操り人形のように個人の感傷をなくして謝罪すればいいという話しに読める
- 私の経験では、過去に謝り方の下手な人は自分は悪くないと顔に出ていて顧客を逆に怒らせてしまう人がいた
- 当事者意識をなくさずに操り人形になるスキルは言うほど簡単ではないかもしれない
強欲ではどこにもたどりつけない
- 求人広告サービスで質問なしの90日間返金保証をしてうまくいった話しに読める
- クレジットカードで支払ったときに払い戻しに応じないとき、銀行に電話して払い戻させることができる。これをチャージバックと呼び、事業者側はチャージバック手数料を支払うことになる、たびたび起きると手数料が引き上げられることになる
- 顧客が払い戻しを要求したら結果は同じになるのでもめずにすぐ払い戻しに応じるという話しに読める
(おまけ) カスタマーサービスの人たちのためのキャリアパスを用意する
- テクニカルサポートにはデバッグ能力を要求するため、資質の高い人を配置する必要がある
- 資質に優れた人がテクニカルサポートをしているとその仕事に飽きてしまう
- Fog Creek では3年間のマネジメントトレーニングプログラムの最初の年にだけやる仕事になっている
- キャリアパスの途上にいる野心的で頭のいいギークが顧客と話して問題解決するきっかけになる
- 平均よりもずっと高い単価を支払うことになるが、はるかに大きな価値を引き出している
本章の内容はいまでも通用するように私は受け取りました。カスタマーサービスの問い合わせ内容を重視して、スキルの高い人を配置し、さらにその人たちのキャリアパスも用意しておくということをできているパッケージベンダーは少ないのではないでしょうか。テクニカルサポートは習熟するとキャリアアップのために辞めてしまうイメージが私にはあります。
第34章 ラクダとおもちゃのアヒル
パッケージソフトウェアの価格付けについてミクロ経済学の考え方を応用しながら論理的に考察していきます。著者がソフトウェア開発者も学んだ方がよいと助言するミクロ経済学の勉強にもなりますし、ユーモアのあるの文章で楽しめました。どういった属性の顧客にいくらで販売するのが利益を最大化できるかを次の手法を使って求めていきます。
- 需要曲線
- 消費者余剰
- セグメント化
- 正味現在価値 (NPV)
最終的にどういう価格付けになるのか。これから読む方のために秘密にしておきます。こういった考察を読むことで、ビジネスにおける数字の見方や考え方を学ぶ必要性も理解でき、経済学への興味へとつながるように思いました。本章を読み終えた後に気になって次の記事も読みました。
blog.livedoor.jp
所感
一通り読んで、私が関心をもった箇所を書き出してみました。その過程でアリエルのよかったところが本書でも言及されている内容だったりして思い返すことも多々ありました。2000年代に書かれた本でも、学ぶべきところや時間が経ってもあまり変化がない内容もあります。私にとっては温故知新ということばがぴったり当てはまる内容でした。
