2014年07月29日

人をイメージで語らない。そして相手の自分に対するイメージは利用する

私は、人に対してある程度短い期間で先入観を持ち、この人はこういう人だと決めつけてしまう人のことを、「人をイメージで語る人」と表現しています。

色々と言われますが、人の先入観というのはとても大きな割合を占めていて、一度持った先入観を払しょくするのは非常に難しいです。そして、人は自分が思いたいように相手のことを、あいつはこうだ!と決めつけているものです。

それがよいこともあります。ぶれないことにも繋がるのかもしれません。
しかし、ことビジネスにおいては、この先入観は非常に厄介な代物で、対人関係、部下・上司の関係、仕事の内容、その他多くのものの中に入り込んだ先入観は、時に人を傷つけることも、間違った判断をすることも、人の意見を結局聞いておらず、相手を怒らせることもあります。

逆に言えば、最初に相手にもたれてしまった先入観を利用しない手はありません。
要は相手は、自分のことをこうだと決めつけているのであれば、それは相手が思考を鈍化させ、相手に読まれる状況を自分で作ってしまっているわけです。
この場合、相手の先入観を利用して演じた自分について、相手は自分の持っている先入観が正しいものだと勝手に意識し、疑うこともしないことが多いのです。

これについては経験的にいくつかの実験をしています。
相手はもう、私のことをこういう人間だと思い込んでいるため、その状況を利用して自分の有利になるような状況を作りこんでいきます。相手は気持ちよく思考し、こちらはそれをそのまま利用していることに相手は気づかないわけです。そして、こちらは相手の手の内をすべて読んだうえで行動できます。

勝手に先入観を持つこと、つまり人をイメージだけで語る場合、相手に付け入るスキを作ります。
逆に言えば、相手が自分に対してどのような先入観を持っているか、それを早期に知ることは、その人をうまく説得することも、だますことも、動かすことも、気分良くさせることも、嫌われることまでこちらの思惑通りに動かせる可能性を持っています。
そして、こちらが相手に勝手に先入観を持ってしまうことは、間違ったことをしてしまう可能性も出てしまいます。

勝手なイメージを自分では持たないように、常にそのイメージが正しいか、正しくなさそうなのか、勝手に固定観念にしてしまっていないか、思い込んでいないかを意識し、違う観点・違う角度から物事や人物、さらには自分をとらえるよう意識しましょう。それすらもイメージなのかもしれませんが・・・。

そして、次には相手が思い込んでいるイメージをしっかり理解し、時に相手のイメージに合わせた説明、相手のイメージを利用した行動、または相手のイメージを壊して育成させるなどに活用できるよう、意識して行動していきたいものです。

2014年07月27日

「考えなさい」という指示は無駄なことが多い

会社の上司からよく言われる叱られる言葉の最後に「考えてみなさい」もしくは「考えなさい」があります。
簡単に言えば、これは上司から部下に対しての教育をかねての言葉だったりします。
また、コーチングにしかり、いろいろなご意見の中で、コミュニケーションが重要であり、最終的には対話の中で考えさせるというのが結論として語られます。コミュニケーションについての多くの知識、経験は話の中でこうしたらよいなど雄弁に語られますが、考えさせること、その方法については全くと語られることがありません。

それは単純に考えさせることが話のテーマではないか、考えさせるのは別の機会でということか、もっと言えば、考えさせることまでは方法論がないかのいずれかだと考えます。

私には、この上司から部下に対する考えなさいという指示、言葉は間違えている対応だと思います。
もし最初から言われているようにもっと考えてきなさいという対応ができているのであれば、最初から考えて答えを上司にもってきているはずです。
誰だって、やっつけ仕事でなければ考えて仕事をして、そのうえで分からないから上司に相談するなり、考えた結果これが自分なりのベストという意識をもって上司に報告します。
そこからさらに考えてみなさいということに対して、何を期待しているのか?となります。

一つ目は、対話をしている中で気づきが本人にあったから、考えさせたら答えを自分の力だけで導き出せそうだと感じる場合。この場合はごくまれにありますが、その場合においては本人にはすでに答えが見えています。

二つ目は、あまりにも正解に遠いから、もう一度考えて少しは正解に近づけてみなさいという場合。
この場合は、多少は時間をかけただけあって正解に近づく可能性もありますが、逆に遠くなる可能性もあります。もちろん、正解に近づくヒントを出すこともあろうかと思いますが、そのヒントをヒントととらえるかどうかは相手次第です。つまり、上司のヒントを出してあげたという自己満足の世界で対話が完結しているのです。
このパターンの上司は、案外部下の言葉に耳を傾けていないことも多く、考えなさいというのは単に自分が正解に部下をコーチングしていくのをさぼっているだけのケースがほとんどだと思います。

もちろん、上記二つに合致しないケースもあるかもしれませんが、私の狭い経験の中では、特に二つ目の上司がほとんどを占めていると思います。

これは時間の浪費です。
まず、考える力というものを誤解しているかもしれません。
人は誰しも考えた結果について、考えた末に思いついたと思いがちですが、そういうケースは少ないのが実態だと私は思います。通常は思い付いたのです。。。ひらめいたともいえます。
それを考えていたからと表現しているだけです。

ある仮説を立てて、それが正しいかを論理的に導き出していく作業が考える力の一つだと思います。
つまり、考えている場合には、ある一つの考えの次の意見までしか出てこないのが実情です。そして、さらに次の意見にたどり着くのには、思い付きやひらめきが必要不可欠です。

上司が求める考える力は、ある種の思い付いた結果やひらめいた結果の正解を部下に求めていることと同義です。よって、上司に見せた成果物から本当に上司が求める正解を考えて導くことは通常できないものです。
それこそ、別の観点から思い付きでもしないかぎり・・・。

思い付きやひらめきは、大量の経験が必要です。
ある物事に対しての10の経験と、その中から出た100の不満に対して導いた解決策が思い付きやひらめきで表現でき、それを普通は考えた結果出たものと表現していると私は思います。

上司が部下の出した答えに対して考えろというのは、そのことに対して、部下に大量の経験をさせていなければ、時間の浪費、部下は考えても何をどう考えたらよいのか、むしろ自分はものすごく考えたのに・・・と不満を持ち、さらに試行錯誤して場合によっては近づくかもしれない正解もあるかもしれませんが、より正解が遠のき、さらに時間が浪費されます。

考えてみなさい、その結果出た答えが正しければ成功体験になるのかと言えば、そうでもないのも実情です。
残るのは時間の浪費と部下の本当にこういう上司のやり方は正しいのかという思いを残すだけです。
上司にとっては部下を思って考えさせたのかもしれませんが、部下にとってはもっとビジネスに対してドライに時間の無駄を意識させることになります。

考えさせるのではなく、答えを提示した上で、どう違うのかをコミュニケーションの中で部下に発言させるのが、もっとも次に部下は自分の行動が正しく上司が求めるもの、ビジネスとして正しいものだったのかを考えるきっかけになります。

上司は単に考えてみなさいと、答えを提示せずに、またできなければ仕事を取り上げてしまうのではなく、考えさせるならば、それなりの理由と行動を示す必要があることに気付くべきでしょう。

2013年02月10日

禁じ手「犯人探し」は本当にNGなのか?

いわゆるコミュニケーションを大事にすることを重視するプロジェクトにおいては、また一般論としてのプロジェクトマネジメント論としては、例えばあるミスを犯したプロジェクトメンバーや上層部に関してこのようなことが言われることがありませんか?

「犯人が誰かであるかは重要ではない」

そう、犯人ではなく何が起きたのかを注視しようという観点に立って問題の本質を見極めようというのです。つまり、注意喚起メールは行われますが、犯人を探しているわけではないため、犯人が分かりません。誰が犯人かわからない状況ですので、送られるメールの内容は語弊の少ない、「で?」と言いたくなるような文言に落ち着きます。

「〜〜は気をつけましょう」等です。

きっと色々とあるのでしょうが、この考え方の根幹に在るのは「誰だってミスをする」というところでしょうか。

でも、だいたいの人は自分ではない、自分とは関係ないという意識の元、こういう注意喚起は他人事に思えてしまうものです。
それこそ、だれだってミスをするという観点でいるならば、他人事になるという観点でも発言をすべきでしょう。
ですが、そこまでには至らないことがおおいと思います。
よって、気をつけるよう言われても、具体的にどういう行動をすればいいのかは不明です。

少々話をずらしますが、
例えば、誤って間違った(自分が一時的にデバッグ用に他人が担当のソースコードを修正して、そのまま)ソースコードをサーバに保存して、そのまま忘れていたとします。
普通であれば、そもそもバージョン管理システムを使えばいいとか、ファイルサーバなんかに保存しなければいいというのがありますが、案外SIerで働く人間は知識も技術もなく、バージョン管理システムを使うというだけで拒否反応を示す人もいれば、理解がない、教えないといけないという状況が出てきてしまいます。

おかしな話ですが、そこはプロジェクトの方針として、サーバに保存するとして話を進めます。

ファイルサーバでは履歴も何もないため、誰が保存したのかもすぐに分かりません。
注意喚起のメールは、以下の様な感じのものが送られたりします。
「ファイルサーバにデバッグ用のコードが残ったものが保存されており、しかも古い状態で上書きされていました。今回は担当者が最新のソースを残していたため、元に復元することができました。次回からは自分が担当しているソースコード以外はサーバに保存しないでください。保存する際、自分のソースコードの選択が正しいか確認し、またコピーする前に差分比較を実施してください。」

そもそも論を展開すると、どんどん広がる内容です。

「人間はミスをするものだし、ミスをしない人は最初から当たり前のように確認しているだろうし、それでもミスをしてしまうのが人間だし、でもそのために履歴を保存できるようにしているだろうし、でもそれでも壊してしまうかもしれないし、壊れてしまうかもしれないし、そもそも人間だからミスをして。。。。。。。。」


話を元に戻します。

私は何かプロジェクト上で問題があった場合は、「なぜそうなったのか」と同時に「誰がやってしまったのか」を調べるべきです。つまり犯人です。
ただ、それは犯人を吊るしあげたり公表したりすることが目的ではありません。

犯人がヒアリングしなければわからないケースでは、プロジェクトリーダー(できれば2名以上で)はメンバーを1名ずつ別室へ呼び、「今回こういうことがあった。このソースに関係しそうなのはあなただけど、やってしまった記憶はありますか?」というところから犯人を探し出します。別室へ呼ばれることに対して恐怖心がある方もいるので、そこは口頭・メールなどを使い分ける必要があります。

犯人であれば「そうですか。ミスは誰でもするものです。ですが、他の人も同様のことがあるかもしれません。ミスを減らすために対策を考えたいのでご協力いただきたい。今回どういう経緯で事態が起きたか聞きたい」と事態を確認すべきです。その上で、個人の背景を聞いて、対策や事態の周知をするのかどうかを判断すべきです。

