ブログトップ 記事一覧 ログイン 無料ブログ開設

Strategic Choice

2015-04-02

[]曖昧模糊

対象

加害者被害者
ユーザ=>プログラマ

どういうこと?

ユーザから、「漠然とした」「ざっくりした」情報で、仕事の依頼が来ることがあります。

特に多いのが、トラブル解決の依頼です。「Webサイトが壊れた。なんとかしてくれ。」「印刷が正常に作動しない。なんとかしてくれ」などです。情報を聞こうとしても、「何もしてないのに壊れた。なんとかしてくれ。」という答えが返ってきます。

こういった曖昧な依頼は、次の一手が決められないので、対処に悩まされます。

どうして?

ソフトウェアは、ほとんどの場合「決定論的」です。障害が発生した場合、その「原因」を掴むためには、多くの切り分け情報が必要となります。

しかし、ユーザにおいては、そのソフトウェアを作った人は、「すべてを見通しているような、神のような存在である」という誤解があります。

そのような認識があるため、ユーザに「その問題を再現してほしい」とお願いしたり、さらなる情報を求めたりすると、ユーザはひどく面倒な様子で、苛立ちをぶつけてきます。

しかし、このような関係では、問題解決に時間がかかるばかりです。

どうすれば?

ユーザは、「壊れたから直してほしい」だけでは、情報が不十分だということを理解します。

わかりうる限りの情報を、開発者に渡すようにします。その中で、最も重要なのが、「再現環境」「再現手順」の情報です。開発者の手元で再現できれば、解決にかなり近づいたことになります。原因を知るには、ログも重要な手がかりなので、送付するようにします。

出処

2015-04-01

[]専門外

加害者被害者
ユーザ=>プログラマ

どういうこと?

プログラマは、プログラムのスペシャリストです。

しかし、周りからは、しばしば、「IT関連技術全般のスペシャリスト」のように扱われます。専門外のことを、さも当たり前のように聞かれると、プログラマは困惑し、時には傷ついてしまいます。

どうして?

多いのは、ハードウェアにまつわる問題です。

ハードウェアの故障に端を発したトラブルの原因追跡は、プログラマにとって容易ではありません。また、解決策に至っては、そのアイデアすらありません。PCならまだしも、メインフレームやUNIX機では手も足も出ません。ネットワーク機器についても、専門性が高く、やはり手が出せません。

次に多いのは、ミドルウェアにまつわる問題です。

プログラマには、SQLが得意な人はいますが、データベース管理者になれるほどDBMSに詳しい人は、それほど多くありません。テーブルを作ることまではできても、アカウント管理をおこなったり、ディクショナリを自由自在に使いこなしたり、サイジングを行うなどは、それほど得意ではありません。

また、オフィスソフトの質問や、PCにまつわる一般的な質問を聞かれることも多くあります。

しかし、プログラマは、オフィスソフトの専門的な教育を受けているわけではありません。場当たり的に、必要な時に必要な使い方を調べているだけです。PCについても、普段使っていないOSのものであれば、ほとんど何もわかりません。なのに、質問に即答できないと落胆されるため、多少なりとも傷つくことになります。

どうすれば?

プログラマは、コンピュータ分野すべての専門家ではありません。

ハードウェアに関しては、ほぼ門外漢です。これは、専門家に任せるようにします。

ソフトウェアに関しても、非常に幅広い分野ですので、専門的にやっているところ以外は、それほど詳しくありません。これも適宜専門家に任せるか、いなければ、調べる時間を与えるようにします。

出処

2015-03-31

[]コード無理解

対象

加害者被害者
マネジャー=>プログラマ

どういうこと?

プログラマや、プログラミングを理解していないマネジャーがいます。

プログラミングを理解していなければ、プログラマを助けることも、プログラマたちをまとめることもできません。それどころか、このマネジャーは、おそらくは無意識のうちに、プログラマの仕事を邪魔しています。

どうして?

「仕事の内容」を理解していなければ、現実的な見積もりや計画を立てられるわけがありません。また、無茶な仕様や仕様変更も平気で要求してしまいます。

「仕事の仕方」を理解していなければ、プログラマの行動様式がわかりません。必死にアイデアを考えたり、ロジックを考えている時に、平気で声をかけてしまいます。ひどい人になると、サボっていると勘違いして、注意するマネジャーもいます。

「仕事の価値」を理解していなければ、プログラマを評価することができません。テストを書いたり、リファクタリングしてコードを綺麗にするという非常に重要なことを、「無駄」と判断してしまいます。ひどいエピソードとして、繰り返しの多い単純作業を自動化したら、「楽するな」と怒られたという笑い話もあります。

どうすれば?

マネジャーは、プログラミングを知り、理解しようと努めます。

(職業)プログラミングを一度でも体験してみると、理解が早まります。そういった機会に恵まれない場合は、メンバのプログラマに聞くしかありません。知ろうとする姿勢、理解しようとする姿勢が大切です。特に、チーム内のベテランプログラマの意見を傾聴し、参考にします。

