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年05月15日

なんとなく

ちょっと必要になるかもしれませんので、なんとなく作りました。
まだテストも作成していませんし、コメントも記述していませんが、
興味がある方はどうぞ

単純に、Value型に文字列やら日付やら、数値やらを自由に入れられるコンテナです。
あんまり役にはたちませんが。。。
ライセンスは、MITライセンスです。
もしかしたらもっとゆるいのがあれば、そちらに変えるかもしれません。
posted by Kiruahさん at 23:44| Comment(0) | TrackBack(0) | 日記

2011年05月05日

今日は紙婚式

結婚して今日で1年目になりました。紙婚式です。
とても幸せです。これも奥様のおかげです。いつもありがとうございます。

短いようでいろいろとあった1年でした。
とても楽しかったです。それも奥様がいたからです。
これからも幸せにできるよう、ちゃんとしていきたいと思います。

これからもどうぞ、末永くよろしくお願いします。
posted by Kiruahさん at 22:42| Comment(0) | TrackBack(0) | 日記

2011年05月04日

JavaでWebアプリのフレームワークも作ってます

今やWebアプリ向けのフレームワークと言えば、Javaも含めてたくさん出ています。
それはもうたくさん出ており、どれが一番いいかは難しいところです。
結局のところ、一番簡単か、一番最初に使った物がだいたい手に馴染みます。

Javaでもいろいろと出ております。でもJavaの場合はたいがい、
HTMLに対して何かしらの特別なタグを入れたり、HTMLから受け取った情報を格納するためのBeanを作成することが多いのが現状です。
Javascriptも何かしら組み込むことが多いです。たとえ、Javascriptが不要と言われていてもです。

最近の私は、出来る限りHTMLとCSS、JQueryとJQuery経由でAjaxをメインにしてブラウザ上で画面を動的に構築し、Java Webアプリサーバ上ではDBから取得した情報をJSONに変換してブラウザに送るだけみたいな役割分担で、簡単にアプリケーションを作っています。みなさんもだいたい近しい作り方になってきたと思います。もしくは、node.jsやRhinoでサーバでもJavascriptもありでしょう。

これでも個人的にはだいぶ簡単になってきたなぁとか思っていましたが、やっぱり面倒になってきました。
逆にJava Webアプリサーバ上で、Javascriptをブラウザに実行させちゃえというのが、今つくっているものです。
.NET Framework 4にもController.JavaScriptがありますが、これをさらにひどくしたやつだと考えていただければと思います。

正直なところ、実用性はありません。ぶっちゃけ実行させてみると、「うーーん、遅い」と思います。
当然セキュリティのところまでは実装にいたっておりませんので、ほいほいと攻撃できます。
そこら辺のチューンナップはおいおいやるとして、まだ基本実装を充実させているところです。
内部にJQueryを入れてあり、これ経由で実行させます。

サーバ上で、JQueryのSelector(JQueryのセレクタを生成してくれます)オブジェクトを生成してgetすると、ブラウザにJavascriptが送信されて、結果をブラウザ側にキャッシュしてくれます。
で、JQueryでgetした情報(JObjectに入ります)に色々とメソッドが用意されており、append("うさぎさん"); とメソッドを実行すれば、ブラウザに送られて、「うさぎさん」が画面に表示されます。
ついでにタグとか使うと、JQueryの$オブジェクトをキャッシュしてきてくれて、Java側でもそれを使えるJObjectがappendから返却されるので、さらにいろいろとできるようになっています。
(メソッドチェーンみたいな感じ)

ついでに言えば、JavaのクラスとHTMLが一対一で対応するようにしました。
よって、次の画面へ遷移する場合は、forward(new 次の画面のクラス()); みたいにします。
この時、次の画面クラスのコンストラクタとか、setterに色々と情報を前画面からセット出来ます。
HTMLは特別なタグも何も不要で、とりあえず操作したいタグにidを入れておくぐらいです。
別にJQueryなので、idでなくても良いのですけど。。。
SelectorにはJQueryのセレクタをひと通りいれたので、フィルタとかもメソッドがあります。
なので、HTMLには一切Javascriptを実装する必要はありません。

まぁ、こんな感じで作っております。だいたい簡単なチャットは作れるところまで来ました。
ログインしてないのにチャット画面に遷移するとログインにも移動してくれます。

企業のアプリ以前に研究用途にも使えませんが、VBの画面を作るような感じでアプリを作れる感じになってきました。
まぁ、妻は「なにこれ、超作るの簡単じゃん」と言ってくれました。嬉しい限りです。
そのうち公開するかもしれません。

まぁ、あまり興味ある人はいないとは思いますが。。。
posted by Kiruahさん at 14:38| Comment(0) | TrackBack(0) | 日記

2011年05月03日

設計書には業務理由を明記すべき

多くの設計書では、何をすべきかがシステム屋目線で記述されています。
例えば基本設計書、私のローカルな言葉では、「業務機能 機能処理フロー設計」、「業務機能 詳細設計」にあたりますが、これらは全て、なぜそれをしなければならないのか、顧客の業務の理由を明確に記述すべきだと考えます。

理由は主に下記4点です。
1. 顧客が機能の必要性を理解出来ないこともあります。
もしシステム開発に対して積極的な姿勢でない場合、レビューを実施しても疑問も感じずスルーしてしまいがちです。
その後、バグがあったとしても、お互いにレビューした/瑕疵だと強く主張することになります。
そういうリスクはなくなりませんが、多少は顧客にも機能の必要性を理解しやすくしたいと考えています。
2. テスト仕様書を作成する際に、業務上のあり得る/あり得ないも含めてシナリオを作成しやすくなります。
基本設計書フェーズでは結合テストやさらに上位のテストが実施されているはずです。
このタイミングではホワイトボックスやブラックボックスというよりはむしろ、より業務に近いシナリオベースでテストが記述されることも多いと思います。
よって、業務理由が記述されていれば、このシナリオの妥当性が分かりやすくなります。
3. 後任の担当者が理解しやすくなります
後から入ってきた担当者は業務も知らない、何も知らないケースが多く、それなのに担当に割り当てられます。
その際の教育負荷の軽減につながります。
4. 保守業務が多少楽になります。
あとから見たときに、なぜこのような実装になっているかがわかります。
よって、業務が変わっとしても実装の影響等が分かりやすくなります。

設計書への記述としては記述する範囲が狭くなりますが、2段組がベストです。
左に設計、右に関係する業務やなぜこうするのか、業務的な理由、システム的な理由、資料へのリンクや説明や議事録のパスなどが記述されているのが良いと考えます。
こうすると設計に時間がかかると思われます。しかし、その方があとの工程や引き継ぎが楽になります。
posted by Kiruahさん at 09:17| Comment(0) | TrackBack(0) | ノウハウ