犯人でなければ調度良いので「今、プロジェクトでは急ぎでやっていることもあって問題が多い。この場を借りて、何か問題が出ていないか、気付いたことが些細な事でもあれば教えて欲しい。それが後々大問題になってしまう問題かもしれないし、そうでないことかもしれない。ですが、メンバーの気づきを大事にしたい」と情報を引き出します。

それをやってしまったのが、人によって背景が異なる点も重要でしょう。
普段はしっかりしている人が犯人で「たまたま頭がその日痛くて注意力不足だった」のであれば、実は注意しましょうでは解決せず、体調不良だったら休みましょうの方が適切ではないでしょうか。
一方でBさんが犯人で技術不足であれば、教育が必要かもしれません。
Cさんが犯人で正確的な問題でルーズな人であれば最初の注意喚起は効果があるかもしれません。

でも、犯人が誰か特定されておらず、汎用的なメールでは、そもそも自分のこととは思いませんし、自分の行動が悪い行動とは気づかないことも多く、また何度でも同じ事を繰り返します。
つまり、注意喚起は根本的な解決にならず、問題の再発を引き起こしやすいのです。

ただし、犯人が分かったからといって、「あの人が犯人でした。」、「あの人が根本原因でした。」という姿勢は持ってはいけません。
あくまで、事前にこういう問題があったけど、プロジェクトとしての問題の提起を早期にしてくれた協力者だったという観点を残して接することで、その方のモチベーションを低下させないよう対応する必要もあると考えます。


こう考えたのは、今回のプロジェクトでは何回も同じミスがあるのにも関わらず、一向に解決しない状況が発生したために、こういう考えに至りました。
また、営業やPM、PLが実は理解、知識、技術不足で意味不明な要件を確定してくる場合もあります。その場合も、正しくミスであることを教え、なぜそれがダメなのかをわからせない限り、また同じ判断ミスを上がしてくることがあります。

プロジェクトメンバーのミスは案外小さい問題が多いですが、上層部のミスはプロジェクト全体に影響することが多いです。むしろこちらのほうが、根が深いことが多いのが悩ましいところでしょう。

2012年10月13日

思考力を身につけるための習慣 (4/4)

どうやったらこの思考力を身につけられるのでしょうか。
非常に難しい問題であることは想像できます。
私の考えでは、思考力とは習慣から身につくものだと言えます。

よって、大人になってから身に付けるのであれば、保証できませんが、私の考えでは以下の行動をとることになりそうです。


1. 自分が理解のために努力しない人間だと認識しましょう

諦めない、投げ出さないと等しいのですが、自分が上記のような人間だと謙虚になり、姿勢を改める以外にありません。「いや、私は謙虚だ」と思った時点で謙虚ではないと思いましょう。それほどに前提が成立していないのです。


2. 仕事でも趣味でも、ものすごく好きなものを探す

好きなもののために何をおいても行動するという意思と、実際に行動することが求められます。そのために散財することにもなり得ます。子供の頃は散財する財力もないために、逆に好きなものを以下に長く続けるか、大量に手に入れるか考えることを行えます。なので長い間、ものがない/困ったことがある子供というのは、大人になって思考力があるケースが高いです。
大人になると、欲しいものはある程度買えます。でも、ある程度行くと抑制心が働きますので、散財するほどではないケースが多いでしょう。破産しない程度に散財するぐらい、好きにならないとだめかもしれません。。。

ただ、生活できないほど散財しないようにするのは難しいでしょう。生活についてもしっかり赤字にならないよう考えてください。

そして、何でもよいので、好きなものの知識を深めてください。


3. 現状に困っていることを探す

好きなものに詳しくなってください。具体的には好きなんだけど、こういうものが足りない/困るというものが見つかるぐらいにです。どんな些細なことでも困っていることを探し、何とか解決しようとしてください。それは既製品をまずは探すでもよいでしょう。見つかれば良しとしてください。どんどん改善してみてください。
改善するという行為が考える行為になっていきます。


これを2年ぐらい続けてみて、やっともしかしたら思考力の基礎が身につくかもしれません。
これについては保証できません。。。。。
ただ、何でもかんでもやってみるということに結局結論付けされます。。。

2012年10月12日

思考力がないことのデメリットを知る (3/4)

書籍には考える力がないことによるデメリットが示されていないことが多いように思います。
このデメリットについても知る必要があると思います。

仕事にしろ勉強にしろ、どんなことでも次のステージに進むには何か必ず新しいものを理解する必要があります。もしくは新しいものを生み出す必要があります。そのためには新しいものについて考える能力が必要です。勉強の場合、通常高校までは先生が先に新しいものを教えてくれます。そのため、新しいものを自分から理解しようという能力は育ちません。そして、それに慣れてしまうと、知識は与えられるものだから、待っていれば答えがいつか得られることを無意識に考えてしまいます。これが自分で考えることを阻害し、分からなければ降参さえすれば、誰かが答えは教えてくれると待ちの状態になります。

社会人になれば、勉強すらも自分から新しい領域に踏み込まなければなりません。いえ、踏み込むことは簡単です。本を買うなり、人に教えを請えば良いのですから。でも、そこでは答えを簡単に教えてもらうことはできません。正確には答えがない可能性が高いです。社会において答えとはないに等しく、いわゆる処方箋に近いものです。よって、誰かのやり方が正しいかといえば、別の状況では全く正しくない、もしくはもっと良い方法があることが多いのです。

また仕事にしてみれば、何か新しい革新を生み出すこと自体、既存にはありませんから答えなど教えてもらうことはできません。それこそ自分で答えを作る人間にならなければなりません。それが考える力になります。それを既存がこうだからとか、調べたけど答えがないと言っていては、当然何も改善も革新も新しいこともありません。また、現状何が問題か、不満はないかなども考えませんから、結局は非効率な方法を続けます。

これらはもし会社であれば、人件費として莫大なコストとなります。

会社員は法的に十分保護されています。就業時にいわゆる能力主義による契約をしていない限りにおいては、容易には解雇されません。
それが逆に、安心感を生み、社員自らの向上心を阻害する要因になり得るケースもあり、一概に良し悪しを言い表せません。良いのは、考える力がある人間からすれば、チャレンジ精神を持って新しい分野に進出し失敗したとしても、そこは守られるためです。また会社もチャレンジ精神のもと、正しく活動した社員は重宝こそすれ、捨てることはほとんどありません。
逆にチャレンジせず、現状を変えることもしない社員は、単に守られているだけで、会社には害しかありません。会社は基本的に、社会に貢献し、利益をあげ、会社を大きくすることが求められます。その全てにおいて重石になります。

この重石はチャレンジしようとしている人間にとっても害になります。チャレンジしようにもお金がなくなれば、会社はチャレンジを容易に認められなくなります。また、チャレンジできる能力を有していても、考える力がない社員が活動できるよう、彼らが考えなくてもできる方法を模索することにチャレンジする必要性が出てきてしまいます。つまり、チャレンジできる人間は社外に能力を発揮して確認するのではなく、社内の考える力がない社員に向けた閉じたチャレンジしかできません。
結果、これらは別に評価されることもなく(考える力のない社員が幸福になり、そして感謝もされませんし)、文句も言わずにこれまで同様残るか、会社を去る道を選ぶことになります。

考える力がないということは、会社が革新する上での妨げになります。

考える力がない人のデメリットはその人自身にはありません。その人の周りの方にしかデメリットは発生しません。昔であれば聴衆を簡単に扇動できたでしょうが、今の方は思考能力にまで発展しませんが、自分にデメリットでは?ということだけは、自分を守るために感覚的に考えます。
ですが、あくまで自分のデメリットまで。他人に与えるデメリットを認識するには至りません。
また、何となく考える力がないなと思いながらも考える力がないことを実感できない、自分で気付かないのも考える力がない場合の特徴です。
そして、得てしてまわりからは評価されないのですが、その評価の理由も分からず、教えてもらえることもあまりありません(どうせ聞いてもなぜなのかを考えないため。。。)。

はっきり言えば、この記事は耳障りな内容だと感じる方も多いでしょう。ですが、デメリットを認識しなければ身につけるモチベーションにならないかもしれない、逆に言えば、この記事でモチベーションにつながる方もいるかもしれませんので書かさせて頂きました。

2012年10月10日

思考力がある人はなぜあるのか?思考力以前のハードル (2/4)

思考力がある人は多くの場合、ある特定の分野に対して非常に特化した思考力を持っています。それは概ねどの分野でも構わないのですが、あまりに趣味に走りすぎた分野の場合は単純に詳しいだけになりがちです。


どういうことかと言いますと、つまりは思考力は過去の自分の記憶や経験から推察されるものがほとんどだということです。そしてその分野に特化して、詳細に記憶や経験がある分野において、想像をふくらませることを何度も経験すると、まずは、その特定の分野に関してのみ思考することができるようになります。この想像をふくらませるというのは、訓練のためにふくらませようとしているのではありません。

簡単に言えば、その対象のことが好きだからよく考えるだけなのです。私だったらゲームやコンピュータのことが好きだから、そのことをよく考えるだけです。


必ずしもではありませんが、思考力がある方は、具体的にはその対象、ものや分野に関して以下の感情を持つことが前提です。

1. すごく好きだと思う
2. よく見聞きしている。
3. 興味がある
4. 趣味
5. 楽しい、面白い
6. やっている。やってみたい。
7. (ごく稀な例外ですが) やりたくないぐらい、すごい嫌い


その現在の状態に対して考えるというものをし尽くし、現状に満足しない状態になった時に状態の変化を考え出します。どうにかして新しいものを、どうにかして改造を。。。などです。この状態の変化を引き起こそうとする行為が思考力を鍛える方法になり、これを何度も行うと思考しようという糧になり、そして、実際に状態の変化の行動を起こすことで思考力が鍛えられ身につくようになります。この状態を変化させる行動はよく失敗します。失敗するからこそ、どうしたらいいのか、前提はなんだったのかを何度も考えます。それが建設的、論理的な思考の順序を考える訓練になるのです。

これが経験上、次にどうしたら良いのかを考える基礎となり、今までこういう手順で状態を変化させてきたというものをベースにどんなことも建設的にこうして行く必要があるのでは?と考えるようになります。

思考力がある方は、単純にある特定の分野の上述の経験を、何となくだったり体系だっていないけれど、考えることができる、考えることが苦ではないというだけです。


今更どうしようもないと言われてしまえば、どうしようもないでしょう。
簡単に言えば、以下に当てはまる方は、思考力がない場合がほとんどです。

1. 好きなもの、熱中するものがない
2. 好きなもの、熱中するものはあるけど、単純に見ているだけで満足する
3. 見ているだけで満足しないけど、仕方ないから諦めて、自分で好きなものの状態を変えようとしない
4. 状態を変えようとしたけど、知識、(一般)教養がない。
5. 知識も(一般)教養もないけど、できる/できないの結論を理由を持って出す前に、途中で投げ出した