出処

2015-03-30

[]仕様変更

対象

加害者被害者
ユーザ=>プログラマ

どういうこと?

ユーザは、気軽にプログラムの動作の変更を要求します。

ソフトウェアの変更は、要求する側からみると非常に簡単に見えるからです。しかし、実際は、非常に複雑で、難しく、時間を要する作業です。

さらに、その難しさの技術的背景や要因を、ユーザにわかりやすく説明して納得してもらうのは、容易なことではありません。結果、押し切られ、プログラマの残業が増えることになり、プロジェクトのスケジュールや品質に影響を与えることになります。

どうして?

ハードウェアのように成果物が可視化されないソフトウェアは、簡単に変更できるように見えます。

しかし、これは誤解です。プログラムは複雑で、外側からは少しの差でも、内側の作りには大きく影響を与える場合もあります。

プログラムの変更は、設計の変更にあたります。ハードウェアを製造している時、常識的に、設計の変更は考えられません。しかし、なぜかソフトウェアの世界ではそれが横行しているのです。

どうすれば?

プログラムの変更は、簡単に見えるものも簡単ではありません。事実として、変更の分は、余計に工数がかかります。

プログラムの変更は、大きな影響があることをユーザに理解してもらいます。その上で、妥協案を探ります。納期を伸ばすとか、納期優先であれば、優先度の低い機能を削るとか、次バージョンのバックログに積むなど、検討します。

また、プロジェクトにユーザを巻き込む方法もあります。例えばアジャイル開発手法のひとつ「XP」では、「オンサイト顧客」として、実際に使用する人をチームに巻き込むプラクティスを採用しています。

出処

2015-03-27

[]管理職オファー

対象

加害者被害者
会社=>プログラマ

どういうこと?

プログラマは、優秀になればなるほど、現場でコードを書く仕事から遠ざけられるようになります。優秀であると、自動的に、その組織の管理職のオファーが来るのです。

優秀なプログラマは、技術リーダーシップ力を発揮し、現場の開発を牽引しています。ただ、技術面で優秀であると認められたのに、なぜか「管理職」として、これまでとは全く別の仕事をさせられるようになるのです。

プログラマは、なかば強制的に管理職になり、やる気を失います。さらに、プロジェクトの現場から、その優秀なプログラマが抜かれてしまうことにもなります。しかも、その補充は、たいてい新人です。

こうして、プロジェクトは、管理にモチベーションを持てないマネジャーと、優秀でないプログラマで構成されることになります。現場は、ヘタクソなコードにまみれ、統制のとれていない管理により混乱し、必然としてプロジェクトが失敗に陥ります。

どうして?

管理職になると、これまで習得したものとは全く別の、社交面や管理面などのスキルを学び、使用する必要があります。このようなスキルを身に着けるには、多くの試行錯誤が必要となります。

こうして、かつて賞賛されていたプログラミングに費やす時間がなくなります。そしてある時、大好きだった仕事が嫌になり、達成感が打ち消されてしまうのです。

また、モチベーションの問題だけはなく、得意不得意の問題もあります。人材マネジメント力と技術リーダーシップ力は、まったく別のスキルです。

どうすれば?

プログラマが希望するなら、プログラマのまま技術を極めてもらいます。

「技術リーダー」を目指してもらいます。並外れたパフォーマーとして、他のプログラマの手本になることを期待します。誰もが管理者になりたいわけではないので、プログラマの目標となる人がいれば、他のプログラマもより高みを目指すようになります。

技術リーダーの成長を促すには、早い段階から、技術分野における成長の期待をかけていくべきです。そして、本人の最終的な目標を明確にするように促します。

例えば、最高のプログラマになることであったり、1千万ユーザを想定したシステムを作ることであったり、オペレーティングシステムを理解することであったりします。このような技術的な目標であれば、プログラマにとって達成可能であり、モチベーションも上がります。こうした目標を達成できるように、人事制度を作るなどして、支援を行います。

さらに、プログラマにとって、「面白い」プロジェクトにジョブアサインします。プログラマにとっては、プログラマとして学び成長できるようなプロジェクトを担当することが「面白く」、それが最高の報酬なのです。

また、プログラマとして成長ができる機会を社外に求めることも大切です。プログラマに対して、カンファレンスでトークセッションに参加するように促したり、ある専門分野におけるリーダーとなるよう促します。

プログラマは、そのような場に参加することで、自身の業績をアピールすることができます。つられて、会社の社外評価が高まるので、結果的に才能ある人材を引き寄せることになります。

上級レベルのプログラマが「この組織で働きたい」と思う最大の理由は、リクルートされることではなく、興味がかきたてられるような人との出会いです。会社にいる技術リーダーを、ある専門分野のリーダーとして活用できるような方策を進めることこそが、エンパワーメントであり、エンジニア自身の成長につながるのです。

出処