プロフィール

携帯版はコチラ

カレンダー

2025年8月
 12
3456789
10111213141516
17181920212223
24252627282930
31  

固定ページ

  • 欠陥住宅の恐怖。

    夢にまで見たマイホームが時間がたつにつれてひびが入り、カビが生え、挙句の果てに家そのものが傾いてきた・・・。
    このような状況を調査に入った一級建築士に、インタビューアが「これはひどい悪徳業者ですね」と尋ねると、一級建築士の答えは意外と違ったものでした。「いや、知らなかっただけなんですよ。」
    この一級建築士によると、この業者の建てた家には、お客さんの立場に立っていろいろ良心的に考えて一生懸命努力した形跡もあるそうです。使用されている材料やその家の販売価格からして赤字だった可能性もあるということでした。しかし、残念なことに「知識」だけが足りなかったのです。
    SEの仕事は、注文住宅を建てる建築士にたとえられます。たから、このような欠陥住宅の話も他人事ではありません。いくら「心優しい」、「思いやりのある」、「努力家」なSEであっても、ユーザからみると、悪意が無くてもスキルがなければ、迷惑以外のなにものでもありません。
    そのようなことを考えればソフトウェア開発は欠陥住宅のオンパレードではないかと感じられます。
    自分の「知識」がどのくらいのレベルにあるのかを正しく理解することの重要性がわかると思います。
    いずれか建築業界と同じように欠陥について非難される時がくると思います。自分のかかわったプロジェクトが欠陥であると言われないよう最低限の知識を学ぶことはSEとしの義務なのでしょう。

  • 開発の効率・知識の共有

    最近上のようなことを考えることが多いのですが、どちらもどうすれば「開発の効率・知識の共有」ができるかは明らかなのですが、それを実践できる環境をつくるのが難しく、うまくいきません。

    例えば知識の共有であれば、多くの人が集まって問題などを考えると本来答えは1つだと思っていたことに対してでも意外な意見があったり発見したりすることがあります。

    私の友人は土木関係の仕事をしていて、全く住む世界が違いますが、私たちのIT業界について素朴な疑問を投げかけてくれます。その中でも発見はかなり多いことを感じています。
    相手も同じように感じているようです。

    プロジェクトの開発の効率を考える時、誰かが嫌われるようなおもしろくない仕事をしなくてはいけなかったり、決まりを強制されたり、窮屈な思いをする為、うまくいかない方に進みます。

    知識の共有についても、労力をかけてまで自分の持っている知識を出すような気も起こりません。

    これらは必ずフィードバックとなる利益が伴わないとうまくいかないと感じます。前者ではプロジェクト成功のごほうびであったり、後者では知識のフィードバックやお礼であったり、その辺りをうまく輪にできるようになればみんなにとってハッピーな状態になるような気がします。

    ※内容の一部リーンソフトウェア開発でも書かれています。

  • ゼロ欠陥精神。

    モチベーションをくじかせる、最も簡単な方法の一つは、アメリカ軍で「ゼロ欠陥精神」と呼ばれているものです。ゼロ欠陥精神とは、絶対にミスを許さない雰囲気のことです。

    この一節を読んで今のプロジェクトの状況を思い浮かべました。今のプロジェクトは1つのミスも大事で皆異常なまでに警戒心をもって作業に取り組んでいます。
    この業界では唯一といえるほど、「作業は遅いがミスが少ない人」が評価される所です。
    しかし何事も成功に導く要素は、積極性や率先力が必要となります。
    今のプロジェクトに入って知らず知らずに「ゼロ欠陥精神」に汚染されている自分が恐ろしく感じます。

  • 勉強会。

    今のプロジェクトにて作業が少なくなって来た為、勉強会をしようと提案しました。さそく以前EJBの時に作成した資料を見直してみたのですが、短時間で作ったこともあり、出来がいまいちでした。最近こつこつとアップデート作業をしているのですが、これがなかなか良い復習となり、頭の中が整理されるので勉強方法としてはお勧めです。

    自分の作成した資料をみると理解度・説明能力がすぐにわかりますよ。

  • 結婚式のスピーチ。

    とうとう幼馴染の1人が結婚することとなりました。もう30になろうとするのに私の周りの幼馴染は誰も結婚しませんでした。
    とうとう第1号が・・・。とおめでたい所、またもやスピーチ。幼馴染はあまりにも出来事が多すぎて話す内容に困ってしまいます。

    スピーチはどうしてもワンパターンなのが多いのでなんか趣向をこらしたいのですが、未だおもいつきません。

  • 台風一過。

    台風が行ってしまい昨日、今日とわりと良い天気になりました。それにもかかわらず、この2日間はぐうたらに過ごしてしまいました。最近は涼しくなり、良く眠れるためどうしてもぐうたらになってしまいます。

  • 映画館。

    私の家にプロジェクタがやってきました。ビデオデッキ・スピーカーと接続し、たった6畳の部屋の壁一面のスクリーンで映画を見ました。
    今までの14インチのテレビで見るものと比べて全く違う迫力でした。
    まだきちんと設置できていませんが、近いうちにテレビもプロジェクタで見れるようにしたいです。

  • お客さんからの指摘。

    先日ミーティングにてお客さんとのやり取りの1部分です。

    カットオーバーが近づき、テストも完了したさなか、処理構造の大きな変更が持ち上がった。
    簡単に言えば、Webでは通常ウィザード形式で画面を進んで行って戻った場合は値の復元は行われるが、さらに進んだ時は値は復元されないことがセオリーとなっています。
    このことはクラサバのシステムと比べてシステム上の制限とも言える代表的な事例である。
    クラサバからのマイグレーションである為現行保証が必要となるが、この件について合意がなされていなかったことから、時期・利便性・品質・コストのおとしどころ探る為のミーティングだった。

    ■システム側の意見
    この時期での大きな変更はテストのコストが膨らみ、品質に問題が発生する可能性が高い為、機能的に譲歩できる部分は情報してほしい。

    ■お客様
    当システム制限は合意事項に無く、納得しがたい。ダウングレードする事に関して時間やコストを理由にするのはシステム側の都合すぎるのではないか。

    お客様一言ばっさりと、多くの時間を取って要件をつめるコストのかかる開発体制を取っているのは顧客満足(システム側の言い方だが)を高める為。それが出来なければシステム側の押し付け型の開発でコストを少なくした方が時間もコストも節約できて良い。

    契約時の1つの合意ミスが大きく跳ね返る一例です。
    ちなみに今回の件はお客様の配慮により最大限譲歩を検討してくれています。
    システム屋として心に留めておきたい一件です。

  • 航空業界のダウンサイジング。

    今日の新聞で航空業界のダウンサイジングについての記事が掲載されていました。
    今まで発着枠が少なく少しでもたくさんのお客さんを乗せる為に、需要の多い路線はB747のジャンボが主流であった。しかし最近の経営効率化の流れにより、需要予測のシステム化が発達し、小型機にシフトしつつある。
    簡単に言えば、高需要路線は他社の参入も多いし、便数も多いその為需要予測としてシステムがはじき出した答えは小型機だという。
    システムの発達という意味合いも大きいが、企業が「主観的判断」から「客観的判断」を重視する傾向にあるということでしょう。
    これから益々業界におけるシステムの重要性が増してくる中、IT業界の主観的なものの見方が相変わらずなのはもう少し危機感を持つべきことだと感じます。

    http://www.yodoq.com/technology/scrapbook/20040921.gif

  • 啄木鳥の戦法。

    武田信玄の配下、山本勘助が上杉謙信に対して川中島の戦いにて使用した兵法の1つである。
    啄木鳥(きつつき)が木の穴から虫を誘い出す時、木の裏っ側からつついて誘き出す様に例えた兵法である。
    その時は、兵法に精通していた上杉謙信に悟られ逆に虚をつかれたということです。
    その際にもう一冊アンチパターンという本を読んでいて、感じたのですが、どのような優れた兵法やパターンも使用する状況や、その時の要件により、逆の効果を生み出すことがあります。
    パターンの類を学ぶ場合には、適用するに当り、背景など裏に隠れた部分、アンチパターン(悪例)などを学ぶことが有効であると感じました。
    歴史の本はパターンの本のように読みにくくなく、楽しく読めてお勧めです。

« Previous Entries   Next Entries »

Recent Comments

  • 昨今、日韓の溝は深まるばかりですね。 ...
  • マズローの欲求5段階説における 尊厳欲求は...
  • 平松市長と橋本知事の応戦は知っている人は...
  • ファストリさんは 店頭で募金を受付、280百...
  • こんなにも前から警鐘を鳴らし続けていたに...