この内、知識や一般教養は好きだけでは身につきません。好きな分野に関しては知識は身につきます。単純に詳しくなったり暗記するだけです。でもどうしてもそれだけでは、複数の知識を身につける何かが足りません。言葉だったり、数字だったり、時事だったり、物理だったりするかもしれません。これら複数の知識をつなげるために一般教養は必要です。


また、状態を変更するというのは以下の欲求を解消することを指します。

1. 楽しいけど現状に飽きてきた。もっと楽しくしたい。面白くしたい
2. 人がやっているのを見ているのが好きだったが、自分でもやりたい。だから何とかやりたい。どうにかしてやりたい。
3. こういうことができたらいいなと思う。ちょっと何か自分に合わない。一手間あるのが面倒だと感じた
4. どうしても今のままだと面倒くさい。楽になりたい。
5. 今のままでは、これができなくて困っている。自分で何とかしたい。自分でどうにかしたい。

よって、例えば麻雀は好きだという方は、最初の好きなものがあるという前提を満たします。ですが、現状の麻雀のルールに満足して面白いと思うだけでは思考力は身に付かないのです。ルールをねじ曲げてみたい、如何に効率よく状況を簡単に把握できるようになるにはどうしたら良いか、自分でルールを展開したいと思うようになってしまうぐらい熱中する人が、最初の思考力の基礎への扉が開きます。

また、困っていても、それを自分で何とかするのではなく、既製品から探すだけではやはり考えないため思考力は身につきません。自分の要求を叶え終わっているものを探すだけでは、あれば満たされ、なければ諦めてしまうため、考えません。あくまで、探しても、その後無ければ諦めないで自分で何とかしようと思う場合だけです。逆に言えば、諦めてしまうというのは「好き」ではあるのでしょうが、「ものすごく好き」ではないと思います。


上記のほぼ趣味に近いことを経験したことがない場合、思考力が身につきません。

そして、その状態を変えるということを何度も何度も、何年もかけて経験すると、思考力の基礎ができます。思考力とは趣味の改善に近いものです。


好きでも嫌いでもない感情を持ったまま、思考力を身につけたくて本に頼ります。でも、どうやればいい、ああやればいい、と言われても、ふーんで終わる。結局それの必要性は何となく理解できるけど、それを習慣にはできない。最初はがんばってやってみているけど、しばらくすると忘れてしまう。だって、興味がないから。本当に必要な時はそんなにないし、面白くもないからとなって、結局身に付かないのではないかと私は考えます。

2012年10月08日

思考力を身につけることはできるのか? (1/4)

思考力、論理力(ロジカルシンキング)、整理術等、考える力を身につけるための本は多いです。
ですが、これらの本を読んで理解し実践できる人間は、概ね最低限の能力を有している場合が多く、最低限の能力を有していない方は、これらの本を読んでもさっぱり実践できないことが多いと思います。

本に記載されていることが間違っているわけではありませんが、できない場合は、「なぜできないのか」、「できるようにするには」の実践がないことも大きな障壁でしょう。通常はこのような本には、「こうすればいい」が書かれていますが、それを実践できるなら実践できています。つまり、最低限の能力として形容した能力(よく地頭とも言われますが)がなければ実践できず、ある人は本を読んでも実は知らず知らずに実践できていることも多く、理論を得られますが、実際はほんの少しの向上にしかならないことが多いです。


問題なのは、その最低限の能力を有していない場合です。


彼らはそもそも、考えるということをしていないのです。最低限の能力とは、考えられる力ではなく、考える力でもなく、考えるという行為ができるかどうかです。その結果答えが出る/出ない以前に、考えると言う行為ができない人は、たった少しの意味不明なものがあると、全てが意味不明に連鎖的に陥ります。そして、分かっている部分から少しでも読み取ろうという意識さえなくなり、完全に放棄します。その結果、何が分からないか分からないという状況になります。

彼らは少しでも理解できないものがあっただけで、全てを理解できないものとし、少しでも理解しようという気持ちさえなくなるのです。そんな彼らは「全て自分が分かる言葉に置き換えてほしい」という、自分の能力がどの程度かも表現せず、ただただ自分のレベルに合わせるように要求をはじめ、最悪の場合、最終的にはその要求を満たさない相手が悪い、理解させようとしていないというように考えはじめます。
そして理解しようという気持ちは何もなくなり、放り出してしまいます。

最低限の能力と言いましたが、能力以前の単純に心構えの問題ともいえます。
考える力がある人間は理解できない部分を無視して理解できたところだけを読むか、理解できたところや前後の文脈から何とか理解できない部分を推し量ったり、補間しようとします。その結果、100点はとれなくても十分な合格点にその場で至るケースが多いです。合格点には至らなくてもある程度の情報を得たり、後から十分情報を補間できます。つまり、理解することを諦めていないのです。

単純に理解を諦めている節が多いのは事実に考えます。長時間考えているように見えますが、実際は眺めて単に答えが実は隠れていないか、観察や調査、整理、推測ではなく、そのものずばり、答えそのものを表面的に探しています。結果なければ、それ以上の観察や調査、推測を行うことなく、断片的に理解したこともまとめず、「全て理解できない」よって「分からない」に至ります。この全て理解できない状態を、分からないと形容するがゆえに、思考力がない、論理力がない、整理できない、考えられないに結び付けられて能力が判断されます。

先にあげた書籍は、この理解を諦めない人のために書かれた本です。
その理解できる部分から理解できない部分を理解できた状態にするための手法が紹介されています。そのために、どのように観察するのか、どのように調査するのか、何をどのような方法で分類・整理するのか、どうやって理解できない部分を推測したら良いか、その方法が記述されているのです。つまり今まで合格点にならなかった「理解できなかった個所」を、あらゆる方法論を用いて合格点になる推測等の結果「理解できた個所」にするための所作と心構えに近いことが書かれています。その前提はやはり諦めない人間です。そして、その所作と心構えをある程度持った人(これが最低限の能力があると形容されたもの)が読むために、さらに能力向上につながります。なぜなら、自分に足りないものを本から推測等ができるからです。その所作と心構えを持たない人は、どんなに読んでも何も得られません。おそらくその本を読んでも、理解も共感も何もないため、結局自分には理解できないとなります。最後には自分に足りないものを推測することもなく、本を閉じるでしょう。

結果、思考力は身に付かない人には身に付かないまま、鍛えられないままとなってしまいます。ですが、思考力というが身に付かないというのは本を読む、上記のような忍耐力みたいなものがあるかどうか、それ以前のように考えられます。

2012年10月07日

責任を取るということは、どういうことなんだろうか?

「責任はどうやって取るつもりか?」

こう聞かれても、責任のとり方なんて簡単にはわからないと思いませんか?
・会社をやめればいいのか?
・謝ればいいのか?
・給料が下がればいいのか?
・始末書を書けばいいのか?
・それとも損害賠償すればいいのか?

そして、責任を取らなくてもいいということも分からないと思いませんか?

それらはつまり、責任とは何か?責任の所在はどこなのか?明確では無いから発生しているようにも思えます。

私は上司の立場にはありませんので、最終の責任のとり方というのは会社を辞めることまでであって、それより上の損害賠償等の責任は、よっぽどのことをしないかぎりは発生しないでしょう。でも通常は、プロジェクトにおいても仕事においても、何かあったとしてもそこまで責任をとるということは発生しません。

同時に責任と反対の無責任もどういう状態なのか分からないと思いませんか?

会社では「あの人は責任を取らない」とよく思います。それは私が勝手に思っていることです。
でも、よくよく考えると、じゃぁ何をしたら責任をとったことになったのか、それを考えていなかったように思います。

社会人でも、会社員としても、役職なしの社員、主任、課長、部長、さらに上の立場、
次に役員の立場、執行役員や監査役、社長や副社長、さらに上の立場、
株式会社においては、株主もいます。

会社内の役職員における立場もあれば、プロジェクト上のプロジェクトマネージャー、プロジェクトリーダー、サブリーダー、営業、いろいろな役回りもあります。

それぞれの責任範囲とは一体何なのか?
そして、それぞれどこまでの権限があるのか?
お金はどこまで使えるのか、何を決定でき、何を決定できないのか?
何かあったらどうするのか、誰にエスカレーションしていくのか?
そして、失敗した時はどうしたらいいのか?

「そんなことは言われなくても当たり前のように分かっていろ」と言われるのかもしれません。
それは私が不勉強なのだと思います。でも、それはあくまで暗黙的です。

定義すればするほど、逆にがんじがらめになるとも言えます。それが身動きを取れなくしてしまう。なければ、ある程度状況や行間を読んで行動し、補間できる場合もあるので定義しないと言えます。

責任というものを考えて行動するのは非常に難しいです。

が、一つだけ誰でもできることは、「無責任ではいけない」「これは私が責任を持って最後まで面倒を見る」という心がけは持てると思います。最低限、「自分には責任はないから」という考えを持たないようにしたいと考えました。

2012年07月12日

クラウドつながり。私が本当に使えると思うクラウドはSIer開発案件向け。

SIerは顧客にクラウド環境を売っています。
売れているかどうかはおいておいて。。。

社内ではよく、サーバーリソースが足りないとか、検証環境が足りないとか聞きます。
そして性能検証したい環境なんて、テストが終われば用済みであったりします。
逆に開発中は大規模にリソースが必要です。

また顧客の保守環境は、リリース前はきっちりとしておきたいけれど、リリースが終わればしばらくは縮退したい。でも保守期間中はきっちりと保存したいという要望があります。

そうです。これこそクラウド環境はもってこいの内容だと思いませんか?

ですが、弊社ではやっと考え始めた節がありますが、まだまだ本格的にどうにも使いにくいものです。
もっとメリットを前面に出して、いかに案件のコストが減るのかを明確にして、さらにSourceForgeやGithubのような機能や営業支援機能、営業情報管理、リリース管理、不具合管理、課題管理、ライブラリ管理、バージョン管理、Wiki、ブログ、掲示板、アラート機能、マニュアル、ドキュメントやソース全文検索機能、ナレッジベースとその統合化、構成管理、プロジェクト管理(コスト管理、スケジュール管理、メンバー管理、等など)、ユーザー管理、認証管理、テスト管理、承認管理、ビルドサービス(CI的なものなども)をあわせて、社内で売上を立てる部署を作るべきだと私は考えています。

今、その方向で何かできないか、実はこっそり考えています。

2012年07月11日

クラウドは失敗してもらいたい

今やどこでもクラウド、クラウドと言われています。
私が一番最初にクラウドという言葉を聞いたのは、2008年ぐらいに品川で行われたガートナー社の講演の中です。当時はまだ、クラウドという言葉がバズワードレベルで紹介され、これから定義をしていくという感じでした。

当然ガートナー社ですので、要は「ブームはこれから自分たちが作るものである」と言っても彼らにはいいのかもしれません。ただ、単純に当時、社内へその話を持って帰った時の上司達の反応は、「クラウドって何?」でした。私は「単純にいえば、仮想化です。ネットワークの先にあるサーバーリソースを隠して、使いたい時に使えるようにして、自社データセンターがなくてもコンピュータ資源を使えるようにするようです。」と話したら、「そんなのいらない」という回答を上司から得た記憶があります。

