「 2005年12月 」一覧

2日間の休日だと

一ヶ月ぶりくらいに土日がきちんと休みだったんだけど、なんかこの二日間がすごい長く感じてしまった。

一日違うとけっこう違うもんだなぁ。

風邪のせいで外出はできなくて、ほとんど本読んでいるかPCに向かっているかだったんだけど、ブログのデザイン変更とかたまってた未読の雑誌を一気に読んだり。

あと、はてなの技術発表会の動画をまとめてみたり。はてなは毎日こういうのをやってるのかぁ…。そんなに肩肘張らない感じで面白そう。うちみたいな会社だと肩肘張ってやることになりそうだなきっと。まぁそれ以前にそういう話しに興味ある人が少なそうだけど。

とまぁこんな感じで今週はけっこういろいろできたかも。

こういう感じで休日を過ごせたらいいな。いつもは無気力に過ぎていくだけだし。


エントリ投稿画面のフォントサイズを大きくする

ちょっとしたことだけど、MTのエントリ投稿画面で、入力フォームのフォントサイズが小さいように感じる。

さすがに長いエントリを書くと、全体が見づらくなるんでそれを大きくするには、

mt-static/styles.cssに

#body-box textarea.full-width {

font-size: 100%;

}

を追加すればOK。

デフォルトは95%のフォントサイズになっているっぽい。


SEの「設計スキル」は低下しているのか

http://itpro.nikkeibp.co.jp/article/OPINION/20051205/225703/

すごく変なところに反応するけど…。

「SEの設計スキルが低下したのは“空白の10年間”のせいですよ」—。先日,大手ITベンダーの幹部に取材したところ,こう切り出された。

 その幹部によれば,この10年間,大規模な基幹系システムの開発がめっきり減り,その代わりに保守開発や中小規模のWebシステム開発が増えた。そのために,「特に若手のSEが設計にかかわる機会が減少し,設計スキルの低下が目立つようになった」(同氏)と言うのだ。

大手ベンダーらしい考えですな。

保守開発とか小さい案件だって取らないとやっていけない会社やエンジニアはいるわけで。「大きい案件バンザイ」みたいなのはねぇ。まぁ昔も今もそういう案件に関わっている人間は業界の中でもまだ花形のように見られているフシがあるってことかな。前も「億以下の案件はゴミみたいなものだ」なんて「大手ベンダ」の人が書いてあるのを見かけてちょっとムカッと来たことあるけどさ。

…まぁ地方のしがないエンジニアのひがみは置いといて。

記事自体の言いたいことはわかる。本当にきちんと基本設計をしないと駄目な案件が少なくなっているから、ベテランのSEから若手へのスキルトランスファとか若手SEの経験を積む機会が減っていることが一因ってことだよね。

たしかに一昔前に大規模システムを経験したベテランSEの持っているノウハウがそのまま応用できない部分が増えて、じくじたる思いをしている人もいるんだろうけど。

でも、それってここ最近の案件の質が変化してきたってことじゃないかな。保守開発や中小規模のWeb案件の中できちんと要件定義から設計、製造、テスト、カットオーバー後の保守までのノウハウを新しく蓄積しないといけない時期なんだと思う。今からまったくの新規で大規模なシステムの構築があまり見込めないのなら、そういう時代に対応した生き抜き方ってあるよね…。

もっとも,基本設計そのものが難しくなっているという面もある。例えば,あいまいな要件定義書が増えており,その結果,基本設計の入力情報が不明確になってしまう。

 さらに言えば,多様化・高度化した技術や製品を活用して高品質なアーキテクチャを組み上げるのにも高度な専門スキルが必要となる。そこでは高い性能や信頼性,セキュリティといった非機能要件も考慮しなければならない。

そう、空白の10年の間に求められるものが大きく変わっているんですよ。昔は「大規模基幹系を経験したエンジニア」というくくりで他の基幹系システムにも応用が利いてよかったかもしれないけど、今は「セキュリティ」「ネットワーク」「データベース」「Web系」なんて具合に専門化したエンジニアが集まらないととても基本設計なんてできなくなっていると思う。

