福岡で働くＩＴ屋の徒然ブログ

上記の広告は2週間以上更新のないブログに表示されています。 新しい記事を書くことで広告が消せます。  

ちょっとマニアック？なネタですいません。

そもそもデータセンターってのは、「データセンター（Data Center）とは、
インターネット用のサーバやデータ通信、固定・携帯・IP電話などの装置を
設置・運用することに特化した建物の総称。」（wikipediaより）のこと。

このブログもどこかにあるデータセンター内のサーバにて運用されてるはず。
最近流行の「クラウド」もデータセンター内のサーバで運用されます。そして
クラウドサービスの価格はデータセンターの運用費に左右されます。

有名なところでGoogleやAmazonなんかは広大な敷地に巨大なセンターを作るこ
とで運用コストを下げてますが、日本のデータセンターは都心にあることが多く、
その為土地代や人件費が高いため、サービス自体の価格がどうしても高くなって
しまいます。

そんな中、インターネットプロバイダの「さくらインターネット」が北海道石狩に
巨大データセンターを建設すると発表しました。
なぜ石狩かというと、
・土地が安い
・人件費も安い
・冷房費（電気代）が安く済む
の３点が、大きな理由みたいです。

特に３番目の冷房費について、コンピュータって結構熱を出し、且つ熱に弱いので
データセンター内というのは一年中温度を下げておく必要があり、その分の電気代
が馬鹿にならないのです。

今回、石狩という地の利を生かし、気温の低い外気を利用したり、冬の雪を冷房に
使ったりして、電気代を節約するそうです。
また運用管理を行う人もそれなりに必要ですから、雇用にも繋がります。
多分今後追従してくる企業が出てくるでしょう。それによって、日本企業によるクラウド
サービス価格の低下と北海道の雇用促進に繋がれば、一石二鳥。
今現在、海外のクラウドサービスを使う上で一番のネックは通信の遅さだと思うのですが、
国内であれば、それも解消されますし、その点でも利用者メリットもありますしね。

  

ビックリするを発見しました。
「人間がコンピューターウイルスに感染する悲劇が現実に」

あくまでも実験とのことですが、ICチップ（RFID）を人体に埋め込むという話しはだいぶ前から
ありましたし、例えば人工心臓をはじめとする人工臓器も制御のために、その様なチップを
使うこともあるでしょう。
万一それを狙ったウィルスが作られたら。。。ちょっと恐くなりました。

また人体に埋め込むものではありませんが、福岡でも各鉄道会社のICカードを始め、RFIDを
使ったカードを多くの人が利用してます。それを誤作動させるようなウィルスが出たら、
かなり混乱するでしょうね。

もちろん、そういったことが無い様、各事業者は事前にセキュリティ確認を入念に行っているでしょうが、
PCの実情を見るとイタチゴッコですから、100%安全とは言えないと思います。

かといって、気を付けようも無いわけで、これはもう祈るしかない！？
  

いよいよiphone4の発売日です。
ネットの情報だと、既に当日手に入れることができる予約者には連絡が
入っている様子。

残念ながら、自分には連絡きてませんが。。

ソフトバンクは予約受付数や初回入荷数を公表していませんが、ネット情報だけを見ると、
地方ではショップでの予約番号１番でも未入荷だったり、多いところでも20台前後と予約数に
比べて入荷数がかなり少ないようです。
また16GBと32GBとで、入荷数に差があるようで、１：６～７の割合みたい。

自分の予約番号と比べると、どうも7月中ですら怪しい感じ。16GBモデルだし。。。
この分だと予約再開もいつになるかわからないですね。。。

ま、気長に待つことにします。


  

家電エコポイントについて、先日ポイント発行通知が1ヶ月かかると書きましたが、
昨日、そのハガキが届きました。（発行から約2週間、これは早いのか遅いのか？）

まずは、ポイント確認のため、ハガキに書かれたIDとパスコードを使ってマイページにログインです。
ログイン後、メールが来て、今度は間違いなくメールアドレス登録しました。
（画面にも登録しましたとのメッセージ）
が、その後同一IDでマイページにログインしても、同じようにメールアドレスの登録→メールが来る
→認証の繰り返しで、ポイント数の確認すらできない。。。
ハガキでの通知はインターネットでポイントできないのか？