そんな弊社も今や、国内に何箇所もデータセンターを持ち、そしてクラウドサービスもやっています。一応は名も売れているようです。例に漏れず上司たちはクラウド、クラウドと叫んでいます。

今、クラウドは旬な状態から枯れる位置に移動しようとしています。

ですが、私が言いたいことは、そんなことではありません。


クラウドのメリットやデメリットは色々と営業として語られてきています。
でも、メリットの中には耐障害性だとか、運用コストが安くなる可能性があるだとか、そういう話があがります。もちろん、パブリッククラウドからプライベートクラウド、併用等も含め。。。

正直なところ、そんな話、今となってはウソでしかないのではないかと考えています。
あらゆるメリット・デメリットを検証してもし尽くせないのですが。。。ここで2つ見てみます。

1. データセンターを持つわけではない、DRやBCPサイトを別のクラウドセンターに用意すれば業務継続性に強い

これは本当にそうでしょうか?自社内においてもネットワークの切断があれば、社内システムは使えないわけです。それがさらに社外に及ぶネットワーク切断が発生する可能性があるわけです。
今ではSalesforceは日本にもデータセンターがありますが、一時はオンライン障害が発生するまでは日本にデータセンターはありませんでした。SaaS環境の上で営業売上を分析するシステムを構築していたとして、さて大地震で海外につながるあらゆるネットワークケーブルが切断されてしまったらどうしますか?衛星回線でも使いますか?衛星回線は高価です。常時のコストは安くとも、障害があった時の代替案としてはコストがかかり過ぎます。

結局どこにセンターを置いたとしても、TCP/IPとインターネットによるネットワーク網が冗長であることがどれほど謳われたとしても、SIerレベルではそれを営業が「本当に大丈夫なんです」と話すのはウソです。「100%大丈夫」はありえません。
私が社内でよく切り出す話題に、「伊豆半島にしか本社、支社がない会社があって、弊社の東京データセンターを利用している会社があったとき、決算期に富士山が爆発して伊豆半島だけ分離して流されたらどうしますか?」とインフラ担当者に聞くと、彼らは「そんなこと起きないよ」と返します。

SIerが考えている想定はつまりはその程度なのです。
SIerにとっては伊豆半島が離れることはないし、まじめに考える必要もないし、本当に離れてしまっても自分たちが困ることがないからまじめに考えないのです。

それでもクラウドって障害に強いのでしょうか? その強さを一度定量的に示してみてくださいとSIerに聞いてみれば分かります。弊社も若干某米国のサーバーにのっているクラウドもありますが、そのサーバーまでの地面に埋め込まれた回線数を全て把握していて、1時間で全て回答できないでしょう。もしできるようであれば、弊社を利用してくださっても問題ないかもしれません。。。


2. コストが安くなるという宣伝文句に騙されていませんか?
これはつまり、逆に言えば、今のコストは高くしているのですよと言われていることと等しいです。
安くなる=そこに弊社の中で営業努力やコストカット、効率化があって安くなっているという事実はありません。
遅ればせながら参入したから営業的に、クラウドにすると他社より安くしますよという言葉は言います。が、これは営業努力の結果でしょうか?

おもしろいことにSIerの素晴らしいところは、自社の顧客の業務をシステム化し、そして業務上発生するデータはデータベースにのせることはできるのですが、自分たちの業務はデータベースに表現できないと言うのです。また、他業種は自分たちがコスト削減や効率化をシステム化することで実現しているのに、私たちはそんなことを推進しているわけではありません。

同じ仕事、同じお金を稼ぐ作業、同じ何かをデータ化する作業。何が違うのか?

言いたいことは簡単です。クラウドだからコストが安いというのはウソなのです。
どちらにしてもデータセンターは運用しなくてはいけないのです。ただ、クラウドとしておけば、顧客がサーバーを使う際のSIer内のCPU時間やメモリ、運用コストを効率良く分配できそうだと考えているだけです。ただし、当然SIerの視点では正しい考え方です。
でも、顧客の決算期などの最繁期なんて業種が同じだったらどこの会社もほぼ同じ時期でしょう?
だから、データセンターで監視しする運用コストはそんなに変わらないはずなのです。。
ちょっとだけシステム化されているだけ。要は客寄せパンダのためのコスト表が提示されているのです。


さて、話題を変えさせてください。

今や禁止用語に近くなったP2Pという技術があります。また、P2Pとは少し違いますが、SETI@homeなんていうものもあります。

これらに共通して言えることは、みんなのPCを少しずつリソースを共有して、何か大きなことをしようというものです。
P2Pでは悪いイメージが先行していますが、業務で暗号化して利用してしまえば複数の社内PCに対してデータを社員が利用しているPCのほんの50GB(最近はHDDに500Gとか積んでいるので問題ないでしょう)を利用させてもらって、社内の業務情報を複数箇所に分散させて保存させるなんてことは考えたことがありますか?

ちょっと特殊なアプリケーションですが、業務の計算を社内に出社しているコンピュータを利用してその空きCPU時間を利用させてもらって業務計算させるということは考えたことはありますか?最近はデュアルコアどころか、クアッドコア(4コア)のCPUを積んでいたりします。
SIerで開発をやるようなところではなく、WordやExcel、PPT、ネットが見れてちょっとしたアプリが使えればいいような業種であれば1コア分を使わせてもらっても影響はそんなにないと思いませんか?

自社の社員のPCをクラウドのようにディスクスペースとCPUコアを分散して使う。
その社員が日本全国にいて、10支店ぐらいあって、500人いて、毎日彼らは出社してくるわけです。閑散期も最繁期も。そして、最近はWake On LANがありますので、夜間バッチ中にリソースが足りなくなるようであれば、パケットを飛ばして社内のPCを立ち上げることもできます。
CORBAなんて技術もHadoopなんて技術もあるので、社内の全部のPCを使えばいろんなデータをバックアップしながら複数人で分散し、いろんな社員のPCのCPUタイムを使えば十分なことができます。

ただし、前提として中小企業ではこれらは難しいかもしれません。。でもクラウドなんてものをやってみようなんて言うところは案外大企業が多いです。


言ってしまえば私の話なんて極論です。でも、自社の社員のPCに暗号化されているデータと、どこかのSIerという会社が「暗号化してますよ」といっているセリフ。私だったら前者の方が安心します。
耐障害性も、社内のLANが有効で社内のPCがしっかりワイヤーで固定されていたら、火事や津波ではダメかも知れませんが、外部とのネットワークが切断されていても社内のPCだけで業務を継続できませんか?


私は本当にクラウドが顧客が本当に期待する当たり前品質を満たせるのか、甚だ疑問です。
目先のコストだけで流行にのっているだけに見えます。それはSIerや顧客共にです。
今はまだ何も起きていないから、良い方にも悪い方にもどうとでも言えます。
でも、SIerの責務はどうとでも言えることを言うことでも、100%であるかどうかを検証もせず答えられもせず、「大丈夫です。」と言うことでもないと、私は考えます。


お客様の皆様にはどうか、本当にどうやって自社の資産を守っていけばいいのか、単純にSIerの営業トークを聞くだけでなく、疑って、検証して、こういう場合はどうなのかを問い詰めて、その上で答えを出して欲しいと切に思います。

-----
2012/07/13 分かりにくい表現を修正しました。

2012年07月03日

開発方式、処理方式、開発標準という夢物語

日本のSIerは過去、もしくは弊社では未だに現在進行形で、開発方式、処理方式、開発標準を考えるべきだということが叫ばれています。それがないから開発に失敗すると。
実際のところ、そんなものは弊社では立てられないと心のなかで分かっていながらも、私も「そうだ、そうだ」と叫んでいたこともありました。

そして、今現在進められている案件でもまだ、開発方式、処理方式、開発標準をどうするかだけでなく、各案件で開発方式、処理方式、開発標準が策定されている始末です。つまり、確定していないし、現在進行形でそれぞれの人達がそれぞれ開発方式、処理方式、開発標準を作っているのです。

が、はっきり言えば、日本のSIerが叫ぶ開発方式、処理方式、開発標準(以下、まとめて方式と呼びます)というものはいずれも、中身が無い空虚なものです。これができれば、開発が少しはうまくいく、効率化、省力化できるという夢が語られたりもしましたが、絶対にそんなことはありません。最近はそんな風に考え方が変わってきました。

これら方式とは誤解を恐れずに言えば、究極的に抽象化された、たった一つしか存在しない銀の弾でなければ作る意味はないでしょう。
でも、さすがに作れないため、現在では各プロジェクトごとになんとか銀の弾を作ろうとしています。それすらも結局作れずじまいです。
たったひとつ、全てを抽象化した完全な方式は存在するのでしょうが、存在しても作ることができないでしょう。できて規約までです。

規約はとても有効に働くでしょう。規約は反転すればチェックシートになります。チェックシートはそれを満たせば、成果物が規約の範疇を保証する強力な武器になり、チェックシートに記載された事柄が満たされなければ、突き返すことができる強力な防具にもなります。
そう、開発の現場では、規約とチェックシート、マニュアルやガイドさえあれば、実は十分開発を行うことができます。あえて事前に方式をたてる工数を作っても無意味なことがほとんどです。

それはなぜか。

その理由は案外単純です。方式とはある種現状では中途半端に抽象化されたレベルにしかならないため、実際にしようが固まれば固まるほど、方式の範囲を超えたどうしようも無い例外が発生するためです。結局、最初に立てた方式はなんとなく実現できそうでも、何時の間に苦しまぎれ例外が多くなります。これが後々の保守性を非常に低下させます。

例外ばかりで実装されたシステムほど、どう見たらいいのかわかりません。どう修正したらいいのかもわかりにくいのです。
であれば、中途半端な方式を立てるぐらいなら、まだ何もないほうが工数は無駄になりません。
ただし、もちろん事前に完全に抽象化された方式が立てられ、例外が出ない、もしくは方式に吸収可能なレベルを実現できるのであれば、あったほうがいいでしょうが、ここではそこまでのレベルのものはそもそも作ることができないという立場に立っています。


本当に使える方式を立てるにはどうしたらいいのか。

それは、全ての開発工程を今まで苦労も含めて経験し、そして技術も業務も管理も保守も運用も全て熟知した人間だけが、それらを俯瞰してあるべき姿、つまりべき論を導き出すことができます。

ですが、今現状、弊社で方式を立てようとしている方々は、いかに今わかっている仕様だけで自分の考えている方法論で作るかしか頭にありません。
そうではなく、本当に使う側に立った視点で見ていないのだから、作れないというのが私の意見です。
まずは、本当に各プロジェクトでどういうことがあったのか、分析するところから始め、上から目線をやめ、いろいろな工程の担当者から話を聞き、コミュニケーションを受け、真摯に耳を傾けなければ、真の方式はいつまでも夢物語でしょう。