ホストとダム端末(古すぎ?)と、Web上のイントラネット、外部向けWebシステムじゃ求められるものがけっこう違うんじゃ?もちろん普遍的なのもあるだろうけど。だから、

 「SEの設計スキルが低下したのは“空白の10年間”のせいですよ」—。先日,大手ITベンダーの幹部に取材したところ,こう切り出された。

と言われても、昔と今とを同列には比べられないでしょう。「昔は○○だったから良かった。今は…」みたいな論調って意外と昔の考えにこだわってしまっている人が言ってしまいがちではないかな。

今は今のシステム構築のニーズに合わせてノウハウを蓄積して、それに対応したエンジニアを育てられるようにする。もちろん昔のノウハウが使えればそれも取り入れるし、ベテランも昔に拘らずに今に応用が利くものはどんどんと若手に伝えるようにしてみればいいのでは。若手は技術だけじゃなくてそういうベテランの経験も「古くさい」と思わずに良いものは真摯に聞いて試してみる。それに尽きるんじゃないだろうか。



女性向けのたばこ

雑誌の広告を見て思い出したけど、最近女性向けと思われるタバコがあるみたい。

パッケージがピンク色でピーチの香りがするんだとか…。

自分がタバコ吸わないし、他人が吸っているタバコの匂いも苦手だから言うわけじゃないけど、女性でタバコ吸う人は基本的に敬遠したいんですよ。たとえ美人だろうがなんだろうが。せめて女性だけにはタバコ吸って欲しくないなぁ…とイメージ的になんとなく思うわけです。仮に自分の彼女とかなら絶対に許さないし。

でも、JTは禁断の領域に踏み込んだ感じがするなぁ。まぁ過去にもあったのかも知れないけど、女性までターゲットにしてタバコ売らないといけないんだろうかねぇ…。

それはそうと、JTのWebサイト、タバコ情報のページに入るにはIDとパスワードが必要でかつ、電話か書面で成人かどうかの確認をしないとダメだというのを今見てみて初めて知った。未成年が見ないようにってことらしいけど、じゃあ街中にあるタバコの広告はどうなんだろう…とか思ってみたり。


香港国際警察

レンタルで借りてみた。

ジャッキーの映画はあまり見たこともないし、香港映画自体もあまりみないんだけどこれは見応えがあった。

冒頭の部下が惨殺されるシーンはちょっと刺激が強いようにも思うけど、それを除けばジャッキーはじめ若手俳優の脇役もきちんとストーリーに絡んでたし、全体的によくまとまってると思う。

この映画ではジャッキーはすでに50歳を超えている。けどそれを感じさせないアクションなのもすごいの一言に尽きる。

香港国際警察 NEW POLICE STORY コレクターズ・エディション (初回限定生産)
B0007N0YGU ジャッキー・チェン ベニー・チャン ニコラス・ツェー

ユニバーサル・ピクチャーズ・ジャパン 2005-08-26
売り上げランキング : 939

おすすめ平均 star
starジャッキー感動作品
starジャッキーの新たな挑戦
starスーパーコップ、健在!!

Amazonで詳しく見る by G-Tools


MTのスタイルシートでハマる

すっかり忘れていたことをひとつ。

MovabletypeのテンプレートとCSSの内容ってぜんぶDBのテーブルに入ってるんだよね…。

styles-site.cssファイルを直接更新しても、次にエントリを再構築したときにファイルが前のに書き換わってしまう。

さっきまで何回か置き換わってしまって「なんで?」と悩んでしまった。


デザイン変更

気が向いたのでここのデザインを変更してみた。

まぁセンスの無さは置いといて、寒々しかった青系から緑をベースにした色に変えてみました。

あとはサイズや余白をちょっと調整。

基本的にFirefox上で調整しているんでIEだとまたちょっと見え方が違うかもねぇ…。

CSSの解釈とかフォントサイズとかけっこう違うみたいだし。


自宅待機

仕事は今日、自宅待機となっております。

昨日リリースしたものに緊急のトラブルがない限りは。