ただ、インターネットで通知が来た分については正常にログインできたので、そちらの方で
ポイント合算を試みる。
合算する３つのIDとパスコードを入力し、実行すると「受け付けられた。メールで通知する」のメッセージ。
が、いつまで待ってもメールは来ない。ポイント数を確認しても合算した分のポイントが表示されない。
尚且つ、合算した3つのIDではマイページにログインすらできなくなってる。。。

おーーぃ、ポイントどうなってしまったんだ！？

どうしょうも無いので、また営業時間（９時～１７時）に電話してみます（泣）

それにしても、本当に酷いシステムだ。。。
色んな記事や雑誌に、クラウドを使って短納期・低コストでできた成功事例みたいに書かれているが、
正直ここまで不親切、判りにくいシステムは初めて。
いくら低コストといっても、ウン億円は税金から出しているはず。
信じられん。。。
でも、これが今の省庁発注者の力量なんでしょうね。
  

前回の続きで、プロジェクト内における進捗管理の頻度と方法について。
※ここでプロジェクトとはITシステム構築プロジェクトを差します。

まず、プロジェクトにおける進捗確認・会議の頻度ってどの位でしょう？

プロジェクトの規模や工期によって差はあるでしょうが、一般的なのが週に１回程度では
ないでしょうか？（それが遅れが発生しだすと間隔が短くなり、トラブルが発生すると
酷いときは数時間毎になったりしますが）

また、進捗の確認方法としては各作業・機能毎に「○％の進捗」という報告を元にガント
チャートに稲妻線を引いて、遅れが見えるものに対して「対策を報告させる」という方法
が多いのではないでしょうか？

私の見聞きした中での話ですが、この方法で何の問題も無く成功したプロジェクトはあり
ません。もしあったら教えて欲しいくらいです。

では、どうするか？

私が一番参考にしているのが、ゴールドラット博士の著書、
「クリティカルチェーン―なぜ、プロジェクトは予定どおりに進まないのか?」です。
本の中には、工程作成の考え方から書かれていますが、今回は割愛して進捗管理の
部分のみ書きます。

前回書いた、作業分割及び担当の割り当てができている前提ですが、進捗管理の方法として
やるべきは、以下の２点のみです。
（１）後何日で終わるのか？
（２）それで終わらない可能性として、どんな問題が想定されるのか？

（１）について、例えば「進捗９０％」の状態が、それに達するまでよりも長く続いてい
るなんてことありませんか？（そもそも何を基準に％を出しているのかさえ不明だったり）
始まりからではなく、終わりを基準に進捗を管理しようというのが（１）の意味です。

また終わりを基準に考えると、それまでに後何をしなければならないのかを意識します。
そこでもう一歩深く考えさせるのが（２）の確認になります。
「予定通り終わるには、残り○○という作業をしなければならない」
　→「その為には△△と□□の準備をしておかなければならない」
　　→「もし△△が予定通り準備できなかったら、○○という作業に着手できない」
となると、「△△が予定通りに準備可能かどうか、事前に確認しなければいけない」という
アクションアイテムが明確になり、事前にリスクを回避でき、遅れが防げるという訳です。
最初のうちは、作業を落とし込むことが難しいかもしれませんが、やってみる価値は
絶対にあります！

まずは、小さなプロジェクトからでも試してみる価値はあります！

　
  

少し間が空きましたが、QCDの最後、D（納期）について。
IT業界においては、納期遅れの話はよく聞きますし、仮に最終納期に間に合ったとしても、
その直前まで遅れていて、突貫工事でなんとか間に合わせたなんてことも多いのではないで
しょうか？

それを少しでも減らすためにはどうしたらいいか？について、纏めたいと思います。
とりあえず、今回はごくごく当たり前の事を。

まず、納期遅れ（進捗遅れ）は何故発生するのか？
その原因としては外的／内的要因に関わらず
（１）想定外の事態が発生した。
（２）想定以上に作業時間を要した。
の２つが殆どではないでしょう。
となると、対策としては『事前に想定をする』しかありません。

例えば、あるプログラマに「この機能を○日で」と指示があったとしましょう。その時、
どのようなスケジュール（工程）を引きますか？（まさか、スケジュールを引かずにいき
なり作業を始める方はいないでしょう）
もしくは、既に作成されたスケジュール（工程）表を渡す場合、その工程表はどの粒度で
しょうか？