では、具体的にどうすべきかについては、また順次記載して行きたいと思います。まだ、まとめきれていないので、ちょっと時間がかかりそうですが。

2012年07月02日

コミュニケーション能力とは何なのかな

よく言われるコミュニケーション能力。

いつも言われることは、飲みニケーションや趣味が充実していることが、最終的には営業としてうまく成約に結びつくという話です。彼らの言い分としては、飲みニケーションはコミニケーションを潤滑に行うために必要ということです。また、話の面白さもそういう面でコミュニケーション能力の一つだということが叫ばれています。
論理がおかしく、飲みニケーションはコミュニケーション能力の一部であるという主張をいいながら、それが全てでそれがなければコミュニケーション能力があるとは言えないと言い始めます。
話が常にそれぞれ独立して論理を展開するため、聞いている側は反論できないのがポイントです。
そして、それを発揮するから仕事が取れるという言い分をよく聞きます。
そうするから顧客から信頼が得られるとも主張されます。

さて、コミュニケーション能力とはどういう意味なのでしょうか。
普通に訳すと意思疎通でしょうか。Wikipediaによれば、「交流」であり、「生命体 (人間、動物、植物、微生物等)が、感情、意思、情報などを、発信受信応答、つまりは、相互連絡関係をもとうとすること。」のようです。
ポイントは相互に連絡関係がある状態であることでしょう。

意思疎通。意味は、自分の意思(考え、思い、感情、情報が主たるものでしょう)について、相手が疎んじている状態を通ずる状態にすることではないでしょうか。
疎んじている状態とは、理解が不完全であるということです。それを通ずるようにするということは相手に理解させるということです。

コミュニケーション能力は、会話の能力ではありません。相手に理解させる能力です。

確かに、英語において話すに関連する英語は、speak, talk, chat, lay on, conversation, open one's, tell, ask, have face等があります。これらは意味が異なり、speakとtalk(の半分ぐらい)は一方的な能力、askやtellは問い合わせる能力、chatやconversation、その他は会話や雑談のような意味です。では、理解はというと、comprehendやunderstandがありますが、これらは〜を理解するという意味です。
どこにもcommunicationが出てきません。ここでよく言われる飲みニケーションを考えると、確かにコミュニケーションを取る上で、話すということや理解するということはコミュニケーションの重要な要素、手段であることは確定できます。が、必ずなければならないというものでもありません。

なぜそんなことを言うのかといえば、私はコミュニケーションについての研究を学生時代担ってきたからです。
コミュニケーションには、大きくバーバルコミュニケーションとノンバーバルコミュニケーションがあります。この二つを発揮することがコミュニケーション能力を発揮するということです。
そして、バーバルコミュニケーションは、口頭でなくても手紙でもよく、むしろ飲み屋でなくても、面白い話でなくても、趣味が通じなくても良いものです。
ノンバーバルコミュニケーションは非言語コミュニケーション。つまり、仕草や表情といったものです。これらを駆使し、相手に自分の主張を理解させることができる能力をコミュニケーション能力というと私は考えます。ポイントは、バーバル、ノンバーバル両方もしくは片方を相手にあわせて適切に使いこなすことができ、その結果相手に主張を理解させることができることです。

以下は、とても失礼なことを言います。不快に思う方がいましたら、本当に申し訳ございません。ですが、言わせていただきます。
コミュニケーション能力がそのように定義されなければ、もし障害があることで話せなくなった方、耳が聞こえなくなった方はコミュニケーション能力を絶対に持てないことになります。
また、お酒が飲めない方、無趣味の方は相当な努力が必要になってしまいます。
元々の先天的、後天的な状況をもってしてコミュニケーション能力の有無を語ることは、本来の意味の達成とは異なるのではないかと考えました。

私はコミュニケーション能力とは、相手の理解のために努力すること、そのために言葉や表情、仕草、資料等をどこまで相手の理解のために用意でき、その用意を相手のために奉仕できるかではないのかという、思いやりの能力だと思いたいのです。
その結果、営業的に成約できるのは、誠意と信用が生まれた結果であって、決してコミュニケーション能力の有無とはまたこれらは関係ないとも思いたいのです。


最初の多くの主張である飲みニケーションはchatやconversationであって、communicationではないと思います。どこかでうまく、相手の中に信用を得ることができたり、探り探り相手の考えをくみとることができたり、もしくは本当にcommunicationが部分的に発揮できた結果、飲みニケーションで成果が得られ、それがいつの間にかコミュニケーション能力の一部と勘違いされたのではないかと思いたいのです。


コミュニケーション能力とはつまり、誰かが一部の人間のための能力ではないということを言いたく、また、有無について語ることは無意味だと思います。無いのではなく、思いやりや相手の理解への配慮が足りないだけだと考えたいと思うのです。


これらは完全に私の個人的な意見です。人の考え方についてどうこう言うつもりもありません。
ただ、よく言われる「あいつはコミュニケーション能力がない」というのは、もっと考えて私も発言したいと反省しました。これは、それ自体が相手とのコミュニケーション、つまり相手の状態への配慮が欠けた状態だからです。これは、そもそもの人間関係を醸成する行為の否定であって、自らアンテナを閉じた状態なのかと考えました。
ここから色々と考えて上述の思考にたどり着きました。

勝手ながら、きっと私たちは思いやりという面で、何か重要なものを忘れてしまったような、そういうことが感じられることが多く、私はもっと反省すべきと気づきました。という告白です。


余談ですが、社内で飲みニケーションが推奨される会社もあります。ポイントが発行されたりというところもあるそうです。それはコミュニケーションとは別としてもおもしろいと思いました。

2012年05月01日

弊社で叫ばれている内容を聞いて感じたこと

これから書く内容は、たくさん失礼な内容が記載されています。
気分を害された方は無視して下さいませ。

私自身、SIerで働いています。その中でも色々とやはり議論を重ねているのですが、どうやってもみんなの考え方が分からない面があります。
それが標準化というものです。
設計を標準化する、製造を標準化する、そのために評価方法、分析方法を定量的にし、フレームワークを当て、誰も自由な設計や製造ができないように当てはめていこうとする考え方です。
これは別に間違えではないと思っています。それが、SI業界でなければです。
まずそもそも、品質に問題があって炎上したプロジェクトにおいて、炎上した原因は2つのどちらか、もしくは両方しかないと思います。

1) そもそも達成できない予算のプロジェクトで、お金がない
2) 参画している人間のスキルがない

よって、なぜ失敗したかなんて分析するまでもないと思っているのですが、会社ではバグの内容は何だったのか、それによってどれだけの影響がどうでたか?
そういったことを分析したり、収集したりしています。そして、ずっと分析結果は出なかったりしています。。。
対策方法もありません。予算を増やすか、参画している人間のスキルがあがらなければ、どんなに一番簡単で泥臭いやり方であるチェックリストを作ろうともチェックするのが人間なのだから、抜け道ができてしまいます。

まぁ、それでも標準化したら、スキルのない人間でも、それしか設計できない、それしか実装できないようになるのだから、品質はあがるだろうという認識のようです。
そもそもソフトウェアにおける品質なんて、要件通りに作るのが品質の基本であって要件通りでなければ品質は満たしていない、それ以上は品質の向上ではなく、満足度の向上でしかないという事実は無視されています。

もしも、もしも本当にそんなことができるなら、きっとSAPやOracleはもっと日本市場に力を入れてもいいと思うでしょうね。
それぐらい日本の商習慣や各社の文化はかなり違い、また、パッケージがあるべき姿をある程度投影しているのに、業務をパッケージに合わせるのではなく、パッケージを業務に合わせて、カスタマイズと言う名前のスクラッチ開発をしたりもしていますよね。


簡単な例でいえば、ナンプレが作らないといけないシステム、その上で答えようとしているのが幼稚園児レベルのスキルの人間なのが、現在のSIerの状況です。
ナンプレの問題を作るのは顧客の要件がポイントです。ナンプレであれば、これだけ揃えばかなり簡単になるとか分かるでしょうが、顧客の出す要件はそもそもそのナンプレの問題にすらなっていないことがあります。だから、せめて目的だけでも要件定義しなさいとは思うのですが。。。
でも、なんとかナンプレの問題になるレベルが出たとしても、それを解くのは幼稚園児レベルです。もし、幼稚園児が解けるのであれば、その分野においてはその幼稚園児は中学生レベルですね、きっと。でも、幼稚園児ではなく、幼稚園児レベル。。。

そして、SIerではPMOが幼稚園児レベルの人に、「何で間違えたんだ?」とか、「何で答えがあっているか確認しなかったんだ?」とか叱っている風景ばかりです。
その中で優秀なSIerの社員は、標準化を掲げて、設計や製造の自由度を下げて、幼稚園児レベルでも解けるよう、正確には考えなくてもいつかはあてはまるように、考えてあげているわけです。
それは少しシステム化され、ナンプレの問題が本ではなくExcel上で書かれていて、一箇所数値を埋めると、自動的にその数値は他の箇所では使えないように選択肢が選択できなくなるレベルのもの。それでもないよりはマシかなというレベル。
もしくは、事前に答えのチェックができるのかもしれないですが、そんなに柔軟に判定できるシステムを作れるなら、最初から不具合のないシステムを作れるのでは?

そして、そんなにすごいもの、当然優秀な社員でも作れないのです。

時間も工数もなければ予算すら割り当てられず、というか、優秀な社員でも一人で何か一つのアプリケーションを作ることができないのですから、、、そんなすごいシステムを作ることは難しいです。
せめて10万ステップのプログラムを一人で作ったりとかできればまた違うのでしょうが、そんなスキルのある社員はSIerにはほぼいません。


余談ですが、SIerの社員で最も求められていると勘違いされていることの一つにコミュニケーション能力があります。でも、コミュニケーション能力は話がおもしろいとか、そういうことではなく、いかに相手に要点を理解させるか等の、その方法論であることは気づかれていないところが面白いです。よって、ノンバーバルコミュニケーション能力が無視されています。本当のコミュニケーション能力について理解されないまま、あの人はコミュニケーション能力があるとかないとか話されているが面白いです。話が面白いのはコミュニケーション能力の一つではなく、一部でもなく、要素に過ぎないのであって、他で補間できるのであれば必須ではないというのも事実です。


話がそれましたね。。。もう少しついでにそらすと。。。
ミスに気づかない人間は、何度やっても何年やっても、それをミスだと知らされても、そうならないよう努力してミスの根本を理解し、なぜそれがダメなのか理解できるまで、何回でもミスに気づかないままです。


弊社は1960年代に設立された比較的古い大手のSIerです。でも、人材確保に難点があります。それは上記の考え方があるから、幼稚園児レベルでも人間を集めて、人数で工数を出せば儲けられるという商売の仕方が根底にあります。
対して例えばGoogleやMicrosoft。Microsoftはそれでも古い方ですが、Googleは1998年設立です。それでも弊社はすでに企業規模で負けています。名前でも負けています。
Googleには比較的高いスキルレベルの人間が集まりますし、集めてもいます。誰でも入れる会社ではなく、また入ってからも生き残りが大変です。