まぁ、おとといくらいから風邪をひどくしていたんで、ちょうど自宅で休養できていいんだけどね。

また今回の風邪も喉から始まって咳き込む…最悪は熱が出るかな?というパターンだけど、今のところ咳き込んでいたのも小康状態で落ち着いてるからこのまま治って欲しい。仕事もそうだけど、せっかくの年末年始に風邪じゃね。

ああ、でもせっかく天気のいい土曜日なのに家かぁ。


プロジェクトを管理しないという発想

http://www.atmarkit.co.jp/farc/rensai2/emer01/emer01a.html

火を噴いたプロジェクトを立て直したプロジェクト管理の話し。

まだ第一回目だから本題に入っていないけど、「自己組織化したプロジェクト」というのがキーワードらしい。そのために筆者(火消しとして入ったプロマネ)は、これらのことを実施したそうだ。

* 朝は遅刻厳禁:朝バラバラに出社して、深夜まで仕事をする、という習慣をやめさせました

* 朝のスタートアップミーティングと夕方のラップアップミーティングの実施:定刻に始まり、きっかり15分で終わる朝/夕のチームミーティングを、1日も漏れずに行うようにしました

* WSS(Windows Sharepoint Services)を導入し、情報を一元化:WebポータルアプリケーションであるWSSを導入して、情報を一元管理しました。進ちょく/仕様/課題/障害管理データベースはここに作りました

* 進ちょく/仕様/課題/障害管理で必要とされる項目を必要最低限に:複雑になりがちなこれらの管理情報項目を大幅に削減しました。進ちょく率などは、85%完了、といった細かな管理を一切やめ、未着手(0%)、作業中(50%)、完了(100%)、中止のみとしました

* 進ちょく/仕様/課題/障害管理で必須項目はすべて最新であるように徹底:管理情報項目を最低限のものにする代わり、それらの項目は絶対に漏れがなく最新ステータスであるよう、徹底しました

* 課題/障害管理データベースに、どんな問題でもとにかく起票するよう徹底:課題や障害の起票ルールを最低限とし、とにかく起こったことはすべて起票するように全員に徹底しました

たったこれだけでプロジェクトが立ち直るのか?という疑問が先に来る。これから先の連載でこの辺は出てくるんだろうけど…。

この中で最後の項目の課題・障害管理でとにかく何でも問題点などを洗いざらいにするってのが一番効果的なんじゃないかと思う。

自分が今やっているプロジェクトも

  • 外部とのインタフェースが多いので他所との調整や検討作業が多い
  • 機能が細分化されていてそれぞれ仕様が細かい
  • その仕様がコロコロ変わる
  • システム全体の規模が大きいので何かするにも既存のルールや仕様を調査する必要あり
  • ひたすら短期開発で常にドタバタしている

という中で、情報がすぐに錯綜してしまう。あの検討項目はお客に問い合わせたあと回答があったか?とか、これは相手機能の担当とネゴを取ったか?とか…。そういうのを各プロジェクトメンバが抱えてしまったままだとプロマネもプロジェクトのっ状況をつかみようがないし、各個人の進捗の管理もできなくなってしまう。それに、どこかに記録しておかないと担当者自ら忘れ去ってしまう危険もある。

そこで状態が混沌としてくると、「未解決、検討、要調査事項」をTracのWiki上にすべて出させるようにして、何を解決しないと進まないかをメンバー全体で情報共有することにした。

こうすることで直接自分と関係のない機能であっても、何か知っていることがあれば教えることができるし、プロマネはこれをチェックリスト代わりにして課題を一つずつ片付けていけば良い。

じっさい、仕様検討段階では何回かこうやって「棚卸し」をして情報の整理をしたおかげで、火を噴くことなく進められたのではないかと思っている。実際の具体的な効果は測れないけど、何もしない状態ではプロマネ自身が状況の把握で回らなくなっていたと思うし…。

そういう意味では、この筆者のやり方に通じるものはあるかも。プロジェクト規模とかぜんぜん違うんだろうけどね。


スポンサーリンク