多くの場合、このスケジュール（工程）は「管理の視点」から書かれたものが殆どです。
なので、具体的な作業項目までは書かれていません。それなのにいきなり作業を始めてし
まうから、『想定外』のことが起きてしまうのです。

まずやるべきは、作業を細かく分解すること。プロジェクトレベルでWBS(Work Breakdown
Structure)に分解することは行われますが、各担当者の作業レベルではどうでしょう？
ある程度の経験者であれば、多分頭の中でやっているでしょうが、やはり書かないと抜け
が発生し、それが致命傷となる場合もあります。

ましてや、経験の浅い者にとっては、何をどうしていいのか分からないことでしょう。
ですので、最初のうちはきちんと付いて一緒に考えてやる。慣れてきて、ある程度できる
ようになっても、事前に内容のレビューは確実に行ってやることが大切です。
『作業分解して、各作業毎に工数／時間を見積もる。』
『経験者を含めて事前にレビューする』
ごく当たり前のことですが、きちんとできてますか？


【段取り八分】を改めて考えて見ましょう！


さて、どんなに事前準備を完璧に行っても、やはり日々問題は発生します。
それを未然に防ぐには、日々の進捗管理が大切になってきます。
その方法については、また後日。
  

既に多くの方々が書かれてますが、予想通りiphone4発表されましたね～。


今のsoftbank携帯が9月で2年を迎えるのですが、その前に機種変してしまおうかなと
マジで考えております。
あと、問題は価格。15日から予約開始らしいので、近々に発表されるでしょうが。。。
ただ機種変だと新規よりも高いしなぁ。。。
ずっとsoftbank使っているんだから、せめて新規と同額にして欲しいと思うのは
おかしいでしょうか？
Twitterで孫さんにつぶやいてみるかな

ipadも欲しいし、合計すると幾らになるんだろ？？？  

先日会社帰りに天神のベスト電器本店に寄ってきました。
お目当てはiPad。ベストも取扱店との情報をappleのホームページで見て、
実物あったら触ってみたいなと。

apple製品がある１Fではなく、６Fに実機を展示してありました。
第一印象は「楽しい！」。キーボード・マウスに慣れた自分にとっては
最初は操作方法に違和感ありましたが、すぐに慣れました。
自分で使うだけでなく、小学生の子供に使わせたいです。学校でPC操作の
授業はあるらしいのですが、こちらの方が断然親しみやすいと思います。

で、店員さんに入荷時期を聞いたところ、次回6/7の予定だが台数は未定。
その次は6月末ではないか？とのこと。
店員さんも本当に直前にならないとわからないそうで、その点でもappleの
秘密主義が徹底されているようでした。
なんでも、発売日前日（5/27）も何時に何台入ってくるのか事前に連絡なく、
実際入ってきたのは、閉店20分前だったそうです。

なお、ベストではWiFiモデル一括購入であれば商品券が使え、さらに10%
ポイントが付くそうです。

エコポイント交換ではベストの商品券は20%多くもらえるので、まだ交換
していない方は狙い目かもしれませんね。

  

この業界（IT）に限らず、年俸制の企業って結構ありますよね？
（全社一律でなく、本人希望や一定の役職以上も含む）

ただ、その支払い方法は各企業毎に異なります。
単純に年俸を１２分割して毎月支払いだったり、１５分割して毎月＋夏冬賞与１．５とか。
後者の場合、業績不振を理由に賞与分をカットってありなのでしょうか？

先日お話をしたソフトハウスの方が、昨年まさにこのパターンで、「これで年俸制と
言えると思う？」と聞かれて、答えに詰まってしまいました。

その会社の仕事形態が技術者派遣で、派遣先からは時間外分の追加費用はきちんと
支払われているが、年俸制であるため時間外手当は無しとのこと。
これが自社内開発で、自分たちの責任におけるコストオーバーで赤字になったのなら
まだ納得できるが。。。とのこと。


話を聞いた限り、それが法的にどうこうではなく、個人的にはそれまでの過程（会社の
説明）が酷いなと思った次第です。

その会社、前回少し触れましたが、会社の状況について殆どと言ってよいほど、説明が
なく、賞与至急の直前になって、カットを通知されたそうです。（全社一律に）