あえてこれ以上は言わないでおきます。優秀な幼稚園児に申し訳ないので。。。

今、SIerは先に何をすべきか。業務を拡大するのもいいでしょう、標準化して幼稚園児レベルでも少しでもパズルが解けるよう手助けするのもいいでしょう。人それぞれの考え方はあるので、それをやめろとは言いません。
でも、前提を間違えていると思います。SIerは頭脳労働がメインの業種です。
思考レベルを高めない、高くなくてもいいという方向で、結局間違えることをする人間ばかりで、チェックする、答え合わせするだけのシステムでは、根本的な対策になっていません。
とはいえ、そんなことを言っても、それに賛同する人間が少ないので方向性は変わらないでしょう。

今後、少なくとも弊社は生き残れないかもしれませんね。。。

2012年04月05日

フレームワークが提供するロギング機能について

特にJavaについてですが、フレームワークが例えあったとしてもパフォーマンス上もしくはコーディング上、さらにはこういうものだという思い込みもあって、各クラスにログ初期化コードをそれぞれ記述しているのではないでしょうか。

例えば、Apache commons-loggingであれば、

public class Sample {

private static final Log LOG = LogFactory.getLog(Sample.class);

/**
* 業務処理
*
* @throws Exception システム例外
*/
public void process() throw Exception {

}
}


これはとても最適なコードのように見えます。初めてSampleクラスが初期化された際に、たった一度だけログ出力用のインスタンスが生成されます。

ですが、これらが各業務プログラムに乱立すると、どのクラスだけをログ出力したいか、簡単かつ詳細に定義できないことが多いのです。
例えばこのクラスが共通クラスであり、APサーバ上の共通libに配置しなければならない場合、このクラスは全てのWebアプリケーションから透過的に扱われることになります。
では、AというWebアプリケーションサーバではこの機能はログ出力したいけれど、BというWebアプリケーションではこの機能はログ出力したくない場合はどうしましょうか?

そもそもそんな需要はない?
性能を測定したいとか、障害が発生したとか、そういうこともないシステムならいいのでしょうが、実際にはそんなことはありません。

ログの制御は、log4jやLogBackを普通に使うのではなく、多少コストがかかったとしてもフレームワークが担い、ログインスタンスを業務処理に引き渡すべきです。
そして、フレームワークはシステムをわざわざ停止させなくとも、あるタイミングから業務処理を呼び出す時に引き渡すロガーの内容を、性能計測用、障害検出用、通常運用用と動的に切り替えられる仕組みを持つべきです。

ある1プロセスで、EAIアプリケーションのように複数のデータ転送を行う場合、例えば複数のサイトにFTPやDB、MQに接続する複雑なシステムの場合、縮退運転でサービスを停止させられない場合、これらにおいて、フレームワークがログ出力を動的に制御する機構を備えていることはとても保守運用者を安心させます。

残念ながら、未だにログ運用まで考慮できたフレームワークは見たことがありません。あくまで作る側の視点での出力です。それは、NTTデータのフレームワークですらできていないと言えることなので、絵に描いた餅という意見と言われても仕方ないのかもしれません。。。

少なくとも私は過去の案件において、フレームワークでログ制御を実施したことがあります。その際は通常何も問題がなければ実は動作しているかどうかも分からないぐらい何もログを出力しないシステムでした。つまり、起動しましたというログしかでません。

でも、実行中フレームワークが呼び出した第一階層の業務プログラムはフレームワークがログ機能を完全に制御し、まだ業務プログラムが扱う値はセッションのように値を保存することを前提とさせたため、障害が発生した場合(つまり例外が発生した場合)、拡張したロガーがどのプログラムで、どこまで処理してどういう異常終了したか、またその時の持ち回り変数の値は何だったかを全てダンプ出力するようにしました。

通常、障害がなければ何も出ませんが、障害があるときだけ、メモリの内容をほぼ吐き出し、ロジック上のスタックトレースや例外メッセージだけでなく、フレームワークがどこまで制御していたかまで出力することを実装したことがあります。

これは有識者が見れば、すぐに原因が分かるレベルでしたが、さすがに運用保守の人間では難しすぎたため、今では反省しています。(とはいえ、運用保守の人間が見るログと解析する人間が見るログ、統合運用監視システムが見るログはそれぞれ別で、それぞれに応じて出力内容を制御したりしましたが。。。あと、出力順にも優先度があったりなど)

そして、フレームワークでログが出せない場合(OutOfMemoryなど)は、APサーバがログ出力します。よって、アプリ用の通知ログ、APサーバのログ、APサーバ自体のプロセス監視、あとは、JMXよりももっと簡単にHTTPでシステムやスレッド(スレッド名を機能名に変更し、問い合わせしやすくしたり)の状態を確認できるようにし、運用監視できるようにしたことがあります(もう2年も前か。。。)。

昨今、正常実行中に無駄にログが出る割に、障害では必要なログが出ないシステムが多いと思います。少しでもそのような状況を改善できないか、模索中です。

2011年07月23日

極論であっても、やっていることを他のことに例えてみる

「それは極論だよ」なんて言われる経験がある方もいるかもしれません。

コンピュータの世界だけではありませんが、物事を抽象化することがあります。
抽象化することは、共通部分を見つけ出すことに近しいものです。
その共通化部分を究極まで切り詰めて見つけ出し、何にでも当てはめられる法則まで持っていくことをしようとすると、その時に「それは極論だよ」と言われます。

「何にでも当てはめられる法則なんてない、そんなことは当たり前だよ」
これは当然です。言い換えれば「例外のない法律はない」みたいなものです。

でも、自身の行動の規律を考える上で、この極論まで考えるというのはとても大切だと思います。
本当に極論を考えることになっているの?と思われるかと思いますが、例を考えたいと思います。
あくまで例であって、私が言おうとしている問題とはかけ離れたところです。ですので、矛盾などを見過ごしてみていただきたいと思います。

本を読むという行動を考えます。本を読むという行動を考えた場合、

1. 本を選ぶ
2. 本を買う
3. 本を読む
4. 読書を一旦中断する
5. 読書を再開する
6. 本を読み終える

これは料理するという行動と類似しているのではないかと考えます。

1. 料理を選ぶ
2. 材料を買う
3. 料理を作る
4. 料理を一旦中断する
5. 料理を再開する
6. 料理を終える

別に問題はありません。ですが、読書と料理では、一旦中断した場合の期間に違いがあります。
読書は1年でも10年でも、本が朽ちなければ一旦中断できます。料理は?料理は1年中断したら?もしかしたらまだ食材は持つかもしれません。10年保存しますか?冷凍すれば良いかもしれませんが、冷凍できないものもあるかもしれませんし、10年も保存したらまずいものもあるでしょう。。。

単に読書を他の料理するという行動に当てはめた場合、一旦中断するというところに違いがあって、極論、それを抽象化して共通的に考えるなんてナンセンスだと言われます。
この例は、確かに無意味かもしれませんね。


ここから本題です。

AさんはIT企業でPGをやっている10年目の社員です。ある日、先輩や上司から「このプログラム、3日で確実にできる工数で、実際にその工数で普通の人はできると第三者からも評価されたものだ。だから、3日で完成させてくれ」と言われました。
即座にAさんは、「自分の力では無理です。」と答えました。「体調が悪いのか?都合が悪いのか?緊急の用でもあるのか?」と聞くと答えは、「自分には、その詳細設計書の内容は難しすぎます。」と答えました。先輩や上司は諦めて他の人を探しに行きました。。。

極論です。もし野球ファンの方がいらっしゃったら大変失礼かもしれませんが、ご容赦ください。
プロ野球の選手に例えてみてください。

Aさんはプロ野球リーグで、10年目のセンター担当の選手です。ある日、監督や先輩から「次の試合、センターで、センターにきた玉はしっかりキャッチしてくれ。普通のセンターならキャッチしているような玉は確実にだ」と言われました。
即座にAさんは、「自分の力では無理です。」と答えました。「体調が悪いのか?都合が悪いのか?緊急の用でもあるのか?」と聞くと答えは、「自分には、センターの役割は難しすぎます。」と答えました。監督や先輩は諦めて他の人を探しに行きました。。。


ただの言葉遊び、すり替えでしょう?と言われても仕方ありません。
けれど、IT業界ではそれでもずっと給料をもらえます。でも、プロ野球の世界ではAさんはもう「引退」の言葉をつきつけられるほどのことをしていると言われても仕方ないのではないでしょうか。

できないことが悪いことではありませんとだけ、付け加えさせてください。
でも、せめて「どこまでやれるかわかりませんが、やらせてください」と言うことはできます。


自分の作業を他の業界であったらどうなのだろうかと置き換えてみてください。
例えばIT業界であれば、建築業界でもいいでしょう。
今作っているシステム「仕様がずっと確定していないけど、もうすぐリリースだからこのまま10万ステップのプログラム、不具合ありでもリリースしようか」という感じで、建築業者が「ビルの構造がずっと確定していないけど、もうすぐ工期が終わりだから、このまま33階のビル、そのままオープンしようか」と例えてみてもいいと思います。


所詮、極論です。所詮、共通化してみた言葉遊びです。考え方ややり方を抽象化してみただけです。
「そうだね、言葉遊びだ。極論だから、考えることはない」と言うのは、そこは人によって主義主張あると思いますので強制しません。

でも、一度、この極論で自分の行動を考えてみて欲しいと思いました。


「本当に、それは極論だよ、という言葉で片付けますか?」

2011年06月20日

私が上司になったら

私はまだ上司という立場ではありませんが、先輩後輩という立場でプロジェクト内で実践したことがあります。
それは、部下(この場合は後輩ですが)の愚痴や要望、やりたい事を聞くということです。
これは酒の席であれば、酒の勢いで話しやすいこともあるでしょうが、結局聞いたことを忘れてしまいやすいです。また、メモを取らなければ、真摯に聞くという気持ちも出てこないものです。

どんな内容でも愚痴を聞きました。「やり方が良くないのではないか」、「答えは分からないけど、これはおかしい」等です。
対して私の返答は「なるほど、〜ということで認識はあっている?」「なるほど、私もそう思う。では、一度持ち帰って率直に試してみるよ」「なるほど、私は〜だと思う」という感じで答えました。

また、最初は当然後輩といえでも身構えてしまうでしょう。どうやったって意図はなんだろうかと勘ぐってしまうものです。私は先に、こう目的を切りだしています。

