システムの運用においてトラブルの対策を考える際、インパクトが大きいトラブルに対しては大きな労力を、そうではないトラブルに対しては小さな労力をかけるのが効率的です。
ここで、ホビーの売買サイトの運用を例に挙げて説明します。
例えば、エンドユーザーが直接触る画面において、金額計算を間違えてしまった場合、直接クレームに繋がってしまいます。
このようなインパクトの大きいトラブルの発生が想定される場合、予め念入りにテストしたり、本番リリース後にもテストを行ったりして、トラブル発生を防ぐために大きな労力をかける必要があります。
その結果として、実際にそのようなトラブルが起こる可能性は小さくなります。
逆に、管理者しか触らない画面において誤字がある、という程度のトラブルであれば、謝罪して修正してリリースすることで、大事にならずにトラブルを解消することができます。
このような軽微なトラブルについては前述のような念入りなテストを行ったり体制を用意する必要性は薄く、他のトラブルの対策に労力を割いた方が効率的になります。
----
しかし、トラブルのインパクトの大きさを過小評価してしまった場合、本来かけるべき労力をかけずに、高確率で大きなトラブルが発生してしまいます。
例えば、１日の売上記録を他システムへファイル連携するバッチ処理を想定します。
当該の他システムが開発中であり、その他システムではただファイルを受信しているだけであれば、ファイルの中身が誤っていたとしても後で時間をかけて検証して修正すれば、大きなトラブルになることはありません。
このトラブルで済むのであれば、開発者が作成したデータでテストで済ませ、リリース後も後で時間をかけて結果を検証する、という程度の労力でも通常は問題ありません。
しかし、開発中でファイル未取り込みだと思っていた当該の他システムが、実はファイル取り込みも行っている、しかも管理者がシステムテストのために処理結果を見ている、となった場合、システムテストのスケジュールに影響を与えてしまうというトラブルになってしまいます。更に、取り込んだデータの修正も必要になるため、リカバリーにも時間がかかるという厄介なトラブルになってしまいます。
このレベルのトラブルになってしまうのであれば、本番データを想定したテストを事前に行い、リリース時も事前にファイルを出力し、出力結果に問題がある場合はファイル送信を差し止める、といった対応が必要になります。
前述のような少ない労力の対策では、本番で厄介なトラブルが発生する確率が高くなってしまいます。
----
このように、トラブルのインパクトの大きさを過小評価してしまうと、大きなトラブルに発展してしまう可能性が高まります。
それを防ぐために、トラブルのインパクトの大きさは予め有識者に確認しておく、確認できない場合は大きなトラブルが発生することを想定して労力をかける、ということが必要になります。
ラポール形成とは
ラポール形成とは、相手との信頼関係を築くことで、コミュニケーションを円滑に進められるようにするためのテクニックです。
元々カウンセリングのテクニックですが、ビジネスにも応用可能です。
----
自分の立場からの意見を通したり、アドバイスにより相手の行動を変えて欲しいと思っていたりする場合、正論や成功体験を一方的に語るだけでは反感を買うだけとなり、聞き入れてもらえません。
そこで、相手の話を聞き、相手の立場に理解し共感することで、心理的な信頼関係を最初に築くことが重要になります。
まずは、相手を尊重し、相手の言うことに耳を傾けることが重要になります。
その際、相手の言うことを否定せずに、相手を理解しようとすると良いです。
（たとえ、自分の立場や信条、価値観、といったものに相いれない話だとしても、一旦理解することに努めて下さい）
社内外や家族の人間関係のような、プライベートな話までしてくれるようになるのが理想的です。
自分の意見を発したりアドバイスをしたりするのは、このようにして信頼関係を得てからです。
信頼関係を得てからであれば話を聞き入れてもらいやすくなりますし、相手の立場や心理状態に合わせた形でより適切に意見やアドバイスができるようになるという副次的なメリットもあります。
----
例えば、TOEIC高得点を取りたがっている新人エンジニアに対して、自分は基本情報処理技術者試験を優先して欲しいと思っているとします。
ここで、頭ごなしに基本情報処理技術者試験を優先するように言うのはNGです。
その代わり、まずはなぜTOEIC高得点を取りたがるのかを聞く必要があります。
そうすると、「今は海外のエンジニアと仕事するのが当たり前なのでTOEICを勉強したい」のような回答が返ってきます。
その気持ちを尊重した上で、「国内で実績を重ねないと海外でも相手されにくい。まずは基本情報処理技術者試験でエンジニアとしての基礎を固めて、国内で実績を重ねてから、海外のことを考えた方が良い」のような形でキャリアパスを提示しながら基本情報処理技術者試験を勧めると、聞き入れてもらえる確率が高くなります。
人間は学び始めの時に自信過剰に陥りやすい
表題の通り、人間には、学び始めの時に自信過剰に陥りやすい、という特徴があります。
一般的に、ある分野について学び始めた時は自信過剰になり、更に学ぶとその分野の知見の深遠さに気付き自信がなくなる、そしてそれ以降は徐々に自信がついていく、という経過をたどります。
これは心理学の用語で「ダニング＝クルーガー効果」と呼ばれます。
知識・経験の程度と自信の高低については、以下の表が分かりやすいでしょう。
----
IT分野においては、IPAの高度情報処理技術者試験（ネットワークスペシャリスト試験、データベーススペシャリスト試験等の総称）を若手の内に合格して自信過剰になる、というのが分かりやすい例でしょう。
高度情報処理技術者試験は確かに各々の分野の最高峰とされる資格ですが、実際にはこの資格に合格するだけでは以下の知見を身につけることはできません。
・製品固有の知見
・最新の知見
・現場固有の知見やアドホックなテクニック
高度情報処理技術者試験に合格するとその分野については極めたと感じて自信過剰になってしまいがちですが、実務経験が伴っていないと上記のような知見が抜けてしまいがちなため、「各々の分野のスペシャリストになるための下地が身に付いた」というのが正しい理解です。
----
自信過剰に陥ると、その分野に精通している人物から実力を低く見られてしまうので注意が必要です。
例えば、SESの面談の時に「○○はできますか」とスキルを確認する質問をされることがありますが、ここで自信満々に「できます！」と答えてしまうと、自信過剰である（実力的に未熟である）と見られてしまう可能性があります。
その分野についてある程度勉強していたとしても、自分が知らない知見があることを常に考えて、謙虚になるのが重要です。
開発現場における傍観者効果とそれを防ぐ方法
ITの開発現場で活用できる心理学の知見の紹介です。
今回紹介するのは「社会的手抜き」と、社会的手抜きの一つの具体例である「傍観者効果」です。
----
社会的手抜きとは、集団で一つの作業を行う時に、各々の個人のパフォーマンスが一人で作業する時のパフォーマンスよりも悪くなるという事象を指す言葉です。
パフォーマンスが下がる理由については様々な説明がされていますが、「個々人のパフォーマンスが低下していることを責められない状況下で、他人のパフォーマンスに頼ってしまう」という点では共通と言えるでしょう。
社会的手抜きの説明については、WikiPediaの説明（https://ja.wikipedia.org/wiki/%E7%A4%BE%E4%BC%9A%E7%9A%84%E6%89%8B%E6%8A%9C%E3%81%8D）が詳しいです。
傍観者効果とは、社会的手抜きと同じような理由により発生する事象の一つです。
ある作業の必要性が発生した時に、それを傍観する多くの人がいる場合に、皆が傍観してしまい誰もその作業をしなくなってしまうという事象です。
傍観者効果の説明についても、WikiPediaの説明（https://ja.wikipedia.org/wiki/%E5%82%8D%E8%A6%B3%E8%80%85%E5%8A%B9%E6%9E%9C）が詳しいです。
----
傍観者効果は、ITの開発現場でも起こり得る事象です。
例えば
・あるタスクが発生しても誰も手を付けようとしない
・メンバー全員にある質問をしても誰も回答してくれない
といった事象は、傍観者効果と言える事象です。
傍観者効果が発生しないようにするためには、一人一人の役割を明確にして、その役割を遂行したかどうかを確認するのが有効です。
先の例で言うと、以下のように立ち振る舞うことが有効です。
・タスクを細分化し、期限を設けた上で一人一人に細分化したタスクを割り振る
・一人を指名して質問する（わからない・時間がないなら、その旨を回答してもらう）
要件が不明確な場合は慎重に見積を行うべきである
経営や営業の都合では、開発者が直感に基づいて迅速に案件の見積をしてくれると助かります。
見積が早く出てくれば、案件の優先順位付けや案件の受注もスムーズに進むようになり、利益も出しやすくなります。
要件が明確で見積時点で具体的な実装がイメージできるようであれば、これで問題無く回ります。
しかし、ここに要件が不明確な案件が混ざり込んだ場合、見積時には想定していなかった要件調整や影響範囲拡大が発生し、見積から大きく工数が膨れ上がり、利益が出ず長時間労働を強いられる炎上案件と化してしまいやすいです。
（要件が明確かどうかは、コードに落とし込めるレベルで実装をイメージできているか否かで判断すると良いです）
このような見積誤りを防ぐためには、一つの開発者が直感で見積を行っている状態から脱する必要があります。
一般的に見積に時間がかかるようにはなりますが、そこで時間をかけることで案件が炎上するリスクを減らすことができるため、時間をかけるだけの価値はあります。
具体的には、以下のような方法により、見積の誤り（過小見積）を減らしやすくなります。
・複数人で要件読み合わせや積算レビューを行う
それぞれの開発者には得意不得意や経験の違いがあるため、
見積時に感じやすいリスクにも違いがあります。
そこで、複数人で要件読み合わせや積算を行うことで、
事前に見つけるべき要件の問題点や影響範囲拡大の可能性を見つけやすくなります。
・客観的な見積手法を用いる
具体的には、ボトムアップ見積や類推見積といった手法です。
これらの客観的な見積手法を用いた場合、
見積に時間がかかるようになり、
またある程度は直感に頼らざるを得ない面もありますが、
積算時に見つけるべきリスクに気付くきっかけを得られます。
・後工程での再見積を提案する
要件が不明確な案件では、積算と実際の工数にブレが生じやすいです。
要件の不明確さがクリアされブレが生じにくくなった段階で精度が高い見積を出す、
ということが可能であれば、それを提案した方が良い場合もあります。
・直感で出した見積に一定の係数をかける
どうしても積算に時間がかけられないのであれば、
積算時に見落としが発生することを見越して、
直感で出した見積に一定の係数をかける、という方法もあります。
あくまでも個人的に見聞きした範囲ですが、
一般的には1.5～3.0倍の係数をかけると上手く行くことが多いようです。
不確実性コーンの理論では最大4.0倍の工数上ぶれが発生するので、
係数は最大でも4.0倍とするべきでしょう。
新たな状態が発生する修正は影響が大きい
既存のシステムの機能拡張の見積もりを行う際、その機能強化による影響の大きさを正しく把握する必要が肝要です。
影響の大きさを把握する上で、もし新たなデータの状態が発生するような修正をするのであれば、その修正の影響が思いの他大きくなることを警戒する必要があります。
例えば、セミナー予約用のWebシステムを考えてみます。
既存のフローは以下の通りであるとします。
①見込客がシステムのアカウントを取得する
②主催企業が見込客にDMを送信する
③見込客がDMに書かれた候補日時の中から一つを選び予約完了
それぞれの時点での見込客のデータの状態は以下の通りであるとします。
①DM送信済みフラグ＝偽、日時選択済みフラグ＝偽
②DM送信済みフラグ＝真、日時選択済みフラグ＝偽
③DM送信済みフラグ＝真、日時選択済みフラグ＝真
ここで、DMの内容を取り消しし①のフローに戻せるようにする、という機能拡張を行うとします。
この際、「DMの内容の取り消し」を「DM送信済みフラグを偽にする」と実装してしまうと
・DM送信済みフラグ＝偽、日時選択済みフラグ＝真
というこれまでになかった状態が発生する可能性が出てしまいます。
（③の状態でDMの内容を取り消しすると上記のような状態になる）
そして、既存のプログラムで、「日時選択済みフラグが真の場合に③のフロー上にいると判断する」というロジックが存在する場合、それらのロジックは全て修正対象になってしまいますし、新たに発生したデータの状態を各プログラムでどう扱うか、ということも考慮する必要が出てきてしまいます。
このように、新たなデータの状態が発生するような修正は、見た目の修正規模と比べて影響が大きくなる恐れがあります。
影響を小さくしたいのであれば、これまでに存在していたデータの状態のみを使って機能拡張を実現できないか、を考えることが重要です。
（今回の例では、対象のデータに対して「日時選択済みフラグを偽にする」という操作も行うか、対象のデータをコピーして新たなデータを作成した上で新たなデータを「DM送信済みフラグ＝偽、日時選択済みフラグ＝偽」にするか、のどちらかの対応を考えた方が良いです）
作業を上手く依頼するコツ
何かしらの作業を行う際、自分一人で作業するとなると、どうしても時間的・能力的に限界がありますし、得意不得意もあります。
一方、手が空いている人や、比較的重要ではない作業をしている人が周囲にいることも少なくありません。
このような場合、自分が持っている作業を上手く依頼できると、全体としてより多くの作業が良い質でこなせるようになります。
----
ここからがこの記事の本題です。
作業を依頼するにはコツが必要で、依頼の仕方を間違えると、上手く作業をこなしてもらえなかったり、作業に対するモチベーションを下げてしまったりすることもあります。
上手く作業を依頼するには、以下の２つのことを心がけると良いです。
・無理なく作業できるように依頼内容を考える
・快く作業してもらえるように依頼の仕方を考える
ここで、リーダーが、Webシステムの総合試験で発見されたバグの調査をメンバーに依頼する場面を考えてみます。
まず、システムのことを広く理解しているリーダーが、バグの原因の一次切り分けをすることが重要です。
どのプログラムに原因がありそうか、どのロジックに原因がありそうか、といった一次切り分けをしないと、原因調査を依頼されたメンバーが原因調査に時間がかかってしまい、担当範囲外の箇所が原因だと調査できないと言われてしまうこともあります。
次に、メンバーに快く作業してもらえるように依頼の仕方を考えることも重要です。
上から目線にならずに、あくまでも役割分担であることが伝わるようにすることが肝要です。
今回のケースでは、「細かい所は自分よりも理解しているはずだから、細かい所を見て欲しい」と依頼すると良いでしょう。
仮にリーダーよりも細かい所の理解が浅かったとしても、役割分担しながら仕事を進めていく内に、いずれ本当に細かい所の理解でリーダーを超えるようになり、仕事を進めるのが楽になるでしょう。