それまでは、たまに「業績が悪い」「赤字だ」と曖昧な話はあったそうですが、具体的に
どの程度悪いかとか、そのままだと具体的にどうなるのかなどについては聞いても経営者
から明確な答えはなく、その時になって、いきなり賞与カット。

これでは会社に不信感を持ってしまいますよね。
多分、経営者は余計な心配・不安を持たせないためにと思って、話をしなかったのでしょうが。。

良い時だけでなく、悪い時も隠さずにきちんと社員に話す。
業績が悪くなると「個々が考えて行動しろ」「会社の状況を考えて」「一丸となって」等々を
社員に言われる経営者がいますが、現状が正確にわからなければ、全員のベクトルを合わせる
など、どだい無理な話です。

前回書いたコスト意識を持たせる云々以前に、経営者と社員との信頼関係を保持
するためにも必要ではないでしょうか。

  

QCDのQ「品質」の次はC「コスト」について。

これは品質と違い、実際に関わることが無い社員に対して意識を高めることは
なかなか難しい問題です。また技術者派遣を主としているソフトハウス経営者の
中には、効率は関係なく、残業をしてもらった方が多く金が入るので、あえてそ
ういったことには触れない方もいらっしゃるかも？

でも、結局は回りまわって自社に影響があるわけですから、技術者にはきちんと
コスト意識を持ってもらわなくてはなりません。
※効率が悪い技術者→次は使わない。
　ユーザの導入コストが増える→ITは高い→仕事が減る。　などなど。

ではどうすればいいか？

最初に行うべきは、自社のお金の状況を隠さずに社員に伝えることです。
各人の原価が幾らなのか、それに対して売上が幾らなのか、部門・全社の収支状況が
どうなのかなど。今はどこの会社でも月次で管理されていることでしょう。それを
きちんと月次の数字を社員に伝える（数字だけでなく、その仕組み・計算方法も含めて）
べきです。さらには、賞与の計算方法や昇給基準も。

自身の原価がわかれば、時間単価は自動的にわかります。そうすると、自分の仕事内容
がその単価に見合ったものであるか？と考えるようになります。今よりも高い給料をも
らおうと思ったら、現状の単価以上の価値を顧客に認めてもらわなければならないこと
が分かれば、コスト意識は必ず高まります。（現状の給料で十分満足という人は除いて）


以前（２年強）勤めていたソフトハウスで、自分の部下に対して全社・自部門の収支状況を
説明しようとしたら、社長から「待った」がかかりました。
その理由は、「社員の原価について、なぜその金額なのか自分が説明できないから」でした。
（ちなみにその社長は、東大法学部卒の元通産官僚という所謂エリート様です。そんな人が
何故説明できないのか、未だに不明ですが。。。）

結局は、私の独断で、自部門の状況のみを毎月説明するようにしたら、部下達も初めて
聞く事ばかりで最初は戸惑いもあったようですが、皆お金のことを意識してくれるように
なりました。飲み会でもどうやったら自部門の業績が上がるかが話題になったり。

「技術者はお金のことは考えなくていい」ではなく、まずは自社を題材にきちんと開示して
その内容について話をしましょう。その会社のことを一番理解し、正確に伝えることが
できるのは経営者です。そうすることで、コストだけでなく、その他の事についても社員の
意識は高まると思います。


  続きを読む

前回の続き

品質管理に関することでもう１つ。

「テストファースト」という言葉を聞いたことがある方もいらっしゃると思います。
この言葉も色々な解釈がありますが、個人的な考えを。

共通するところは、プログラムを作る前にテスト仕様やテストプログラムを
書きましょうという点。そのメリットとしては
・先にテスト仕様を書くことで、その後作成するプログラムの仕様理解が深まる。
・同様に仕様の漏れ・抜けが防げる。
・その結果として、プログラミング及びテスト工数が削減できる
といった点があげられるでしょうか。

その為、特にスピードが要求されるアジャイル開発においては、さかんに
テストファーストが推奨されています。ただそれも先に書かれるテスト仕様の品質が
高ければという前提条件が付きます。（ここを書かれていないものが多い）

つまり、テストファーストが効果をあげるためには前回・前々回書いた基本が
身に付いていることが前提条件ということです。

