2007/05/01
【信頼されるSEへの道 第30号】オフショアとSEマインド(2)
■□■□■□■□■□■□■□■□■□■□■□■□■□■□■□■□■□■□ ┌───────────────────────────── 2007.5.1 │ │ 信頼されるSEへの道 〜成長し続けるために〜 第30号 │ │ http://blog.livedoor.jp/brave33/ │ │ メルマガインデックス−過去のメルマガ一覧 │ ⇒ http://blog.livedoor.jp/brave33/archives/50529551.html └────────────────────────────────── ■□■□■□■□■□■□■□■□■□■□■□■□■□■□■□■□■□■□ こんにちは、MICK です。 GWですが、皆さんはどのように過ごしていらっしゃいますか？ 連休というのは、気づきや何かしらの転換点となるきっかけが多いような 気がします。 普段、仕事に忙殺されてしまっている方も、ゆっくりと自分や自分の会社、 自信のキャリアプランなど、仕事から離れて本当の意味で冷静な目で見られ るいい時期だとも思います。 右も左も分からない状態での判断は、非常によくないと思います。 自分は重大な決断を行うときは、冷静さがあるときに行うよう心がけてます。 さて、前回はオフショアベンダーの対応方法などについてお伝えしました。 【第29号】オフショアとSEマインド(1) →http://blog.mag2.com/m/log/0000208094/108462028.html 今回は、我々エンドユーザと直接接するSEはどうすべきか？ という内容について、お伝えしたいと思います。 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ <PR> 転職希望、自分の市場価値を知りたい方に朗報です！！ 「信頼されるSEへの道」が自信をもって、エージェントを推薦します ⇒ http://blog.mag2.com/m/log/0000208094/107875439.html ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 【信頼されるSEへの道 第30号】オフショアとSEマインド(2) ...先週からの続きです。 ●ポジションが異なる つまり、我々と求められている職種、ポジションが明らかに違うわけです。 では、我々はどんなことを求められているのでしょうか？ 最初の言葉を思い出してください。 「我々SEはプロジェクトを成功させることが目標」 よくも悪くも、プロジェクトの成否が最終目標であったはずです。 あいまいなこと、リスクが高いわりに効果が期待できないもの、 そうしたいが、納期、コスト、メンテナンス性の問題で実施できないもの、 といったような判断基準があるはずです。 つまり、問題の芽は先に摘んで、納期、コスト、品質など、ビジネスの要望 にあったものを最終納品する立場なのです。 そのためには、顧客の業務や意図を理解し、それにあったサービス、ソフト ウェアを納品する必要があるわけです。 バグが出れば、モジュール修正だけでなく、データ修正、テスト、リリース 計画など、サービス全体のレベルを上げていく必要があるわけです。 理想論で言えば、自分が担当した機能じゃないから、知らないではなく、 全体に責任を負うこと、またはチーム、ベンダー全体として、そのサービス レベルを上げていく必要があるのです。 ●顧客の視点で考えろ！ よく訳のわからない個人的な説明やプログラムの説明をぐだぐだ始める人も 多いのですが、自分はここでよくこう言います。 「それで、エンドユーザわかる？」 「そんなんで、ユーザ使える？」 この状態で、的を得た反論が返ってくることはほとんどありません。 ほとんどは「すいません、直します」と帰っていきます。 この意識レベルを変えていかないと、いつまで経ってもITエンジニアって なに言ってるか分からないと、評価されてしまうわけです。 ●プロマネや上級SEは すくなくとも、プロマネや上級SEは、それらを成果として判断されるわけ です。 つまり、結果が全てという認識です。 がんばったけど、駄目だったね、というのは評価としては悪いとなります。 逆にほとんど仕事をしなくても、成果をあげることができれば、評価が 上がることになります。実際はそんなことはほとんどありませんが。 それを考えられると、エンジニアとして一回りも二回りも成長できるような 気がします。 プロフェッショナルとしての厳しさを自ら認識することに、他ならないから です。 こういう仕事なんで、言い訳はしようと思えばいくらでもできます。 ですが、結果責任を負うことを考え、 ・自分はどうしなければいけないのか？ ・今、どうすべきか？ そういったことを考えられるエンジニアが増えてくれれば、と常日頃、 思っています。 「小さいやつだな！」 自分はくれぐれもこう言われることがないよう、ことあるごとに自分を 見つめ直すようにしています。 ●言った、言わない よく話にでる、「言われてないから知りません」「言った、言わない」 となるパターンでは、不信感があったり、プロジェクトの成果そのものが 上がっていない場合が非常に多い気がします。 ラッキーなのか、やり方が違うのか、いま一つ分かっていないのですが、 自分が要件定義などを担当して、いままで一度も「言った、言わない」で もめたことがありません。 自信を持っていうのですが、通常「言った、言わない」と、仕様をコミット する作業は別物です。 現時点で、その仕様をコミットできる基本設計か、予算的に見合わない 可能性があるか、などはその場で即答すべきことです。 自分は、できそうもないものは、その場で可能性がほとんどない、と認識 するようはっきりと説明するようにしています。 ●顧客とはフェアに言い合えるようになりたい また、安い額で受注させて、無理やり、見積もりより多くの仕様を詰め 込ませようとする会社もあります。 たしかに客は客ですが、フェアな関係でないといいシステムができあがる こともありません。 どっちかが極端に偉かったり、上下関係が出来てしまうと、その時点で システムそのものが駄目な方向に向かうものだと思い、気をつけるように しています。 ●終わりに 今回は「オフショアとSEマインド(2)」と題して、SEマインドの礎について、 お伝えしました。 常に顧客との関係は人間的なものが多く、実際のシステム構築の難しさは システムそのものの構築よりも、人間関係の信頼の構築の方が難しいと 感じることが多いと思います。 そうした意味でも、システムは人間がつかうもの、人間の業務を効率化 させる手段であり、目的は別だということを絶対に忘れないようにしたい ところです。 さて次回は、、、まだ考えていません。 面白い記事や出来事があれば、そこからお届けしたいと考えてます。 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ ご感想やご希望などありましたら、以下までメールください。 なにぶん忙しいので、全てに返信はできないかもしれませんが、 全てのメールに目を通すようにします。 また、ブログを準備しましたので気軽にコメントをお寄せください。 ※セミナー講師、新人研修の講師、コンサルティング依頼などについても、 以下までメールでお願いします。 ⇒ メールアドレス： info@yscre.com ⇒ ブログ： http://blog.livedoor.jp/brave33/ ⇒ メルマガインデックス： http://blog.livedoor.jp/brave33/archives/50529551.html ⇒ 登録・解除はこちら http://www.mag2.com/m/0000208094.html SEの方々にとっても、できるだけ役に立つ情報をお届けします。 ご友人や仕事仲間の方にも、ご紹介いただけたら、と思います。 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ メルマガインデックス−過去のメルマガ一覧 ⇒ http://blog.livedoor.jp/brave33/archives/50529551.html 【第1号】技術系SEの勘違い 2006.09.19 【第2号】本当に必要な新人教育 2006.09.26 【第3号】新人のときにおかれる環境 2006.10.03 【第4号】SEの常識？社会人の常識？ 2006.10.10 【第5号】信頼される上司 2006.10.17 【第6号】もう一つの組織 2006.10.24 【第7号】積極的な思考 2006.10.31 【第8号】メンバー同士の行き違い 2006.11.07 【第9号】プロジェクトのチェックポイント(1) 2006.11.14 【第10号】プロジェクトのチェックポイント(2) 2006.11.21 【第11号】プロジェクトのチェックポイント(3) 2006.11.28 【第12号】プロジェクトのチェックポイント(4) 2006.12.05 【第13号】プロジェクトのチェックポイント(5) 2006.12.12 【第14号】デバッグの方法・考え方 2006.12.19 【第15号】一年を振り返る 2006.12.26 【第16号】要件定義の重要性 2007.01.09 【第17号】要件定義から要求開発へ 2007.01.16 【第18号】要求開発−要求の分類方法 2007.01.30 【第19号】要求開発−各要求の関係 2007.02.06 【第20号】アジャイルに見る理想の開発(1) 2007.02.13 【第21号】アジャイルに見る理想の開発(2) 2007.02.20 【第22号】信頼できるパートナー(1) 2007.02.27 【第23号】信頼できるパートナー(2) 2007.03.06 【第24号】Network World Conference 2007 Spring 2007.03.13 【第25号】セキュリティ監査とポリシー(1) 2007.03.20 【第26号】セキュリティ監査とポリシー(2) 2007.03.27 【第27号】セキュリティ監査とポリシー(3) 2007.04.03 【第28号】セキュリティ監査とポリシー(4) 2007.04.10 【第29号】オフショアとSEマインド(1) 2007.04.17 【第30号】オフショアとSEマインド(2) 2007.05.01 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ ＜お薦め書籍＞ フラット化する世界(上) トーマス・フリードマン (著), 伏見 威蕃 (翻訳) →http://www.amazon.co.jp/gp/product/4532312795/000jp-22 フラット化する世界(下) トーマス・フリードマン (著), 伏見 威蕃 (翻訳) →http://www.amazon.co.jp/gp/product/4532312809/000jp-22 豆蔵セミナーライブオンテキスト(1) わかるオブジェクト指向 (単行本) 山田 隆太 (著) →http://www.amazon.co.jp/gp/product/4774124605/000jp-22 要求開発−価値ある要求を導き出すプロセスとモデリング 山岸 耕二 (著), 安井 昌男 (著), 萩本 順三 (著), 河野 正幸 (著), 野田 伊佐夫 (著), 平鍋 健児 (著), 細川 努 (著), 依田 智夫 (著), ［要求開発アライアンス］ →http://www.amazon.co.jp/gp/product/4822282686/000jp-22 NYPD No.1ネゴシエーター最強の交渉術 ドミニク・J. ミシーノ (著), ジム デフェリス (著), 木下 真裕子 (翻訳) →http://www.amazon.co.jp/gp/product/4894511851/000jp-22 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 日本一キーストロークの短いアドレス！！ ↓アドレスを短く簡単にします。↓ ⇒ http://000.jp/ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ .
