暑いっすね。
投稿日:2007年06月13日 作成者:yasunaka
でも、九州のほうではそろそろ入梅しそうだとのこと。横浜もこの天気は今日まででしょうか?
投稿日:2007年06月13日 作成者:yasunaka
でも、九州のほうではそろそろ入梅しそうだとのこと。横浜もこの天気は今日まででしょうか?
投稿日:2007年06月13日 作成者:yasunaka
5月末にかけて、NTT東(西)日本のIP電話サービス「ひかり電話」関連の障害のニュースが続きました。5月23日に起きたのは東西間接続装置のハードディスク交換時に作業ミスで誤ったコマンドを送信したのがきっかけで東西間の通話が普通になったという件。一方5月30日には、ルーターのソフトウェアのバージョンアップに絡んで、着信できなくなる障害が発生した、という報道がありました。
この2つのトラブルは、もちろん直接的には別々の原因から起こっており、たまたまトラブルが続いた、ということだと思うのですが、システム屋の観点から気になったことを書いてみたいと思います。それは、こういったトラブルから何を学ぶか、ということです。
私が一番気になったのは検証環境での事前テストはやったのだろうか、という点です。システムにはバグがつき物です。新しいものを入れたときにトラブルが発生するというのは良くある話です。トラブルの原因は個別にいろいろあって、完璧にトラブルはなくすスペシャルな方法はないと思いますが、本番適用の前に、事前にトラブルを検知することは、ある程度できるはずです。つまり検証環境を用意して、そこで「事前にチェック」することで、本番でのトラブルを回避できたかもしれない、という点です。
検証環境は本番環境そのものではないので、必ずしもすべてのトラブルをあぶりだせるわけではありません。しかし、できるだけ本番環境に近い状況を擬似的に作り出したり、場合によっては本番環境以上に厳しい状況を人工的に作り出すことによって、どんなことが起こるのかを事前に確認することができます。
検証環境においてテストをシステマティックに回すというのも、高度なノウハウが要求される分野です。ただ単に検証環境で動かせばいいというものではありません。トラブルをあぶりだすには、総合的なチェックにとどまらず、やばそうな部分を予め抽出しておいて、その部分については重点的にチェック(ストレステストなど)するということも必要になります。
トラブルを繰り返さないためには何をすべきか。常に考えていきたいと思います。
投稿日:2007年06月12日 作成者:yasunaka
初夏ですね。というか、今日は真夏ですね。
投稿日:2007年06月12日 作成者:yasunaka
エンタープライズ・アーキテクチャ(Enterprise Architecture、以下EA)が叫ばれるようになって久しいですが、あなたのところでもEAしていますか? ユーザにとってメリットが大きいはずのEAですが、正直なところ、(ちょっと不謹慎ですが)システムを作る側からすると邪魔に思える存在だったりします。それはEAは技術の標準化を求めるものであり、技術革新とは相容れない要素があるからだと思います。今回の案件にはこの技術がぴったりのはずなのに、EAから外れるから使えない! なんて経験、ありませんか?
私が一般に言われるところのEAについて疑問に感じているのは、果たしてドックイヤーと呼ばれるシステムの世界において、技術革新を無視して社内標準を採用し続けることが正しい戦略なのか、という点です。もちろん何でもかんでも新しいものに飛びつけ、と言っているのではありません。しかし適切に技術評価を行ったものであれば、むしろ積極的に新しい優れた技術を採用したほうが長期的には正しい戦略ではないのか、と思うのです。
EAの中でも、例えばデータモデル、コード体系の統合やアプリケーション間のインターフェースの共通化などはぜひ進めるべき課題だと思うのですが、一方、運用管理コストの低減という観点で、対象のハードウェアやOS、ミドルウェアに縛りを付けてしまうというのはいかがなものかと思います。もちろんあまりにバラエティーに富みすぎては管理できなくなってしまいますが、単一のハードウェア、OS、ミドルウェアに統一した場合の、システム・ポートフォリオのライフサイクル全体にかかるコスト・効果と、2,3のハードウェア、OS、ミドルウェアに分散「投資」するコスト・効果を比較した場合、むしろ後者のほうが優れている場合が多いのではないかと私は思うのです。
今の運用管理者では管理できないから、という理由で実現できていないとすると、厳しい言い方をすれば、それはその運用管理者をただ甘やかしているだけにしか思えません。もちろん新しいOSやハードウェアに対応するには、教育コストも余計にかかることになりますが、それを加味してでも将来の技術標準に対するリスクヘッジという観点で十分にペイできるのではないか、と私は考えます。
投稿日:2007年06月11日 作成者:yasunaka
会社の隣がケーキ屋なんですが、その前で犬がお行儀良くご主人を待っていました。
投稿日:2007年06月11日 作成者:yasunaka
年金記録漏れの問題が世間を騒がせています。年金記録5000万件が過去のシステム切り替え時などでうまくリンクがとれずに宙に浮いたままになっている件です。この件でCSKホールディングスの有賀貞一さんがNIKKEI NETのIT+PLUSに寄稿している記事業務・システムの視点が欠落した「年金記録漏れ」問題の与野党議論を読み、大変面白いとおもいました。
「いかに政治家や官僚が社会インフラである情報システムと、それにまつわる業務処理に無知であるかが明解になった」
さすがシステムの専門家だけあって、業務的な観点、システム的な観点、コスト的な観点から、今回の決定が如何に「何も考えずに」行われているかを指摘しています。
読んでいて感じたのは、著者の有賀さんは「政治家や官僚」に特有なこととして指摘しているのですが、果たしてそうなんだろうか? という点です。実はシステムの開発に絡んで世間一般によるある話ではないだろうか?と思ったからです。
つまり業務的な観点やシステム的な制約事項などが考慮されずに先に予算や期限ありきで物事が決まってしまって、あとからシステム担当者がそれにあわせるために四苦八苦、というのは良く聞く話だからです。もちろん今回の決定は1年という短い期間に区切ることにより、不安感を払拭するという戦略的な意味があるのは間違いなく、戦略を重視してそれにあわせて現実を変えていくという考え方そのものは正しいと思います。これは一般の企業でも同じような話であり、先に予算が決まるのも、対象の業務に対する投資対効果をベースに枠を決めていると考えれば正しい行動だといえます。
ただし問題なのは、いくらそれが戦略だとしても裏付けのないまま事を運んだ場合のリスクを考えていないことにあるでしょう。一年以内の突合を公言したために、期限を守ることが絶対条件になってしまった、と考えると、この後、悲喜こもごもとしたことがいっぱい起きそうだな、と勝手に想像してしまいました。
投稿日:2007年06月08日 作成者:yasunaka
プロジェクトマネージャの重要な業務のひとつとして、プロジェクトメンバに対する評価があります。これは単にそのメンバへの支払いを決めるということではなく(そもそも普通のプロジェクトマネージャの場合、そこまで権限をもっていないことが多いですね)、プロジェクトメンバのやる気を高めるための1手段として評価を行うという側面が多いのではないでしょうか。
あるプロジェクトマネージャの人から聞いたのですが、その人はできるだけプロジェクトメンバーが日常で話した、何を目指しているのかとか、どんなことがしたいとか、そんなことををノートなどに記録するようにしているそうです。そして評価のフィードバックのときなどで、以前こんなことを言っていたけど、こうだったね、みたいに伝えてあげるようにしているそうです。
プロジェクトメンバからすると、ああ、この人は私のことをちゃんと見ていてくれているのだな、と感じることになります。この『見守っているよ』感がうまく伝えられればチーム運営上、大きなアドバンテージとなるに違いありません。プロジェクトマネージャからはプロジェクトメンバは1対多の関係なのですが、プロジェクトメンバからみれば1対1の関係だと考えてあげることが重要なのだと思いました。
投稿日:2007年06月07日 作成者:yasunaka
ある人から、こんな問題をもらいました。「今あなたは新しく人を採用しようとしています。候補として次の2タイプの人しかいない場合、どちらを採用しますか?」
1.協調性が良いが技術的には平凡なタイプ
2.協調性が低いが技術的に非常に優れたタイプ
これって実際良くある話かもしれません。協調性が良く、かつ技術的に非常に優れたタイプであれば即採用なわけですが、そんなスーパーマンはそんなにいるわけではありません。
私の予想では、通常は1のタイプを取る人が多いのではないでしょうか? 特にチームワークを重視するプロジェクト運営を目指しているならば、絶対1の人を取るのだと思います。一方、短期間にアウトプットを出すことを求められているプロジェクトの場合、2のタイプを取るのではないかと考えました。
ただいずれのタイプにせよ、長期間プロジェクトメンバとして一緒に仕事をするのであれば、その人の足りない部分が補われるように育てていくことが重要なのだと思います。そういった意味では技術力が平凡なメンバーは、優れた技術力の持ち主の人の下に付けて技術力を育てるべきだと思いますし、逆に協調性が低いメンバーであれば、優れたプロジェクト・リーダーの下に付けてリーダーシップを身に付けさせるというのもいいのかもしれません。
投稿日:2007年06月06日 作成者:yasunaka
働くことが好きな人ってどの程度いるのでしょうか? 私の場合はやりがいのある仕事の場合には、どんなに多く残業しても苦になりません。(やりがいの感じられる仕事の場合には、という条件付ですよ。) いろいろ周りの話を聞くと、この業界には同じような考えの人も多いのかな、と思います。
私の場合は今は労働者としては扱ってくれないので、働き過ぎでくたばったとしても誰も文句を言ってはくれないのですが、通常、会社のプロジェクトの場合、そのプロジェクトメンバがどんなに仕事好きで、がんばって残業したくても会社としての労務管理上、それが認められない場合があります。またコストを圧縮したいという経営からの要求のために、できるだけ残業をしないようにコントロールしているという話も聞くことがあります。現場でプロジェクト管理をしている人であれば、プロジェクトメンバがもっと仕事をしたいと思う気持ちと、さっさと帰さなければならないという立場の板ばさみに苦しんでいる人も多いのではないでしょうか?
働きすぎで健康的を害するというのは絶対回避すべきことなのですが、おそらくそれは単に時間が長いということが問題なのではなく、長時間強いプレッシャーを受けながら仕事をしていることが問題のような気がしています。逆に上記で書いたような、自分から好き好んで残業仕事をしているプロジェクトメンバというのは、おそらく少なくともその仕事に関しては、プレッシャーの強さよりも仕事を楽しむことのほうが勝っているから、進んでやっているように思えます。
そのようなケースで少し問題なのは、プロジェクト管理者側がなぜそのメンバが残る必要があるのかが把握しきれない場合があることです。メンバ側も、いまやっていることがなぜ必要なのかを、管理者側にきちんと理解してもらうよう、説明責任があるといえます。
いずれにせよ、楽しんで仕事ができるというのはまさに理想的な状況だと思います。もしそのような状況が実現できているのであれば、度を越さない範囲で好きなだけやってもいいよっ、というような選択権を与えることはできないものでしょうかね?
投稿日:2007年06月05日 作成者:yasunaka
もし顧客から、まだ内容が明確になっていない新しいシステムについての概算見積もりが欲しいといわれたら、あなたはどうしますか? リスクを回避するために、システムの設計フェーズと実装フェーズを分けて、最初はシステムの設計フェーズのみを確定金額で受注し、実装フェーズは別途見積もりを行う、というのが教科書的な答えになるのですが、問題なのは上記のような手続きになるにせよ、顧客側では最初の概算見積もりに基づいてシステムに必要な予算を立てるため、結局その最初の概算見積もりが上限になってしまうことが多い、ということです。私も今までなんども、これで痛い目にあってきました。
概算見積もりの難しさの主因は、情報の少なさにあります。見積もり精度の良い手法というのがいろいろと編み出されていますが、結局その手の手法は何を作るのかがかなり具体化していないと適用できないものがほとんどで、概算見積もりが必要な段階では用を成さない場合がほとんどです。何を作るのかが確定していないのに正確な見積もりなどできるわけがありません。以前、概算見積もりの段階でソースコードの行数をベースに費用を見積もったベンダーを見たことがあるのですが、その思い切りの良さにある意味すげーっ(褒めたわけではないですよ)と思いました。
知人のプロジェクトマネージャの話では、「いろいろ考えて積み上げて算出した数字を、最後に3倍する」と答えてくれました。この最後の3倍というのが味噌で、そうすると経験的に収支トントンになる場合が多い、ということです。最後の倍率は状況によってはいろいろ異なるのかもしれませんが、少なくとも概算時に積み上げた数字というのは、まだ内容が見えてない分、大きな穴が開いている場合が多いので、かなり余裕度を見ておかないと痛い目に合うよ、ということを物語っているのだと思います。