1. 愚痴を出しきって、少しでもストレスを出したい。
大きな声で人に聞かれたくないことでも会議室なら聞かれにくい。
2. 酒の席では真面目に聞いてあげられなくなったりする。
でも、酒の席がよければそっちでも聞くよ。
3. 自分もたくさん愚痴があって、会社や自分の上司、もちろん君にも愚痴があって、
実は聞いてもらいたい。その愚痴から君も言いたいことを言っていいし、
自分で気づかなかったより良くする方法にこっそり気づいたらラッキーかなと思った。
4. プロジェクトは結局なんとか回る。
けれど、やりたくないことをずっとやり続けて回すんじゃなく、
やりたいことをやって、それでプロジェクトが回るように配置したいんだ。
5. 一対一なのは、他の人がいると言いにくいこともあるでしょう。
だからここの話はここだけの話にしてほしい。私の分は少なくともね。

直接口頭ではもっともっと簡単にピックアップして説明しますが、ここでは色々と目的を記載しました。


多くの上司や先輩は忙しいことも多く、また業務の進め方の良い点として、結論先出しもあって
「何が問題で、どうして欲しくて、それでどうなるかを説明しろ」
「愚痴とか誰かをせめるのではなく、建設的・前向きにプロジェクトをどうしていくかを考えよう」
「だからなんなのか?ただの愚痴で終わったら何もできない」
と言われやすいです。
ですが、本当のプロジェクトの問題は、あくまでも漠然としていて、しかも下っ端ではどうしたらいいか
力も権限も人脈も何もなく、それでも一番の実態を知っているのに何もできないという状況だと、私は考えます。だから上記のように言われると、下はもう何も言えないのではなく、言わなくなります。
また、上司は部下の言葉を真面目に効いていないとも思います。
いつもは「人生相談だってなんだって乗るよ」とか「なんで俺に相談しないんだ」など飲み会で言っていても、所詮それは言葉だけだと痛感させてしまうのです。

これは後輩たちが打たれ弱いのではなく、また勇気が足りないとか、昔と変わったとかではなく、誰でもそう感じるものです。ただ、そう感じた後にどう動くかが世代や性格によって違ってきているだけなのではないかと考えています。

でも、愚痴をメインにしたら結局答えはでないでしょう。それは分かっています。
人間は思っていることを言えないことがまた、大きなストレスになってしまいます。同期やさらに下の後輩に言っているうちは良いでしょうが、それでも解消しきれないストレスとなった場合、それは行き場を失います。本当は上に投げるべきものなのにです。
何でも言える場を提供してあげることも重要です。

また、下の愚痴からプロジェクトの問題点を抽出、推敲、類推できない上司は、正直なところもう無能な上司だと言われる時代だと考えるべきでしょう。
そこにはいろいろな問題点と解決策があるはずです。ただの愚痴だと思ってしまったら、ただの愚痴です。でも「そんなところに答えもアイディアもないと思うところにアイディアがあるかもしれない」とよく上司は言うのに、愚痴からはアイディアを探さないのは、単純に自分のことややり方を批判されたくないだけではないでしょうか。
上司の度量として、真摯に後輩の指摘を愚痴でも聞き、修正していくということを見せなければ、後輩が成長しない姿をなぜ注意できるのでしょうか。
「最近の若者はなかなか理解できない」は、簡単にいえば我々先輩がなかなか勉強もせず新しいことを取り入れていないからのように後輩からは見えています。だからこそ、私は誰よりも最先端のやり方も把握しようとしています。愚痴から取り入れようというのも、その一環です。。。
愚痴では前に進まないのではなく、また愚痴では結局どうしたら良いか分からないのではなく、その愚痴から本当の問題を抽出し、解決策を考えるのもマネジメント職の仕事だと私は考えます。

ただし上司側も、色々と聞き出したくて聴きに行くんだけど、やっぱりなかなか話してもらえないと思うでしょう。だからこそ、自分から自分の上司の愚痴をわかり易い言葉で後輩に先に話すのです。
先に、「上司がこうだから、本当はこうしてやりたいんだけどなかなかできないんだよね。。。難しいし、君が何がやりたいかもっと明確にしてくれたら、もっと君のやりたい事をサポートできて、それを理由に上も動かせるのにさ。だから、上を動かすためにも先に君のやりたい事を教えてほしい。もしくは一緒に考えよう」と言ったりします。



ただし、全ての後輩に対してやるとこれは大きな問題です。後輩一人ひとり性格が違います。
これをやって結局言いふらしてしまう子もいるでしょうし、私生活の話に飛んだりする子もいるでしょう。
真面目な子に対してやると効果的ですし、人によって時間をうまくコントロールすることも重要です。
人それぞれの性格をどれだけ見て、その子が何をしているかをどこまで把握しているか、当然上司として求められる物です。そこまでやって、適切に愚痴を聞き、プロジェクトを回すのが必要です。


私が上司になったら、どこまでうまくやれるかは分かりませんが、こういうことをしっかりやりメンバーマネジメントを図りたいと考えています。

2011年05月24日

人に対する許容というもの

プロジェクトマネジメントはとても難しいものです。
そのなかで、メンバーのモチベーション管理やそもそものヒューマン系管理は非常に難しい物があります。

今、プロジェクトの中で、メンバーの1名が顧客からも他のメンバーからも許容されていない状態にあります。
私はそのメンバーを見ていて、感じたことがありましたのでここに記載しました。

人が人に対して、その人を受け入れられるかどうか(ここではそれを許容と呼んでいます)は3つの要素で表現できるなと感じました。これらの言葉は勝手につけましたので、心理学的にどうだとかではありません。
もしかしたら、正しい言葉があるかもしれません。申し訳ございませんが、調べておりません。
また不快に感じましたら、本当に申し訳ございませんが、ご容赦ください。

A) 生理的許容
B) 発言に対する許容
C) 行動に対する許容

生理的許容は分かりやすいですが、例えば匂いだとか見た目だとか清潔感など、直感的な面も含めたものです。こればかりはどうしようもない面も当然あります。

発言に対する許容は、その人が言ったことに対する許容です。思っていることは当てはまりません。また直接その人に言ったことでなくても、人の悪口を聞いていた人が、言っていた人をどう思うかも含まれると思います。

行動に対する許容は、その人が行ったことに対する許容です。最悪、暴力まで含まれますし、細かな癖など、小さな行動も含まれます。

ここで、例えば性格だとか、思想だとかそういうものに対する許容もあるとは思いますが、人が考えていることなどは結局見えませんし、最終的には上記A,B,Cのどれかに表れてくると考えました。


感じたことは4点あります。

1. A,B,Cそれぞれ、人によって許容可能なレベルが違います。そして数値化しにくいものでもあります。
2. 人は多くの場合、相手がA,B,Cのうちいずれか1つに当てはまると関わりたくない人になり、2つ当てはまると嫌いな人になります。
3. 友達や日常の人付き合いでは、だいたいの場合、A > B > Cの順で優先度が変わります。つまり、生理的に許容できない人ほど、日常では関わり合いたくない度合いが強くなります。
4. 対して仕事では、C > B > Aの順で優先度が変わります。仕事では生理的にというよりも、行動の許容を超える人に関わり合いたくなくなります。

私のプロジェクトのその人は、Aの生理的許容という面では、だれも嫌がっていないのですが、BとCの面で非常に嫌われています。
もちろん、仕事もとてもよくできますし、経験も知識もあります。言っていることも大体正しいでしょうし、プロジェクトの上の方に当たります。そして、面白いことに性格は実は、相手のことを考えて行動するなど、気がきき、生理的にも全く問題ないのです。
ですが、発言が攻撃的でパワハラに近く、行動もあまり褒められたものではありません。それだけで嫌われてしまっています。
逆に他の会社のメンバーはまだ行動に対する許容度の範囲内のため、その会社の方からはまだ良い人だと思われていたりです。


これを受ける部下は逆に不幸だったりと、人というものは非常に難しい物です。
今は周りの人間のモチベーションをいかに維持するか、その補完をする必要があるため、なかなか仕事が大変です。
私の余計なお世話になっている面は否定しませんが。。。

2011年05月23日

システムの再構築について

大企業のシステム開発において、これまではよく、システムの再構築案件が多くありました。
これからはクラウドを企業が取り入れていくことも多いでしょう。その場合、これまでの基幹業務システムの再構築とは一風変わったシステム開発になるかもしれません。
これからお話しするのは新しいことではなく、むしろ古いシステムの再構築についてです。

システムの再構築においては、現行システムをホストからオープン系に変えることが多いと思います。個人的にはオープン系という言葉はあまり好きではありませんが、ここではオープン系と表現します。

その変更において、オープン系にするのは色々と理由がありますが、多くは運用保守費用の低減があると思います。ホストよりもハードウェアやミドルウェアの制約が少なく、階層型DBのようなシステムの改変がややしにくいものよりも、仕様変更に強いという魅力をSIerは提案しているはずです。
また、その際にSIerは出来る限りの仕様変更を取り入れることも提案していることでしょう。
つまり、この再構築は、現行運用を踏襲しながらもオープン系に切り替えることと、オープン系にした際に合わせて仕様変更を行う2つの目的が含まれています。

話はそれますが、要件定義では要件を決めること以上に大切な事があります。
それは顧客のその案件の目的を明確にし、顧客がそれを理解するということが大切です。
目的が決まっていない案件は、話が収束しません。もし現行の再構築であれば、まずはそれを優先していかなければ、そもそもの目的すら遂行できないことが多いと思います。そして、それがプロジェクトの失敗につながります。
要件定義では顧客からの要求分析結果を元に、顧客の抱える問題からシステム開発を行う目的を明確にすべきなのです。その上で、顧客のビジネス上の効果が表現されます。ただし、このビジネス上の効果は私たちSIerが提案や可能性を考えることはできますが、実現するのはSIerではなく、顧客自身であることも明確に顧客に理解させる必要があります。
1億円で開発したシステムだから1億円以上の利益が出るかどうかは、使う人と使い方次第です。
これは私たちSIerが無責任にシステムを作ることとは無関係で、要は顧客もシステムを作っているという責任があることを示しています。
よって、顧客もシステムを作る上で利益や効率性を考えるのであれば、つまり目的や狙いを達成していくのであれば、顧客自身もシステムを開発する立場に立ち、運用要件や業務用件、性能要件を積極的にSIerに提示し、要件の達成を求めたり、交渉する必要があります。

もう1つ異なる話をします。
目的は2つ以上あると、よく失敗します。それが結果的に同じになる目的であれば1つと見なせるでしょう。2つある目的は必ず方向性の違いや、さらに運が悪いとプロジェクトの方向性を見失わせます。
よって、目的が2つ以上あるのであれば、どちらを優先するのかを1つに絞らなければなりません。
2つあっても必ず優先度を立て、最優先の目的を1つだけに絞らなくてはいけません。
これは出来る限りSIerがあるべき姿を提案できると、素晴らしい提案になることでしょう。業界をよく調査し、その企業をよく勉強し、その企業のためになることを提案しているのでしょうから。。。
ですが、そんなことは大概は難しいどころか、その企業の人間が決めるべきことです。
要件定義フェーズで顧客は、必ず目的を1つに絞ることが求められるべきです。

話の脱線を簡単にまとめると、要は目的をしっかり1つに決めなさいということです。
さてここで、この脱線も踏まえて話に戻ります。


