本記事は、「パッケージソフトウェア開発 Advent Calendar」24日目の記事です。
パッケージソフトウェア開発 Advent Calendar
http://qiita.com/advent-calendar/2014/packagesoftdev
私はパッケージソフトウェアの開発に数年携わった後、サポートエンジニアになり、以降10年近く続けています。その立場から、パッケージソフトウェアの開発とサポートの違いと、サポートで必要なことについて、考えたことを書きます。
なお、パッケージソフトウェアが一度リリースされると、作業を開発とサポートに区分することは難しくなりますが、ここでは新しい技術を使ったり新しい機能をつくることを「開発」、開発した機能を使用して発生した問題を解決することを「サポート」とします。
違いを説明するためには例が必要ですが、個人の経験から具体例を引くといろいろと問題が起きそうなので代わりにマンガを例にします。「開発」の例として紹介したいのが「スティーブズ」です。
「スティーブズ」と「開発」
「スティーブズ」は1970年代のシリコンバレーを舞台に、スティーブ・ジョブズ、スティーブ・ウォズニアックがパーソナルコンピュータを開発して、世界を大きく変えていく姿を描く、事実を元にしたフィクションです。
現在のようなIT業界どころか、パーソナルコンピュータという概念さえ一般的ではなく、一部の電子工作マニアの趣味に過ぎない時代です。いくら革新的なものを作っても、実績や信用を重んじる従来のビジネスのやり方では必要な部品も資金も人材も集めることができません。ウォズニアックが卓越した技術力で画期的なコンピュータを設計する一方、ジョブズは慣習やマナーに囚われない自由な発想で、一癖も二癖もある業界の大物に直談判して立ちふさがる難題を解決していきます。
二人のスティーブがパーソナルコンピュータを開発していく中で一番盛り上がるのが、ジョブズに口説かれてエンジニア、デザイナ、プログラマという各分野のライトスタッフが集結してくるシーンです。目標を共にするものたちが力を合わせて、目標を異にするもの、旧来の慣習に縛られた大企業や保守的な投資家を押し退けて、あたらしい市場をつくりだす（ジョブズはこれを「宇宙をへこます。」と表現します）。
いままでにないものをつくる「開発」は、仕事の成果に応じて利益も大きくなる加点方式です。このため、みんなで力を合わせて、なるべく早く、できるかぎり高い品質で問題を解決することが合理的な選択になります。
「マージナル・オペレーション」と「サポート」
「サポート」ではどうでしょうか。こちらも「マージナル・オペレーション」というマンガ（小説が原作ですが、私はマンガ版だけ読んでいます）を例にします。
「マージナル・オペレーション」は近未来の日本で、勤めていた会社が倒産したゲーム好きの元ニートが民間軍事会社に再就職して、現場で兵士を率いる指揮官（オペレータ）に管制室から指示を出すオペレータ・オペレータになり、紛争地帯に派遣されて治安維持活動に関わる話です。
このマンガで描かれるオペレータ・オペレータの仕事は、パッケージソフトウェアのサポートと似ています。問題は常に突発的に発生し、数日から数時間、緊急の場合には数分の間に、解決策の提示を求められます。また、問題発生時に現地に居るわけではないので、対応のために与えられる情報は制限されます。そして、仕事に失敗すると損害が出ますが、成功しても損害を抑えられるだけです。
失敗するとマイナス、成功すればゼロ。この場合、評価は減点方式になります。ここが「開発」と「サポート」の違いです。減点方式では、問題解決の品質よりもリスクの回避やコストの削減が優先するほうが合理的とみなされる場合があります。
主人公が勤める民間軍事会社では、損耗率が高い任務には安価に調達できる兵士をアサインして使い捨てにしていました。主人公は道義的な問題を感じますが、ビジネスなのでただ「止めろ」とは言えません。このため、犠牲となるはずの兵士を効果的かつ安全に運用して事態を終息させる、より合理的な代替案を立案して、上司やクライアントを説得します。
「マージナル・オペレーション」のクライマックスは、「スティーブズ」のように、みんなで同じ方向を見て力を合わせるシーンではありません。道義などの前提が共有できない状況で、関係者全員の事情を伺いながら考えた落としどころに向かって、事態を終息させるシーンです。私が経験してきた「サポート」でも、同じような場面を多く見てきました。
「サポート」として必要なもの
パッケージソフトウェア開発 Advent Calendar 2014の18日目の記事、「カスタマーサポートを支える開発者として考えた事」では以下のような一節がありました。
問い合わせの根幹には困っている人がいて、それを解決したいというのは
エンドユーザー・代理店・サポートチーム・開発チーム全てに共通の目的のはずです。
困っている人の問題をより良い形で解決するべき、というのはこの上なく正しいモラルです。しかし、上記の記事でも触れられている通り、そのモラルよりも自分の都合を優先する人もいます。
モラルが共有できない（ように見える）人がいることで、技術的な問題解決よりも調整や説得を優先しなくてはならない場面も出てきます。エンジニアとしてはたいへん非効率に思えますし、モラルを共有するべきだと憤ることもありました。
でも、この文章を書いているうちに、モラルの共有にこだわっても仕方ない、と思えるようになりました。
「スティーブズ」を読んだとき、私は慣習やマナーを軽々と飛び越えていくジョブズに喝采を送ります。咎める人がいたら「でも彼はすごいことをしているのだから」と答えるでしょう。慣習やマナーもモラルと同じように「そうするべき」という規範です。何かを成し遂げるために障害となる規範を無視してかまわないと考えているのなら、または、そのようなやり方で発展した業界で職を得ているのなら、自分だけが誰かに規範を押しつけられると考えるのは、合理的ではありません。
必要なのは、現実的な対策を考えることです。
たとえ飛び越えられてしまうとしても、やはりモラルは必要です。モラルは旗印で、人を集めてまとまった仕事をするためにはどうしても必要です。ただし、それだけでは足りません。まず発生した問題を解決する力が必要です（さいわい「サポート」では既に開発されたものが基になるので、「開発」と比較すれば問題解決はパターン化しやすく、習得もしやすいです）。それでもまだ足りません。説明や交渉する力、問題を発生させる体制やシステムにも問題がある場合に、調整して変えていく力も必要になります。
説明、交渉、調整はパターン化が難しく、私もまだどうするのが最適なのか分かっていません。まずは、自分の仕事について、責任範囲、コスト、効果を把握すること。問題の解決に関して、実工数、利益率、定量化した他のタスクへの影響など、客観的な指標を揃えておくこと。それらを以て、適切なところ、適切な内容で問題が処理されるように話し合うこと。このあたりから着実にやっていきたいと考えています。
#参考資料
うめ,松永 肇一（2014）『スティーブズ』小学館 （公式無料配信サイト）
芝村裕吏,キムラダイスケ(2014)『マージナル・オペレーション(1)〜(3)』講談社 （公式無料配信サイト）
「ブレイキング・バッド」を読み解く ５．エンパイア・ビジネスとモラルの問題