http://lislog.livedoor.com/r/9120
19時でも結構、キツイんだよな。。。
2008年6月20日金曜日
2008年6月19日木曜日
Firefox3ですな
リリースされて5時間で深刻な脆弱性発覚ですか。そうですか。
「Firefox 3」、正式リリース後5時間で初の脆弱性が見つかる
でもタケはFirefox3使ってます。
とくに理由はありません。
使い慣れたブラウザがFirefoxなだけです。
「Firefox 3」、正式リリース後5時間で初の脆弱性が見つかる
でもタケはFirefox3使ってます。
とくに理由はありません。
使い慣れたブラウザがFirefoxなだけです。
ATOK定額制サービス
ジャストシステム、月額300円の「ATOK定額制サービス」を開始
年間3,200円で常に最新のATOKが使えてあのアホを使わなくてすむなら検討の余地あり、というか多分申し込む。
ちなみに会社PCはVAIOなもんでATOK搭載済み。
Excelとの相性の悪さ、Thunderbirdのショートカットに勝ってしまったりと問題がまったくないわけではないが、それでもあのアホと比べたら！
300円徴収する方が大変そうだけど法人でドカンと契約とかが見込めるのかな？
年間3,200円で常に最新のATOKが使えてあのアホを使わなくてすむなら検討の余地あり、というか多分申し込む。
ちなみに会社PCはVAIOなもんでATOK搭載済み。
Excelとの相性の悪さ、Thunderbirdのショートカットに勝ってしまったりと問題がまったくないわけではないが、それでもあのアホと比べたら！
300円徴収する方が大変そうだけど法人でドカンと契約とかが見込めるのかな？
2008年6月10日火曜日
2008年5月27日火曜日
[memo]おもてなしとコーヒーポット
ドバイでは「コーヒーポット」には「おもてなし」
の意味が込められている、
という話を世界ふしぎ発見！でやってました。
> > Ｑ３もてなしの精神の象徴にし、大切にされているものとは？
> >
> > Ａ：ポット（コーヒーポット）
http://television.ti-da.net/e2033584.html
JavaでRIAでユーザーエクスペリエンスなことやっていると人には「へぇ～」が高いトリビアだと思いませんか？
の意味が込められている、
という話を世界ふしぎ発見！でやってました。
> > Ｑ３もてなしの精神の象徴にし、大切にされているものとは？
> >
> > Ａ：ポット（コーヒーポット）
http://television.ti-da.net/e2033584.html
JavaでRIAでユーザーエクスペリエンスなことやっていると人には「へぇ～」が高いトリビアだと思いませんか？
2008年5月25日日曜日
2008年5月7日水曜日
[RIA][memo]RIAのメリットというかを殴り書き
青いこと書いてたなー。。。。。。
以下、本文
ビジネス視点のRIA活用
①RIAによるビジネスメリット
②RIAに取り組むには？
～コンサルタント選びのポイント～
③RIAプロジェクトの進め方
～現物主義～
④RIAの保守・運用
～攻めの保守・運用～
全体を通じて
・ユーザー視点のアプローチ
・テクノロジー中心のアプローチ
の両方が必要であることをテーマとする
①RIAによるビジネスメリット
ユーザー視点と管理者の視点で考えること
ユーザーは使いやすい、楽しい、仕事がはかどる
管理者は管理が楽になる
これらはシステムを使うための目に見えづらい負担からの解放
システムを使うための苦労が減る分、ユーザーは一件でも多くの仕事をこなすし、あるいは高品質なサービスにつながる。
管理者は次の改善策、運用策を考えることができる。
繰り返すがRIAはかかわる人間に対し、システム利用時にまつわる「使うための負担」を下げ、より本来の業務に注力
できるようにする技術である。またそれを強く意識して活用されるものである。
②RIAに取り組むには？
～コンサルタント選びのポイント～
RIAのプラットフォームベンダ(AdobeやMicrosoftなど)に相談をすると「開発経験のあるベンダーのサポートをえてください」となることがおおい。
その言葉に従いキックオフ。でも何故かプロジェクトの進捗が芳しくない。
もしかしたらそのベンダーの経験領域の外の仕事をしている可能性がいあります。
たとえば一口にFlashといっても、エンジニアのタイプには下記があります。
Flashデザイナー／アニメーター
→Web上のコンテンツなどを制作する人。使用ツールはFlash CS3
Flashデベロッパー
→ActionScriptを記述してプログラムを構築する人。エンジニアの数は非常に少ない。
Flexプログラマ
→FlexBuilderを使ってプログラムを構築する人。じつはFlexプログラマの中にも
・Mxmlに強い人
・ActionScriptに強い人
・サーバー側との通信部分に強い人
などの種類がある。
UIデザイナー
→アプリケーションのユーザーインターフェースデザインについて設計、構築する人。Flexプロジェクトだとmxmlを書くことも多々あり。
またUIデザインから要件を詰められる人はいなくもないが希少人種
サーバーサイドのエンジニア
Java、PHP、.NET、等々のLogicを作る技術があってさらにデータベースとの連携。。。。。。
FlashやAIRが実行環境となっている場合、構築技術としては広い範囲をカバーする必要があるため、Flashができれば即OKとはなりません。
他にもOOP理解していますか？ OOPの理解が拡張性、変更容易性の高い設計に結びついていますか？
生産性と品質を確保するためのフレームワークを熟知してますか？
フレームワークの相性を理解していますか？
中～大規模プロジェクトの経験はありますか？ などなど。プロジェクトマネジメントのスキルと実装スキルは別物です。
まとめるとRIAはこれらの様々なスキルを統合して進めるスキルが必要です。それがないとシステムの「全体最適」は図れません。
そしてFlex/Flash/AIRの独特なところ、深いところをどうにかできるスキル。
ユーザーからみた要望とテクノロジーからの検証を両面で進められるスキル。
これだけ必要です。
どれか欠けるなら代替え策が必要です。
③RIAプロジェクトの進め方
～現物主義～
アジャイル型開発に対する誤解。
変化の激しい市場に適用させるためにあるプロセスであること。
RIA開発におけるIIDのメリットは→現物主義であること。
設計と実装で見積もりを二回とること。これ重要。
「やっぱりできないんですけど」のリスクは避けたい
ベンダーがきついと品質にも悪影響。
win-winであることが重要
④RIAの保守・運用
～攻めの保守・運用～
Flex/AIRであればユーザーごとにカスタマイズも可能（一部ですが）
アカウント管理によって権限を設定して使える機能と使えない機能をもたせる。
動的CSSで見た目を変える。
これらは開発が上手くできていれば変更拡張は簡単
よって
管理者は業務に集中できる
ユーザーは改善要望をだしやすくなる。
より強力にシステムを使い倒すことができる
そして開発ベンダーをキープしましょう。またキープできるベンダーを探しましょう。
保守体制を切り分けましょう
ユーザー → 一時対応（あなた）→対策（ベンダー）
「もちはもちやに」
結構、大切なんですよ♪
逆説的に言うと
ユーザーが使いづらいのに改善されないシステムとの決別
以下、本文
ビジネス視点のRIA活用
①RIAによるビジネスメリット
②RIAに取り組むには？
～コンサルタント選びのポイント～
③RIAプロジェクトの進め方
～現物主義～
④RIAの保守・運用
～攻めの保守・運用～
全体を通じて
・ユーザー視点のアプローチ
・テクノロジー中心のアプローチ
の両方が必要であることをテーマとする
①RIAによるビジネスメリット
ユーザー視点と管理者の視点で考えること
ユーザーは使いやすい、楽しい、仕事がはかどる
管理者は管理が楽になる
これらはシステムを使うための目に見えづらい負担からの解放
システムを使うための苦労が減る分、ユーザーは一件でも多くの仕事をこなすし、あるいは高品質なサービスにつながる。
管理者は次の改善策、運用策を考えることができる。
繰り返すがRIAはかかわる人間に対し、システム利用時にまつわる「使うための負担」を下げ、より本来の業務に注力
できるようにする技術である。またそれを強く意識して活用されるものである。
②RIAに取り組むには？
～コンサルタント選びのポイント～
RIAのプラットフォームベンダ(AdobeやMicrosoftなど)に相談をすると「開発経験のあるベンダーのサポートをえてください」となることがおおい。
その言葉に従いキックオフ。でも何故かプロジェクトの進捗が芳しくない。
もしかしたらそのベンダーの経験領域の外の仕事をしている可能性がいあります。
たとえば一口にFlashといっても、エンジニアのタイプには下記があります。
Flashデザイナー／アニメーター
→Web上のコンテンツなどを制作する人。使用ツールはFlash CS3
Flashデベロッパー
→ActionScriptを記述してプログラムを構築する人。エンジニアの数は非常に少ない。
Flexプログラマ
→FlexBuilderを使ってプログラムを構築する人。じつはFlexプログラマの中にも
・Mxmlに強い人
・ActionScriptに強い人
・サーバー側との通信部分に強い人
などの種類がある。
UIデザイナー
→アプリケーションのユーザーインターフェースデザインについて設計、構築する人。Flexプロジェクトだとmxmlを書くことも多々あり。
またUIデザインから要件を詰められる人はいなくもないが希少人種
サーバーサイドのエンジニア
Java、PHP、.NET、等々のLogicを作る技術があってさらにデータベースとの連携。。。。。。
FlashやAIRが実行環境となっている場合、構築技術としては広い範囲をカバーする必要があるため、Flashができれば即OKとはなりません。
他にもOOP理解していますか？ OOPの理解が拡張性、変更容易性の高い設計に結びついていますか？
生産性と品質を確保するためのフレームワークを熟知してますか？
フレームワークの相性を理解していますか？
中～大規模プロジェクトの経験はありますか？ などなど。プロジェクトマネジメントのスキルと実装スキルは別物です。
まとめるとRIAはこれらの様々なスキルを統合して進めるスキルが必要です。それがないとシステムの「全体最適」は図れません。
そしてFlex/Flash/AIRの独特なところ、深いところをどうにかできるスキル。
ユーザーからみた要望とテクノロジーからの検証を両面で進められるスキル。
これだけ必要です。
どれか欠けるなら代替え策が必要です。
③RIAプロジェクトの進め方
～現物主義～
アジャイル型開発に対する誤解。
変化の激しい市場に適用させるためにあるプロセスであること。
RIA開発におけるIIDのメリットは→現物主義であること。
設計と実装で見積もりを二回とること。これ重要。
「やっぱりできないんですけど」のリスクは避けたい
ベンダーがきついと品質にも悪影響。
win-winであることが重要
④RIAの保守・運用
～攻めの保守・運用～
Flex/AIRであればユーザーごとにカスタマイズも可能（一部ですが）
アカウント管理によって権限を設定して使える機能と使えない機能をもたせる。
動的CSSで見た目を変える。
これらは開発が上手くできていれば変更拡張は簡単
よって
管理者は業務に集中できる
ユーザーは改善要望をだしやすくなる。
より強力にシステムを使い倒すことができる
そして開発ベンダーをキープしましょう。またキープできるベンダーを探しましょう。
保守体制を切り分けましょう
ユーザー → 一時対応（あなた）→対策（ベンダー）
「もちはもちやに」
結構、大切なんですよ♪
逆説的に言うと
ユーザーが使いづらいのに改善されないシステムとの決別
2008年4月23日水曜日
[memo]勝てる見積もり
仕事柄、何度となく見積もりを書いていますが、やっぱり仕事とれないとどんなに「美しい」見積もり書いても意味ねーと思うんですよ。
というわけで「勝てる見積もり」についてアイディアをメモ。これからブラッシュアップ。
・組織として一定のフローを持つこと
・モデルシステム
業種ごとにいくつかのモデルシステムを作る(あくまで見積もりとプロジェクト計画の話)
依頼された見積もりはモデルシステムをベースに差分を数えることで規模間を算出する。
これは営業段階でやっていいプロジェクトかどうかを判断できる
・モデルプロジェクト
モデルシステムに対してどこまでが決定事項なのか判断する。
・モデルシステムとモデルプロジェクトのメンテナンス
日常業務と密接に結びついて、常に最新の状態を保つこと。
・お客さまはコストだけを見ているわけではないこと
・品質
広義の意味で。ユーザビリティといった数値化しづらい付加価値についてもしっかりアピールすること
・コスト
安いに超したことはないが、お客さまがシステムに対して求める条件を満たすために必要十分なコストを
請求すること。
・納期
ほとんどの場合、システムは1日も早くビジネスの現場に投入される必要がある。
・スコープ
スコープ網羅率。QCDと関わる要素だが、お客さまの求めるものを作りきること。場合によっては機能スコープに優先度をつけ、お客さまに対し「過剰な機能」であることを伝えること
・マイルストーン
いつの段階でどういったものがだせるか？ 見せられるか？ エンジニアの都合だけで進めず、プロジェクトの可視化も含めて宣言をすること
というわけで「勝てる見積もり」についてアイディアをメモ。これからブラッシュアップ。
・組織として一定のフローを持つこと
・モデルシステム
業種ごとにいくつかのモデルシステムを作る(あくまで見積もりとプロジェクト計画の話)
依頼された見積もりはモデルシステムをベースに差分を数えることで規模間を算出する。
これは営業段階でやっていいプロジェクトかどうかを判断できる
・モデルプロジェクト
モデルシステムに対してどこまでが決定事項なのか判断する。
・モデルシステムとモデルプロジェクトのメンテナンス
日常業務と密接に結びついて、常に最新の状態を保つこと。
・お客さまはコストだけを見ているわけではないこと
・品質
広義の意味で。ユーザビリティといった数値化しづらい付加価値についてもしっかりアピールすること
・コスト
安いに超したことはないが、お客さまがシステムに対して求める条件を満たすために必要十分なコストを
請求すること。
・納期
ほとんどの場合、システムは1日も早くビジネスの現場に投入される必要がある。
・スコープ
スコープ網羅率。QCDと関わる要素だが、お客さまの求めるものを作りきること。場合によっては機能スコープに優先度をつけ、お客さまに対し「過剰な機能」であることを伝えること
・マイルストーン
いつの段階でどういったものがだせるか？ 見せられるか？ エンジニアの都合だけで進めず、プロジェクトの可視化も含めて宣言をすること
2008年4月13日日曜日
[Project][memo]受託開発の極意
「受託開発の極意(岡島幸男[著] 技術評論社)」を読みました。
思ったことをメモ。
でもメモ意味ないかも。
手元に置いてふとしたときに手にとって読む。
自分やチームの仕事の仕方を振り返ってみる。
自分と役割が近い人、仕事で関わることが多い人と読み合わせて語り合ってみる。
それぐらいしたい本でした。
ここであえてふれていないColumnも役立つ情報多かったし！
なので
「購 読 す る こ と を オ ス ス メ し ま す」
0章 受託開発を楽しむには
0.2
「顧客満足の公式」
顧客満足はQCDからなる成果物に対する「結果」と、仕事を進めていく過程にたいする「感情」の両面からなるということ。
私も恩師から「お客さんは感動に対してお金を払う」といわれたことがあるので、この説明はとても納得。
(こまかく話すとちょっと違うんだけどね)
第1部 受託開発の手ほどき
第1章 お客様に関心をもつ
1.1
「7段階にもネストしたif文や～」
ごめん。それオレ(笑)。
正確に言うとExcelの関数でIF文の限界にチャレンジしてた。無知って恐ろしい。
1.2
「要はお客さまと接する機会が少ないため関心が持てないのです。会ってもいない人に関心を持つことはできません」
激しく同意！ ちなみに私はお客さまとお会いしないと仕事できないタイプ。
たまにお客さまの顔見ないで仕事する必要が発生しますが、なんかあってもちゃんと判断できないですよ。
情報が一方的に的になっちゃうから。
1.6
「お客さまの立場でプロジェクトを眺める」
仕事してるとついついこっち都合を優先しちゃったりするのですが、、、いかんですよね。
猛省です。
第2章
「サービスは見積りから始まっている」
スティーブ・マコネルの『ソフトウェア見積り』が引き合いに出されています。
タケも読みました！
マコネル最高ｗ この本に書かれている見積もりに関する話は非常に奥が深い！
2.2
「お客さまは金額だけで発注先を決めるのではありません。見積もり期間におけるサービスの質も重視しましょう。」
うっすらわかっているようでいてちゃんとわかっていなかったこと。
言い換えると安易な価格勝負すんな！ と。
もし価格勝負をするために意図的にテスト期間を短くして品質を下げるようなことがあるなら、いかんですよね。
システムに関わるもののモラルの問題も含めて、見積もりはしっかりやらないと。
また「プラスα」はいままでまったくできてなかった。スキル不足と時間不足のせいにして。これもなんとかしたいなぁ。
2.4
「見積もり手法を身につける」
「オブジェクト倶楽部」のワークシートが紹介されていました(http://www.objectclub.jp/download/)。
今度、試してみよう♪
タケはそんなに見積もり手法を勉強した訳じゃないですけど、いろいろな手法を知ったり勉強したりすると見積もりに対する考え方に厚みがでる気がします。
日々勉強ですな。
第3章
3.1
「実質、要件は変わったのではなく、間違って定義されてしまっていることが多いのです。」
そうっすよね！
あとプロジェクトがキックオフするときに営業から開発へ情報伝達が上手く言ってない場合！
これもある意味、間違った要件定義。
話変わりますけど、RIA開発に関わっていると「デザイナとデベロッパの協業」についてよく議題にあがりますが、それ以上に営業と技術者の協業の方が問題な気がします。
炎上する原因てだいたいそれだよね。
3.2
手段ばかりに着目するのではなく何を何故作るのか！? を考えなさいと。なんかもう御礼言いたいです。
3.4
「表3-1 システム要件で定義する内容」
これもきっちり認識する必要あり。
3.7
「丸投げドキュメントの読み方」
これは丸投げドキュメントに限らない気がするのですが、それってタケがいつも丸投げされている証拠？
第4章 保守性にこだわった設計・実装・テスト
4.4
単体テストが重要だというのは重々承知していたつもりですが、サンプルとして数値でだされるとその重要さをより認識することができます。
4.5
テスト計画の重要性、各フェーズで何を気をつけるべきかが書いてあります。品質をどこまで保証する、つまりどれくらいテストをしっかりやるか、どういった分担で行うのか、どういったアプローチをとるのかはプロジェクトを始める前にしっかり決めておかないといけないはずです。
またテストは私の知る限りでは必ずと言っていいほどクリティカルパスになります。
テストちょー重要！
第5章 運用が最上流
5.2
「お客さまとの信頼関係も保守する」
なんて良いことを言うんだろう。。。
5.3
「テスト資産を活かす」
なんだかんだ言って、同じテストを何度も何度もやることになることがあります。
そう考えたらテスト計画やテスト仕様書、結果はしっかり書かなきゃいけないし、ツールを使って自動化できるんだったらやっておいた方がいいかもしれません。
第6章 計画とスケジュールの管理
「計画がないプロジェクトはありえませんし、計画が頻繁に変わるからといって、まったく無秩序ではいけません。計画は管理・メンテナンスするものです。」
私の作るMSPがプロジェクト開始2週間でぐっちゃぐちゃになるのはMSPがダメなツールだからではなくて、プロジェクトの計画と実行と管理というのはそんなもんだからです。全然変わらない場合は「わーい♪」と喜んでないで潜在リスクがないか考えないと。
6.1
「3つのスケジュールを使い分ける」
これは目から鱗。。。
プロジェクトを進めていく内にだんだんブレイクダウンしていくことはありますが、明確に3つに分ける(違うものだと認識する)のは考えてなかった。。。
きっと当たり前なんだろうな。自分の無知がおそろすぃ。
6.3
「見積もりが外れる原因と対策」
私は個人的には下記のように考えています。ちなみにKKD法(笑)ね。
・経験
→タスク洗い出し、アプリーチやプロセスの選択、プロジェクト基盤作成に必要なことや技術知識などなど。
・勘
→潜在するリスクをあげること。ここは○○日じゃないだろう…とか、ここで詰まるだろう…とか。
・度胸
→工数を「削る」のは度胸！ ここは○○日もいらないだろう…とか。超安全見積もりで仕事がとれるほど世の中そんなに甘くない！
6.5
「プレッシャーを感じたままスケジュールや計画を立てると、手段の目的化が起きます。」
私はプロジェクトの計画を立てるのと見積もりを書くのは限りなく近い作業であると認識しているので、それを前提に話すと、見積もりを書くときに入ってくる情報が「参考値」なのか「制約条件」なのかはちゃんと切り分ける必要があります。
特に予算はね。書こうと思えば書けるんですよ。予算内で。やべーな、と思ってても。。。
ましてや見積もりを書く人間より、その情報をもってくる人が年長者だったり経験が豊富だったり組織内で権力もってたりすると、余計にやっかいです。そういうもんだって思っちゃうからね。
第7章 チームで成功を目指す
7.3
「表7-1 リーダーのカラー別の特徴」
これわ。。。「ボケボケ」型ってないんですか？ タケはボケボケ型だと思います。
7.4
「お客さまに対する陰口を止めてみる」
コラッ！
7.5
「交渉力」
勝ち過ぎない、っていうのはわりと意識してやってますね。
でもそれでつけ込まれて不利になることが多い気もします。。。さじ加減が難しい。
第2部 人と組織を変えること
8.5
「問題なのは相対評価を気にするあまり自信をなくし、自分が何を目指したいのかわからなくなってしまうことです。」
うーむ。確かにわからなくなっている気がしますなー
Column
「アムロとブライトさんのセリフ」
岡島さんとは美味い酒がのめそう(笑)。
タケはもう子供がいて30歳にもなったので「若さ故の過ちか…」と言えない感じです。
思ったことをメモ。
でもメモ意味ないかも。
手元に置いてふとしたときに手にとって読む。
自分やチームの仕事の仕方を振り返ってみる。
自分と役割が近い人、仕事で関わることが多い人と読み合わせて語り合ってみる。
それぐらいしたい本でした。
ここであえてふれていないColumnも役立つ情報多かったし！
なので
「購 読 す る こ と を オ ス ス メ し ま す」
0章 受託開発を楽しむには
0.2
「顧客満足の公式」
顧客満足はQCDからなる成果物に対する「結果」と、仕事を進めていく過程にたいする「感情」の両面からなるということ。
私も恩師から「お客さんは感動に対してお金を払う」といわれたことがあるので、この説明はとても納得。
(こまかく話すとちょっと違うんだけどね)
第1部 受託開発の手ほどき
第1章 お客様に関心をもつ
1.1
「7段階にもネストしたif文や～」
ごめん。それオレ(笑)。
正確に言うとExcelの関数でIF文の限界にチャレンジしてた。無知って恐ろしい。
1.2
「要はお客さまと接する機会が少ないため関心が持てないのです。会ってもいない人に関心を持つことはできません」
激しく同意！ ちなみに私はお客さまとお会いしないと仕事できないタイプ。
たまにお客さまの顔見ないで仕事する必要が発生しますが、なんかあってもちゃんと判断できないですよ。
情報が一方的に的になっちゃうから。
1.6
「お客さまの立場でプロジェクトを眺める」
仕事してるとついついこっち都合を優先しちゃったりするのですが、、、いかんですよね。
猛省です。
第2章
「サービスは見積りから始まっている」
スティーブ・マコネルの『ソフトウェア見積り』が引き合いに出されています。
タケも読みました！
マコネル最高ｗ この本に書かれている見積もりに関する話は非常に奥が深い！
2.2
「お客さまは金額だけで発注先を決めるのではありません。見積もり期間におけるサービスの質も重視しましょう。」
うっすらわかっているようでいてちゃんとわかっていなかったこと。
言い換えると安易な価格勝負すんな！ と。
もし価格勝負をするために意図的にテスト期間を短くして品質を下げるようなことがあるなら、いかんですよね。
システムに関わるもののモラルの問題も含めて、見積もりはしっかりやらないと。
また「プラスα」はいままでまったくできてなかった。スキル不足と時間不足のせいにして。これもなんとかしたいなぁ。
2.4
「見積もり手法を身につける」
「オブジェクト倶楽部」のワークシートが紹介されていました(http://www.objectclub.jp/download/)。
今度、試してみよう♪
タケはそんなに見積もり手法を勉強した訳じゃないですけど、いろいろな手法を知ったり勉強したりすると見積もりに対する考え方に厚みがでる気がします。
日々勉強ですな。
第3章
3.1
「実質、要件は変わったのではなく、間違って定義されてしまっていることが多いのです。」
そうっすよね！
あとプロジェクトがキックオフするときに営業から開発へ情報伝達が上手く言ってない場合！
これもある意味、間違った要件定義。
話変わりますけど、RIA開発に関わっていると「デザイナとデベロッパの協業」についてよく議題にあがりますが、それ以上に営業と技術者の協業の方が問題な気がします。
炎上する原因てだいたいそれだよね。
3.2
手段ばかりに着目するのではなく何を何故作るのか！? を考えなさいと。なんかもう御礼言いたいです。
3.4
「表3-1 システム要件で定義する内容」
これもきっちり認識する必要あり。
3.7
「丸投げドキュメントの読み方」
これは丸投げドキュメントに限らない気がするのですが、それってタケがいつも丸投げされている証拠？
第4章 保守性にこだわった設計・実装・テスト
4.4
単体テストが重要だというのは重々承知していたつもりですが、サンプルとして数値でだされるとその重要さをより認識することができます。
4.5
テスト計画の重要性、各フェーズで何を気をつけるべきかが書いてあります。品質をどこまで保証する、つまりどれくらいテストをしっかりやるか、どういった分担で行うのか、どういったアプローチをとるのかはプロジェクトを始める前にしっかり決めておかないといけないはずです。
またテストは私の知る限りでは必ずと言っていいほどクリティカルパスになります。
テストちょー重要！
第5章 運用が最上流
5.2
「お客さまとの信頼関係も保守する」
なんて良いことを言うんだろう。。。
5.3
「テスト資産を活かす」
なんだかんだ言って、同じテストを何度も何度もやることになることがあります。
そう考えたらテスト計画やテスト仕様書、結果はしっかり書かなきゃいけないし、ツールを使って自動化できるんだったらやっておいた方がいいかもしれません。
第6章 計画とスケジュールの管理
「計画がないプロジェクトはありえませんし、計画が頻繁に変わるからといって、まったく無秩序ではいけません。計画は管理・メンテナンスするものです。」
私の作るMSPがプロジェクト開始2週間でぐっちゃぐちゃになるのはMSPがダメなツールだからではなくて、プロジェクトの計画と実行と管理というのはそんなもんだからです。全然変わらない場合は「わーい♪」と喜んでないで潜在リスクがないか考えないと。
6.1
「3つのスケジュールを使い分ける」
これは目から鱗。。。
プロジェクトを進めていく内にだんだんブレイクダウンしていくことはありますが、明確に3つに分ける(違うものだと認識する)のは考えてなかった。。。
きっと当たり前なんだろうな。自分の無知がおそろすぃ。
6.3
「見積もりが外れる原因と対策」
私は個人的には下記のように考えています。ちなみにKKD法(笑)ね。
・経験
→タスク洗い出し、アプリーチやプロセスの選択、プロジェクト基盤作成に必要なことや技術知識などなど。
・勘
→潜在するリスクをあげること。ここは○○日じゃないだろう…とか、ここで詰まるだろう…とか。
・度胸
→工数を「削る」のは度胸！ ここは○○日もいらないだろう…とか。超安全見積もりで仕事がとれるほど世の中そんなに甘くない！
6.5
「プレッシャーを感じたままスケジュールや計画を立てると、手段の目的化が起きます。」
私はプロジェクトの計画を立てるのと見積もりを書くのは限りなく近い作業であると認識しているので、それを前提に話すと、見積もりを書くときに入ってくる情報が「参考値」なのか「制約条件」なのかはちゃんと切り分ける必要があります。
特に予算はね。書こうと思えば書けるんですよ。予算内で。やべーな、と思ってても。。。
ましてや見積もりを書く人間より、その情報をもってくる人が年長者だったり経験が豊富だったり組織内で権力もってたりすると、余計にやっかいです。そういうもんだって思っちゃうからね。
第7章 チームで成功を目指す
7.3
「表7-1 リーダーのカラー別の特徴」
これわ。。。「ボケボケ」型ってないんですか？ タケはボケボケ型だと思います。
7.4
「お客さまに対する陰口を止めてみる」
コラッ！
7.5
「交渉力」
勝ち過ぎない、っていうのはわりと意識してやってますね。
でもそれでつけ込まれて不利になることが多い気もします。。。さじ加減が難しい。
第2部 人と組織を変えること
8.5
「問題なのは相対評価を気にするあまり自信をなくし、自分が何を目指したいのかわからなくなってしまうことです。」
うーむ。確かにわからなくなっている気がしますなー
Column
「アムロとブライトさんのセリフ」
岡島さんとは美味い酒がのめそう(笑)。
タケはもう子供がいて30歳にもなったので「若さ故の過ちか…」と言えない感じです。
2008年3月26日水曜日
[memo]アーキテクチャ
スターロジックのはぶさん(面識はありませんが)のブログより
「アーキテクチャ」
http://d.hatena.ne.jp/habuakihiro/20080317#1205758083
同意。激しく同意。
最近はプロジェクトの計画や契約書にだってあるんではないかと思っています。
プロジェクトの計画も、たとえば作業内容がシンプルになっている方が作業効率は良いと思います。あれもこれも同時に、、、は危険。意外とパフォーマンス悪くなるし。
複雑怪奇でどう解釈していいのか分からない契約書より、記述がシンプルで数値も具体的なものの方がわかりやすいですよね。いやなのはわかるんですが、ステークホルダーで認識を一致するのであればシンプルなものの方がリスクは少ないよなー、と思います。
「アーキテクチャ」
http://d.hatena.ne.jp/habuakihiro/20080317#1205758083
同意。激しく同意。
最近はプロジェクトの計画や契約書にだってあるんではないかと思っています。
プロジェクトの計画も、たとえば作業内容がシンプルになっている方が作業効率は良いと思います。あれもこれも同時に、、、は危険。意外とパフォーマンス悪くなるし。
複雑怪奇でどう解釈していいのか分からない契約書より、記述がシンプルで数値も具体的なものの方がわかりやすいですよね。いやなのはわかるんですが、ステークホルダーで認識を一致するのであればシンプルなものの方がリスクは少ないよなー、と思います。
2008年3月21日金曜日
[memo]納期優先の無理なプロジェクトが失敗を招く
納期優先の無理なプロジェクトが失敗を招く
http://jibun.atmarkit.co.jp/lskill01/rensai/pwhyf05/pwhyf01.html
案件を取ってくる段階でしっかりハンドリングしましょう、
というメッセージかと思います。
過去記事のタイトルとかみると耳が痛いですね。。。
2008年2月2日土曜日
[memo]作業の履歴をとることにした
もとはといえば「書きなさい！」というお達しだったのですが、やってみると結構、楽しい？
少なくとも自分の役にはたっている気がする。
ここからはまじめな話。
タケは仕事を一言で表現すると「IT雑用係」です。
社内外のいろんな人との連携やら調整やらが発生します。
コミュニケーションをとって目的と手段の認識を一致させたり共有したり。
わかりやすい成果のでる作業以外に使っている時間が結構多いわけです。
も～何やってんのか自分でもわかんない。
もやもや～ん！！！
そんな毎日なわけです。
なので細かく作業の履歴をとることにしました。ちょっと面倒くさいけど。
簡単な表をExcelで作って、開始時刻を入力(ショートカット Ctrl+「*」)。
作業内容を簡単に書いて着手。終わったら終了時刻を入力。
割り込みはいったら割り込みもちゃんと書く。
こうやって計測をつづけるとタケの仕事の生産効率に影響するものがハッキリしてくると思います。
（たぶん割り込みと不要な情報のインプットだ。間違いない。）
ちなみにソフトウェア開発の計測は総コストの7～9%必要、とのこと(※ 「初めて学ぶ ソフトウェアメトリクス」より)。
タケの仕事にかぎらずそんくらいの時間と金かけて計測した方がいいと思うんですわ。
現状を数値で認識できなければ、改善の目標なんて立てられないし、そもそも適正かどうかもあいまいな判断になってしまうし。
「改善する前に計測すべし」
なんか良いこと言った気がする。
孫子の兵法に通ずるものがある気がする。
あと着手した作業はできるだけその時にかたづけることを強く意識する、とか。
細かい作業でもつもってくと効率悪くなってきます。マルチタスクについては「クリティカルチェーン」にリードタイムの増加の弊害としてさくっと書かれていました（たしか）。
作業効率を改善して、自分のための時間を増やそう♪キャンペーンです。
とても初歩的な話ですが。
少なくとも自分の役にはたっている気がする。
ここからはまじめな話。
タケは仕事を一言で表現すると「IT雑用係」です。
社内外のいろんな人との連携やら調整やらが発生します。
コミュニケーションをとって目的と手段の認識を一致させたり共有したり。
わかりやすい成果のでる作業以外に使っている時間が結構多いわけです。
も～何やってんのか自分でもわかんない。
もやもや～ん！！！
そんな毎日なわけです。
なので細かく作業の履歴をとることにしました。ちょっと面倒くさいけど。
簡単な表をExcelで作って、開始時刻を入力(ショートカット Ctrl+「*」)。
作業内容を簡単に書いて着手。終わったら終了時刻を入力。
割り込みはいったら割り込みもちゃんと書く。
こうやって計測をつづけるとタケの仕事の生産効率に影響するものがハッキリしてくると思います。
（たぶん割り込みと不要な情報のインプットだ。間違いない。）
ちなみにソフトウェア開発の計測は総コストの7～9%必要、とのこと(※ 「初めて学ぶ ソフトウェアメトリクス」より)。
タケの仕事にかぎらずそんくらいの時間と金かけて計測した方がいいと思うんですわ。
現状を数値で認識できなければ、改善の目標なんて立てられないし、そもそも適正かどうかもあいまいな判断になってしまうし。
「改善する前に計測すべし」
なんか良いこと言った気がする。
孫子の兵法に通ずるものがある気がする。
あと着手した作業はできるだけその時にかたづけることを強く意識する、とか。
細かい作業でもつもってくと効率悪くなってきます。マルチタスクについては「クリティカルチェーン」にリードタイムの増加の弊害としてさくっと書かれていました（たしか）。
作業効率を改善して、自分のための時間を増やそう♪キャンペーンです。
とても初歩的な話ですが。
2008年1月22日火曜日
2008年1月15日火曜日
[memo]古今東西のＳＥとプログラマという記事について
古今東西のＳＥとプログラマ
http://blue.hkisl.net/mutteraway/archives/2004/05/post_2.html
備忘録？のために貼り付け。
思うにプログラマを評価するしないではなく単純に「金に近いところにいる人に金が入る」世の中な気がします。
良いか悪いかはおいといて。
つまり
「実際に業務に携わる人（※）」＞「業務を設計する人」＞「システムを設計する人」＞「システムを構築する人」
という序列というか金に対する距離があって、左から順に取り分を取ったら右の人の取り分は少なくなるでしょう、、、と。
※ 正確には「実際に業務に携わる人を雇用している人」
とはいっても「システムを構築する人」がいなくてはシステム作れないですし、業務だってどーともならないかもしれません。卵が先か鶏が先か、みたいな話です。
他の人も言っているかも知れませんが、「腕の良いプログラマ」と「普通のプログラマ」の作るものがどうちがうのか？ どんな付加価値があるのか？ そういったことを数値で証明する必要があるのではないでしょうか。お金に近い人は数字が大好きです。
そこでまた難しいのですが、それには正確で的を得た「計測」の作業が必要なはずです。
しかし悲しいかな、私の働く会社も同じく計測に使うコストや工数が捻出できません。必要性も感じていません。
悲しいです。
私は一所懸命働くエンジニアにやりがいのある仕事を良い条件で楽しくやってもらうことが今の仕事の目標の一つだと思っています。
でも本当に難しいです。
悩みがつきません。
http://blue.hkisl.net/mutteraway/archives/2004/05/post_2.html
備忘録？のために貼り付け。
思うにプログラマを評価するしないではなく単純に「金に近いところにいる人に金が入る」世の中な気がします。
良いか悪いかはおいといて。
つまり
「実際に業務に携わる人（※）」＞「業務を設計する人」＞「システムを設計する人」＞「システムを構築する人」
という序列というか金に対する距離があって、左から順に取り分を取ったら右の人の取り分は少なくなるでしょう、、、と。
※ 正確には「実際に業務に携わる人を雇用している人」
とはいっても「システムを構築する人」がいなくてはシステム作れないですし、業務だってどーともならないかもしれません。卵が先か鶏が先か、みたいな話です。
他の人も言っているかも知れませんが、「腕の良いプログラマ」と「普通のプログラマ」の作るものがどうちがうのか？ どんな付加価値があるのか？ そういったことを数値で証明する必要があるのではないでしょうか。お金に近い人は数字が大好きです。
そこでまた難しいのですが、それには正確で的を得た「計測」の作業が必要なはずです。
しかし悲しいかな、私の働く会社も同じく計測に使うコストや工数が捻出できません。必要性も感じていません。
悲しいです。
私は一所懸命働くエンジニアにやりがいのある仕事を良い条件で楽しくやってもらうことが今の仕事の目標の一つだと思っています。
でも本当に難しいです。
悩みがつきません。
2008年1月10日木曜日
[memo]James Gosling氏がAdobe Flash・Flex・AIRを語る
James Gosling氏がAdobe Flash・Flex・AIRを語る
http://www.infoq.com/jp/news/2008/01/gosling-on-flash
おもしろい記事だったのでメモ。
そして彼はFlexが2008年の初旬にリリースされる予定である一方、JavaFXは出荷される予定がないことを自身の考えとして述べた。
何かもっといい向上が成されるのであればどうぞ出荷してください。
それをいっちゃ。。。
http://www.infoq.com/jp/news/2008/01/gosling-on-flash
おもしろい記事だったのでメモ。
そして彼はFlexが2008年の初旬にリリースされる予定である一方、JavaFXは出荷される予定がないことを自身の考えとして述べた。
何かもっといい向上が成されるのであればどうぞ出荷してください。
それをいっちゃ。。。
登録:
投稿 (Atom)