もしシステムの再構築を行いたい場合は、私は2フェーズにプロジェクトを完全に分けるべきだと考えます。
第1フェーズではオープン系に現行を完全に切り替えるという目的を立てます。その切替が運用に乗ったあとに第2フェーズで仕様の変更を取り入れる修正を施すべきです。
これは顧客にとってはビジネスチャンスの喪失も意味することは分かっています。
ですが、多くの場合はこのために顧客は通常よりも暗に多くのリスクを受容させられています。
SIerは必ず現行と新仕様との齟齬を簡単に吸収できないリスクを金額に載せています。そしてその金額は高いものです。
もしオープン系にしているならば、仕様変更は簡単だと言いながらも同時に行うと実は高いケースがほとんどです。
逆に言えば、仕様変更や保守費用が安くなるはずなのに第2フェーズでの開発費用が高いのであれば、そもそもおかしくありませんか?
よって、フェーズを分けた場合と分けない場合のそれぞれについて、顧客はRFPのタイミングでSIerに見積もりを出させるべきです。
おそらくSIerはより多くの条件と縛りを提案書に載せてくるでしょう。
でも、フェーズを分けたならば、最初は現行通りになり、後は運用保守費用が下がる方法なのですから、顧客から見れば縛りも金額も必ず下がらなければ、おかしいと思います。

期間が延長されることはあるでしょうが、運用保守フェーズという位置づけである程度の新機能を吸収できないのであれば、そのオープン系の効果は嘘でしょう。
また、人が必要というのであれば、再構築によりシステムの最適化がおかしくなっているはずです。
さらには、同時に2つの目的を達成するということで、できないと言われる仕様や最初から要件に話が出てきていないじゃないかと言うSIerはおかしいことを言っていると分かります。

私たちSIerはすでに、今までのシステム開発のやり方ではこれからは顧客からは選択されなくなると思います。
それこそクラウド上で簡単にシステム開発できる環境まであります。そうなれば、顧客は時間をかけるよりも内製で済ませるでしょう。

私たちはWin-Winの関係と大きなことを言います。私の会社でも大きく言っています。
でも、もうその関係性のいくつかの嘘を、是正すべき時期に、見直すべき時期になっています。むしろ、これからではもう遅いでしょう。。。



さて、私の会社は生き残れるのでしょうか。。。

2011年04月24日

Win-Winの関係

私の会社でも要件定義から保守運用まで行っています。
でも、今関わっている案件を踏まえて、確かに我社は利益を出せている案件もあります、一般的に言われるWin-Winの関係を顧客と築くこともできているかもしれません。
ただ、少なくとも私が今まで関わった案件は本当の意味でWin-Winだったのかなと感じます。

システムを作る人間は、次の段階を踏んで成長しているように思います。
第1段階 : とりあえず動くものを作る
第2段階 : システムはどうやったら動くかを考える
第3段階 : システムとはどうあるべきかを考える
第4段階 : 顧客にとってシステム開発はどうあるべきか考える
第5段階 : 方式論、方法論までシステム開発を昇華する

自分もずっとこんな考え方で、システムを技術的にどうすればよいかとか、システムはこうだと使いやすいとか、それを先に考えたりしていました。

我々SIerが言うWin-Winってきっと、本当は納品時点でのことかなと思います。もしくは、SIerにとってもっとおいしいWin-Winの形態って、運用保守までをそのSIerが担当することなんだと思います。
それは当然ビジネスなので当たり前なのかと思います。要はビジネスはどうやってお金を稼いでいくかにつながっています。Win-Winでありながらも自社にお金が継続的に入るビジネスモデルはありがたく、かつ利益の計算もしやすいものですし、顧客もアウトソーシングとまでは行かなくても、保険と同じようなものです。

これは決してWin-Winではなかった案件だと思いますが、私はたった一度だけ、要件定義から保守フェーズまで一貫して案件に関係したことがあります。
B2Cの案件で、開発はそこまで運用までは考えていませんでしたが、システムを作る人間以外が新しく何か画面を作るとき、本当に何も考えなくても作れるようにしてしまいました。
画面上のあらゆるものが部品化され、その部品すらも複数が部品化され、さらにそれが画面レベルまできたとしても画面までも部品化されていました。似たような画面を作るとき、その画面を継承して、ちょっと文言の定義を変更して、入力欄が違っても、画面でちょっと部品を追加すると、バリデーションチェックまでできます。
業務ロジックもパラメータが可変で、入力数は可変でもしっかり関連チェックされ、DBのモデルも可変であることを考慮していました。性能面もセキュリティも考慮したりもしていますが、新規で作る人は考えなくてもよっぽど変なことを無理やりしない限りは問題が発生しないようになっていました。
当然、システム開発においてここまで作り込めたらなかなかな気がします。

そして、最終的にはかなりの利益になった案件です。かなりの成功になりました。しかも、カットオーバーも問題なく、運用もほぼ問題なく進みました。そして客観的に見て使いやすさや品質もよく、顧客は満足しておりました。おそらくここまではSIerで言うところのWin-Winだったのかもしれません。

その後、どうやって作ったのか顧客から教えてほしいという話題になりました。
うちの営業は「抗議してもいいですよ」と言ってましたので、事前に上司に講義内容を決め、資料もOKをもらったあと、私が顧客の技術部門に数回講義しました。
日本人ではありませんでしたが、たった数回の講義、1回1時間の講義で彼らはプログラムもできたので、新規に画面が顧客からの要望案件がありましたが、彼らが1日で作ってしまいました。テストも1日ちょっとでした。要は、私たちが作ると営業から「10日はかかりますね〜」と持ちかけたけれど、実際は2日で作れてしまいました。

その後、その案件に関しては彼らは「自分たちで運用でき、新規の開発もできますので、御社からのサポートは不要ですよ」、と通知が来ました。もし新規案件が他にあればということで、並行で動いていた新規案件がありましたが、以降は大きな案件は発生しませんでした。

でも、もし難しくつくっていれば、彼らは自分たちで運用保守できなかったかもしれません。そうすれば、私たちに依頼が来たかもしれません。そうしたら、彼らは自社で作るよりもお金がかかったかもしれません。
では、彼らは自社で作るよりも他社に依頼したほうが安かったのか、私たちは簡単に作れるようにすべきだったのか、難しく作るべきだったのか。それとも顧客にはどんなことがあっても講義しないほうがよかったのか、それとも講義すべきだったのか、それとも中途半端な内容がよかったのか。


いったい、どれがWin-Winの関係になったのでしょうか。。。

私はWin-Winなんか考えるんじゃなく、顧客が真に使うシステム、いやいやではなく使い続けてもらえるシステムを作りたいです。

2009年06月22日

論理力を身につけることは簡単なのか?

どうやったらプログラムを作れるようになりますか?というような質問があります。
プログラミング言語を覚えれば当然作れるようになりますが、プログラミング言語とは結局のところコンピュータに何をやらせたいかを表現する言葉でしかありません。
コンピュータは人間がやってほしいと思うことを想像したり、先読みすることはできません。逆に言えば、人間が考えたことをその通りやることしかできないものとも言えます。
プログラミング言語は自然言語と同じで、文法が違ったり、単語が違ったり、その程度です。程度の差こそあれたいてい1つの言語を知れば、コンピュータでやらせられることに限界がある以上、他の言語も意外に簡単なレベルなら容易に習得できるものです。

私はプログラムを組むという観点においては、一番重要なのはそのコンピュータに何をやらせるかの手順をどうやって考えて、生み出すかだと思います。これを語弊はあるかもしれませんが、私は論理力と読んでいます。
コンピュータはあくまで論理的に動作しています。人間がその手順を論理的に矛盾が無いように考えられない限り、プログラムにまで落とし込むことは難しいと考えます。その手順を論理的に考えられるのであれば、その順序どおりにコンピュータへの命令を記述するだけだと思います。多くのプログラムができないという方は、その手順が考えられないケースが多いです。
そして、そこが一番難しいところでもあります。

ちなみに、当然昨今のシステム開発においては、ことプログラムだけ出来ればよいなんてことはありません。その部分は除いて、あくまでプログラムを作成するというところに注目しています。


私は論理力を習得する道は、書道と同じだと思います。
書道は、まずお手本と呼ばれるとても美しい字をまねるところから始まると勝手に思っています。どんな達筆と呼ばれる方(たいていは素人には何がよいのか分からないけれども)も、最初はきれいな字をまねて書き、きれいな字を書けるようになっていると思います。その上で、オリジナリティを出していると思っています。逆に、オリジナリティの前に前提となるきれいな字が書けないのであれば、書道の評価は下せないのだろうと思うのです。
書道では、何度もきれいな字を書くことによって、初めてきれいな字が書けるようになります。生れて初めて字を書くという人で、最初からきれいな字を書ける人はいません。
同様に論理力も何度もきれいなロジックを見習うことで初めてしっかりとしたロジックが分かり、考えることができるようになります。生れて初めてしっかりとしたロジックを考えようという人で、最初からきれいなロジックを考えられる人はいません。
センスは才能という面よりも、どれだけ後天的に人のセンスを見たかにもよると思うのです。

論理力も、アルゴリズム教本のような書籍を何度も何度も読み、その内容を何度も書き写すことで、手順はどんなものか分かり、習得できるようになると思います。
私自身も、本などから人のプログラムを何度も200本以上、フローチャートを手書きで描いたり、直接プログラムを入力し、どうなっているんだろうかと考えたり、変更してみたりしました。私は今思えば、最初は方眼用紙にいろんなことを書き写したり、アイディアを書いていました。
それをずっと続けていれば、新しいことを考えることができるようになると思うのです。だからこそ、今何も紙に書いたりせずに直接プログラムをきれいに作れます。

論理力と言っても、コンピュータでいえばアルゴリズム教本があります。
コンピュータ以外では、新聞の論理的矛盾を見つけてみるとか、論理力の本を読んでみる、普段の生活で、どういう順序で動けば最も効率的なのか、この行動はどういう意味があり、今後どう発展することかを考えると、身につくのではないかと思います。

当然、人のコピーでは本質的なオリジナリティではないと言われそうですが、そこに関しては私は否定できません。その純粋な意味でのオリジナリティはきっと、今まで一度もアルゴリズムを見たことも聞いたこともない人が、ある日突然閃いたときにのみ言えることでしょうし、そんなことが出来る人が天才と呼ばれると思います。
偉大な音楽家は、きっと過去の偉大な音楽家の曲を聞いて育ったと思います。が、最初の偉大な音楽家は前例がないので、本当にすごかったのかもしれません。
ですが、私はそこまでの天才ではなく、通常は過去から学ぶものだとも思います。


もし、プログラムを作れるようになりたいと言うのであれば、論理力を見につけるべきだと思います。
もし、論理力を身につけたいのであれば、一生懸命人の論理的思考の結果を学ぶべきだと私は思います。
何事もそういった努力をしてからではないでしょうか?