アジャイルを標榜するソフトハウスも増えてきています。特に中小ソフトハウスが
下請け・派遣から抜け出し、ユーザ直接の仕事を取り・こなすためには、アジャイルと
いうやり方は効果があると思いますし、大手SIとの差別化ポイントの１つになると
思います。

しかし、中にはドキュメントを一切書かず、要件を聞いたら即プログラム製造・リリースを
し、バグは顧客から出してもらい、それを修正することで品質を高めるのがアジャイルだと
勘違い？しているところも見受けられます。その結果、ユーザは想定外の負荷を強いられ、
ITは高い・手間がかかると認識を持たれてしまう。

お客様の信頼無くして、商売は成り立ちませんし、望まれる品質を満たすことでしか、
その信頼は得られません。その為、特に品質に関しては最初から基本を教え込む
ことが大切ではないでしょうか？
そして、その上で、テストファーストの様な導入し、効率を上げていく。手間はかかり
ますが、自社のため、お客様のためにも必要なことだと考えます。



  

前回の続き。

いざテスト仕様書を書くとして、ポイントは２つあると思います。

まずはテストの視点。例えば数値入力箇所があった場合、そのテスト項目として
考えられる点としては、
・数値を入力した場合、異常をきたさないこと。（DBに登録したらエラーにならない等）
・数値以外入力できないこと
・最大値／最小値
・小数点は入力した場合の処理
などなど。こういった視点は書籍などでよく書かれてますが、いざやろうと思っても
抜けることが多々あります。そういった点をきちんとチェックしてあげることが重要。

もう一つはテスト仕様漏れを起こさないこと。
テスト仕様書って何を基に書きますか？
若い人によく見られるのが、作ったプログラムを基にテスト仕様書を書くケース。
これでは全くテストになりません。
テスト仕様書の基となるのは、当たり前ですが、設計書です。
テストというものは、作成したプログラムが設計書通りに動くことを確認するために
行うものです。この点も頭ではわかっていても、なかなかできません。
なので、これも実際にやらせて、それをチェックし間違いがあればきちんと指摘し、
何度もやらせることが必要です。

ソフトウェアのV字モデルを聞いたことある方は多いと思いますが、このようなことを
して初めてこれが理解できます。



特に大手SIではISO9000に準拠した品質管理を行っているところが多く、そのベース
としてV字モデルがありますから、そういったところを相手にしているソフトハウスでは、
その理解が役立つことと思います。


  

まずは品質管理について。

会社の規模によらず、品質の重要性についてはどこのIT企業においても認識は同じはずです。
では品質を確保するために、具体的に何をどのように教えていますか？

座学はある程度必要ですが、やはり確実なのはOJT。できればリーダ・マネージャが
きちんと付いてやるのが一番です。

まずは、品質とは何ぞや？から、体系的にしっかりと学習させる必要があります。
そして自分の作ったプログラムをテストさせる。（本来ならテストは作成者以外が
行うことが理想ですが、あくまで教育という目的ではの話）

とかく、経験の浅い技術者は、想定される正しい動きについてしかテストしません。
それでは、機能要件の一部が満たされているかを確認しているだけ。
機能要件には異常系の処理も含まれますし（エラー処理、メッセージなど）、非機能要件に
ついては全く手付かずのままとなってしまいます。
まずは、「機能」「非機能」の定義、具体的にどんなことを意味するのかを学びます。

その上で、具体的にそれらをテストする方法を教えます。
この時のやり方としては、テストを行っている横に付いて、説明する／やってみせるのも
一つの手段ですが、それだとその時は判ったつもりでも、なかなか後に残りません。
それよりもきちんとしたテスト仕様書を書かせることの方が理解が早いと思います。

これまで色々なテスト仕様書を見ましたが、手抜きと言うと失礼かもしれませんが、
確認する手順と結果がきちんと書かれていないものが多い。
「どの様なデータを使い」「どの様に操作したら」「どういう結果になればOKなのか」が
正確に書かれていないのです。

それではテストをするだけ無駄としか思えません。案の定、テストOKとなった機能を
再確認すると、なぜこれがOK?と言いたくなるような不具合がボロボロ出てきます。

そうやって正しいテスト仕様書を書かせることで、きちんとしたテストができる。
それができるようになると、プログラミングの段階での品質意識も高まります。

この教育における一つの問題は、その様に教えることができる要員を如何に確保
するかですが、これは経営者・管理職が責任を持って行う、もしくはできる人を
外部から連れてくる。
忙しい、費用が無いのはわかりますが、そこはきちんと手を掛けてあげましょう。



  

前回の続き。


では今後中小ソフトハウスはどうすればよいか？

プログラミング力では、間違いなく大手SIよりも中小ソフトハウスの方が上です。
実際大手SIが請け負った仕事の殆どといってよい部分が外部（ソフトハウス）要員が
作ったものですから。私も以前は発注する側にいて、実際に見てきましたが、彼・彼女らの
力は素晴らしいものがあると思います。

ただ、残念なことに、品質・納期・コストに対する意識は、発注する側の要望に対して
低いと言わざるを得ないことも確かです。またリーダクラスのマネジメント力も同様。

この原因は明らかで、大手SIでは入社した時からそういったことを体系的に社内教育、
あるいは規約・規程を通して徹底的に教え込みます。もちろん、それには大変なコストが
かかりますので、それを回収するために大手SIの単価は高くなります。
（注：それだけが理由ではないですが。。。）

では、ソフトハウスでも、発注元である大手SIの要求に応えるべく、同様の社内教育を
行ったとしたら。。。残念ながらその分をコストを発注元に請求することはできません。
（本来であればソフトハウスの品質意識が高まれば、その分大手SIにもメリットはあるので、
多少は面倒を見ても良いと思うのですが。。。）
その為、ソフトハウスでは必要性は感じながら（？）もその様な教育は疎かになってしまいます。

でもそれで本当にいいのでしょうか？
社員教育に力を入れず、同様の過ち（品質未達・納期オーバー等）を繰り返すソフトハウスは
遅かれ早かれ切られるのは目に見えてます。


ソフトハウスの20代～30代の若手技術者と話をすると、その点で彼らは非常に危機感を
もっています。QCDだけでなく、例えば上流SEになりたいが、「何をどう勉強すればいいのか？」、
「そもそも今のままでそのチャンスはあるのか？」といった自身の将来についても。

経営者の方も、そういった気持ちには当然気づいていることと思います。
ではどうするか？

まずは、経営者・管理職クラスの人間が覚悟を決めることです。
自社社員の教育を派遣先に任せるのは止めましょう。
そうしたところで、そのプロジェクト期間中に必要なことだけを、しかも小手先の手法を学ぶだけです。
社員の成長が自社・自部門の成長に繫がるのだと割り切り（？）、そのためにコストはかかることを
認識し、必要なことにはお金を出す覚悟を持つことが必要だと思います。

なんか、話が逸れてしまいましたが、次回具体的にどう教育すれば良いかの私案を書きたいと思います。

　　　
  

本日は朝から某お客様の所へご挨拶。
その起業について、お客様の考えについてかなり時間をオーバーして
お話下さいました。

話の中で言われた言葉。
「ユーザがITのことを勉強するか、SEが業務を勉強するか？
　どっちが早いと思うか？」

もちろん答えは「SEが業務を勉強する」だと思います。
（但し、ユーザ様もITについて全くの不勉強では困りますが。。。）

IT業界はご存知の通り、進歩が非常に早いです。それについていくことをユーザに
期待するのは無理な話。であれば、SEが業務を勉強し、その上で提案・システム
作りをする方が、よりユーザにとって役立つものができるはずです。

ただ、ここで注意したいのが、業務を勉強するということが、単にユーザの話を
聞いて、その通りに作るという意味ではないということ。そうすると、ユーザは
その時点で自分や部門が身近に困っていることを言われる傾向にあり、その情報
だけを基にシステムを作ると部分最適なものにしかなりません。

そうではなく、SE自身が現場業務を見て、経験して、ユーザでは気づかない視点
で物事を考え、その上で全体最適なシステム提案・作りをするということです。

実例として誰もが知っているメーカの名前もお聞きしました。
ただ、メーカの立場で考えると、それは判っていても社内の様々な制約でできない
こともあり、担当者にとっては非常にジレンマを感じることがあります。
（コスト管理、品質管理、リスク管理等、社内規程で雁字搦めです）

対して、その様な制約の少ない中小ソフトハウスにとっては、この点で大手と
差別化できる可能性があるということです。
もちろん、コスト、品質、リスク等を疎かにしてよいということではなく、
ユーザに迷惑を掛けないように必要な管理は行いつつも、より現場に決定権がある
中小であれば、もっと素早く対応できるのではないか？ということです。

その為に中小ソフトハウスが今やらなければならないと思うことを次回に。

　　　
  

Googleホリデーロゴのパックマン、好評につき延長されたようです。

ここ

いつまでかは不明なため、お早めに！

但し、仕事中はダメですよ！？
  

お気付きの方も多数おられたでしょうが、googleのトップページがパックマンに
なっていて、実際に遊べました。

グーグルのロゴがほんとに遊べる『パックマン』に！30周年祝い2日間限定

こういった遊び心、いいですね。
有名な話では３M（スリーエム）では勤務時間の２０％（だったかな）は
業務以外に使うことというルールがあるらしいです。

アイデアって、そればかりを考えていてもなかなか浮かびませんが、注意を他に
向けていると、ふと思いついたりというのは誰でも経験があると思います。

将来、そんな組織を作りたいなぁと、ちょっと思います。

＃ちなみに自身の最高点は5670点でした。。。


  

昨日の西日本新聞の記事で見たのですが、
名古屋文理大学でipda無償配布
とのこと。ただ来年度（平成23年度）新入生が対象らしいですが。

先日の「光の道」で紹介した孫さんの講演にもありましたが、
ＩＴで世界をリードするためにはインフラだけでなくプラットフォームも重要。
残念ながらプラットフォームでは日本は世界に遅れを取っているのは事実です。
（クラウド、iphoneなど）
また、ＩＴ系で学ぶ大学生の数も圧倒的に少ないことも、かなり前から言われてます。

そんな中でＩＴで日本が生き延びるためには若い世代が我々とは違う感性を
持つことは重要だと思います。

それを考えると、iPadの様な優れたプラットフォームにできるだけ早く接する機会を
与える今回のことは非常に嬉しく思います。

是非、iPadの様なプラットフォームを使いこなし、それに負けない技術、感性を
これからの学生は身につけてほしいものです。

  続きを読む

本日は終日自宅でまったりと

今更ながら、BBA（ブロードバンド評議会）シンポジウムでの孫さんの講演
及び孫さん・三木谷さんの対談の模様をustreamでみてました。

三木谷浩史・孫正義が語る
「国民の、ITによる、日本復活」
（合計で約1時間30分程度。興味があれば時間のある時にどうぞ）

いや～、孫さん熱い！
所々に、龍馬ネタや笑いを入れ込みながらも、その思いが伝わってきました。
本当に龍馬（笑）、それと日本という国が好きで、民間人としてIT分野で
この国を変えたいと思っているんだなぁ。

今の自分に日本を変える力は無いですが、その心を持って、少しでも
日本、九州、福岡のために何かできないかと、考える次第です。

孫さんの講演って初めて見た（ご本人も一般の方を対象にしたのは
10年ぶりと言われてました）のですが、これからももっともっと、
そういう機会を持っていただきたいものです。  続きを読む

ある資料を見ていたら『SQCD』なる言葉が。。。
Q(Quality：品質)、C(Cost：コスト)、D(Delivery：納期)はソフトウェアに
限らず、製品開発の世界でも昔から使われている言葉ですが、じゃ「S」って？

ということで、調べてみたのですが、以下の3つが使われることが多いようです。
(1)スコープ(Scope)
(2)安全(Safety)
(3)サービス(Service)

(1)はPMBOKでも出てきますが、何をどこまでやるかの定義の意味。確かにここが
明確になってなかったらQCDも曖昧になってしまいます。
(2)は例えば航空、鉄道など輸送事業の場合に使われることが多いようです。
何よりも安全第一です！みたいな。
(3)は「顧客満足」を満たす条件として使われることがあるようです。有名な
リッツカールトンホテルのサービスなどが該当するのかな？（泊まったことは
ないですが（汗））

でどれが一番しっくりくるかは人それぞれだと思いますが、個人的にはやっぱり
(1)かな。（仕事上でも）

ここを明確にしないと、どんなに良いもの（少なくとも売る側としては）を
納めても、使う側からしたら、想定外ってことになる訳で。。。
で、そうなると安全も顧客満足もあったもんじゃないってことになりますしね。

＃他に「S」の定義があったら教えてくださーい！