［後編］人とITでサービスを極める 21世紀型のビジネス確立へ
［後編］人とITでサービスを極める 21世紀型のビジネス確立へ りそなホールディングス 取締役兼代表執行役会長 細谷 英二氏 顧客視点なら全体最適になる 顧客視点に立つからこそ、顧客の接点である部門ごとに最適化されてきた、といった反論も聞こえてきそうですが。 それは、部門ごとに顧客層が全く違うと考えるからです。ところが現実の顧客は、例えばオーナー経営者であれば、個人部門と法人部門の両方にとっての顧客です。つまり、その顧客についての情報を共有化できるシステムが必要です。ですから縦割りの壁を破って、全体最適のシステムを構築できないといけません。情報を共有化すれば、システムの構築コストも下がるわけです。 全体の最適化により、効率化と顧客満足の両立が図れるというわけですね。 もちろん、システムだけでカバ ーできるわけではありません。顧客は経営課題や生活設計についても、本当に信頼できる人、金融知力の
“営業というもの”の理解がSEを変える
これまで数回にわたって、SEの販売・提案活動に関することを書いた。現役時代からずっと、日本の「SEのあり方」と企業の「SEの扱い方」に強い疑問を感じていたからである。 事実、現在も多くのSEが「営業とSEの関係」で悩んでいる。特にSEが販売・提案活動に参画した時の悩みは大きい。筆者の時代もそうだったが、現在もSEからその類のグチを結構聞く。例えば「営業は売ればよいと思っているからSEがシステム開発で苦労する」とか「営業は技術が分かっていないから後でSEが困る」といった話だ。中には「実際は我々SEが売っているのに、営業はいい格好ばかりする」と言うSEさえいる。 このような声が出てくるのは、きっとSEと営業との関係がうまくいっていないからだと思う。IT企業にとっては深刻な問題である。生産性が下がるし、下手をするとお客様に迷惑をかけかねない。以下、読者の方への問題提起も含め、「SEと営業との関係
かの報告書から何を学ぶか - 虎塚
みずほ銀行 : 2011年3月のシステム障害について みずほ銀行さんの報告書を読みました。考えたことをメモします。 関連: http://d.hatena.ne.jp/torazuka/20110319/mizuho （特定の会社の話題に関するチラ裏なので、続きは折りたたんでみる） ・・・ これほど胸が詰まる資料もありません。いったいどうすれば、止めるべきでないシステムを動かし続けることができるのだろうと思います。報告書を読んでいると、その日が来るのは遠く思えて、悲しくなってきます。 やるべきだと分かっていても手をつけていないこと、緊急度の高いタスクにおされてプライオリティを下げた重要度の高いタスク。そんなものは日常業務で山ほどあります。その積み重ねの延長線上で今回の障害が起きたと考えると、他人事とは思えません。 地続きのITの世界で働く身としては、やはり何か教訓を拾い上げなければならない
IT業界ではなぜ「うつ病」が多いのか 過酷な労働で衰弱していく技術者たち | JBpress (ジェイビープレス)
当社のマネジャーミーティングで賛否両論の議題があるので私の意見を聞きたいという。「あるプロジェクトに関わっている技術者が、クライアントから夜間の作業を依頼された。今日、勤務することになっているのだが、作業をさせていいものだろうか」というのだ。 管理部門からは、「契約では就業時間（9～18時）内の勤務となっている。22～8時の夜間に作業するのは、契約違反である。もし何か問題が起きたら、会社としては責任を負えない」と言う。 その心配はよく分かる。実はその技術者はかつて働きすぎが原因で、軽度のうつ病を発症したことがあったのだ。 技術部門は、私の判断に任せるという。「本人に確認したら、このプロジェクトでは断るわけにはいかないので、一番年少の自分が出ると言っています」とのことだった。 営業部門は、作業に行くべきだと考えているようだ。「夜間の作業は他社では普通に行われていることです。日常茶飯事です。こ
こだわりのある職人プログラマーほど、無駄なコードを少なくしたいものという事実を理解してほしい - 達人プログラマーを目指して
ちょっと興味深いエントリが目に留まりました。「プログラミングへのこだわり」を方向づける: 設計者の発言基本的に、この方自身もプログラマーや開発者をされているようですし、他のエントリを読んでも「プログラマーの地位向上をすべき」ということで、私にとっても非常に共感することをおっしゃっているのです。それでも、ちょっとこのエントリの内容については疑問に思うところがあったので、勝手ながら私の意見を書かせていただきたいと思います。 業務システムの生産性や保守性を高めるための基本は「コードを１行でも減らす」である。なぜなら、コーディングとこれにともなうテスティングこそが、開発作業の中でもっとも人手のかかる作業だからだ。個別案件においては、良いコードだろうが悪いコードだろうが少なければ少ないほどよい。 これは、まさにおっしゃる通りですね。もちろん、可読性ということもあるため、厳密には最少のコードが最良とい
「プログラミングへのこだわり」を方向づける - 設計者の発言
業務システムの生産性や保守性を高めるための基本は「コードを１行でも減らす」である。なぜなら、コーディングとこれにともなうテスティングこそが、開発作業の中でもっとも人手のかかる作業だからだ。個別案件においては、良いコードだろうが悪いコードだろうが少なければ少ないほどよい。 いっぽう、そんな方針と明らかにそぐわない人たちがいる。彼らはプログラミングそのものに強いこだわりを持っていて、より良いコードをより多く生み出すことに生きがいを感じる人たちだ。チャーミングな彼らの姿を個別案件の開発現場で見るたびに、私はキャスティングの失敗事例を見る思いがして切なくなる。 それは全国チェーンの外食店の厨房に、新しい料理を生み出すことに情熱を覚える若者が働いているようなものだ。彼がどう工夫しても、全国一律の料理メニューを改変するのは難しいだろう。そんな才能あふれた若者には、本部の企画部門で働いてもらったほうがい
みずほ銀行の3月のシステム障害の調査報告pdfが超面白いのでマはみんな読むべき « おれせん。
みずほ銀行：システム障害に関するお知らせおよびお問い合わせ先 http://www.mizuhobank.co.jp/oshirase.html 中段の「システム障害特別調査委員会の調査報告書について」のリンク 直リンクはこれ（5/20掲載） 前半しばらく「グダグダ鬱陶しい能書き」が続きますが9ページ目の「3. 本障害発生以前のシステム障害及び対応状況」あたりからギアが入って、11ページ目の「4. 本障害の発生事実」からトップギアというかちょっとしたヘル絵図であります。 ……ああ、その前にここを引用しておこうかな、4-5ページの「2. システムの概況」内「(3) 次期システムの概要」箇所。 (3) 次期システムの概要 次期システムについて、ビジネス環境の急激な変化に対応すべく、肥大化・複雑化した現行システムを新たなシステムとして再構築するために、2004 年から MHFG を中心に検討
“お客様というもの”の理解がSEを変える
一般にIT企業のSEには、第一線で働くSEとバックエンドで技術的な仕事のみを受け持つSEがいる。前者は受注したシステムの開発・保守の仕事や販売・提案の仕事を行っている。後者は大手IT企業に多い。「技術サポートグループ」などと称される部署で、第一線のSEを相手に技術面で支援する仕事をしている。 SEの人数は、前者の第一線で働くSEの方が圧倒的に多い。筆者がこの連載や雑誌のコラムなどでSEについて色々書いているのはすべて第一線のSEについてである。筆者が第一線のSEに向けて書いている目的は、SEの世界は長年「技術偏重」「受身意識」「ビジネス意識の薄さ」など多数の問題を抱えているが、その変革を読者の方々へ訴えるためである。今回もその趣旨で、第一線のSEについて別の視点で書いてみたい。 できるSEは「技術力+しっかりした“顧客観”」を持つ 筆者はSE時代に数多くの顧客を担当し、様々なプロジェクトを
フレクトのクラウドBlog: セールスフォース、Google、AmazonのPaaSの比較とSIer視点からの印象
最近、Amazon Beanstalkが発表されて、PaaS領域が一段と盛り上がってきました。 業務系に強いForce.com、ソーシャルアプリなどコンシューマ系サービスに強いGoogle App Engineあたりが有名でしたが、最近は選択肢がかなり増えました。 この記事を書いている最中にもちょうど以下のような記事がでていて、PaaSに対する注目度が高いことがうかがえます。 http://www.publickey1.jp/blog/11/google_app_engine_paas.html http://www.publickey1.jp/blog/11/_java_paas.html 上記の記事でだいたいよいところ、難しいところがまとまっているのですが、今日はGoogle App Engine、Force.com、AWSのサービス、それぞれ実サービスの運用や受託開発で使った経験や、
退職しました - yukungのブログ
本日2011年4月30日を持って、株式会社インテックを退職しました。 振り返ると、2005年４月１日に新卒で入社して、それから今日で６年間と１ヶ月です。６年間、SIerに所属しながら、主に金融領域の顧客をターゲットとして、顧客先に常駐して開発・保守作業を行うといった、所謂エンタープライズSI業界のど真ん中で過ごしてきました。最初の２年弱は、汎用機開発のプロジェクトで所謂COBOLerとして、その後転身を図り、JavaによるWeb開発を５年弱、経験しました。 キャリアとしても、SI業界の不文律、「PG→SE→PM」という出世魚キャリアを邁進中でした。5年目以降からは、リーダー業務やシステム提案などコンサルめいたこと、エンジニアながらパートナー会社の方との採用面談や外注管理などの営業サポートなど、多岐に渡る業務に携わって経験を積むことができました。こういった色々な経験のチャンスを貰えたことで、
システムエンジニア生き残りの極意 エピソード０ コボラーの復習 - カレーなる辛口Javaな加齢日記
http://slashdot.jp/developers/article.pl?sid=11/03/29/0047205 経由 この四月からIT業界に入った不幸な君たちへ． 是非とも読んでおくべき伝説の迷記事がこれだ． 「実はオブジェクト指向ってしっくりこないんです！」http://el.jibun.atmarkit.co.jp/minagawa/2010/04/post-ebc4.html とくにコメント欄が必見 そして，それに続く第二弾がコレだ． Press Enter 「高慢と偏見」 http://el.jibun.atmarkit.co.jp/pressenter/all_entrylist.html http://el.jibun.atmarkit.co.jp/pressenter/2010/11/1-828a.html http://el.jibun.atmarkit.co.
バッチ処理の開始チェックは大事、ということか - 虎塚
みずほ銀行さんのシステム障害という悲しい事件が騒がれています。 みずほ銀行は15日未明、バッチ処理が予定時間までに終了しなかった。原因について同行は「東京都内の特定支店の特定口座への振り込みが想定以上の件数に上った」と説明しており、その段階でシステムが動かなくなった可能性がある。18日夜の会見で西堀利頭取は「一部の口座では、データ容量の上限設定が適切な数値になっていなかった」と人為ミスの可能性に言及している。 テクノロジー : 日経電子版 ・・・ちょっと何いってるかわかりません、というカンジだし、記事へのブックマークコメントが興味深いので、考えたことをメモしておきます。（特定の会社の話題に関するチラ裏なので、続きは折りたたんでみる） 開発方法論は無関係のハズ ウォーターフォールで開発してるからこうなった、というネタにマジレスすると、それは無関係でしょう。 たしかに、派生開発したシステムに対
SI業界で技術者が軽視されてしまうのは何故なのか - GoTheDistance
日本のSI業界でこそ、専門の技術者の必要性がもっと見直されるべきではないのか？ - 達人プログラマーを目指してを拝読しました。この手の議論は定期的に出てくる根の深い問題でありまして、1億年と2000年前から多くの方に言及されています。しかし、それほど大きい問題であるということです。一概にああしろこうしろで片付く問題ではありません。 色々論点はありますが、「技術を売って社会貢献している業態なのに、一番重要な技術者を軽視するってどういうこと？」という１点に集約でき、上記エントリの主題も同じです。技術onlyの専門家の存在が認められないのが問題だと。しかしですね、「技術者そのものを売ってるんだから、軽視云々を言ってもどうしようも出来ない」という果てしない平行線を辿っていることが見えているでしょうか？ブルーハーツの「弱いものたちが夕暮れ 更に弱い者を叩く」というフレーズが思い起こされます。 技術者
SEに必要なスキル、いらないスキル - スーパーSEへの道
1961年栃木県足利市生まれ。株式会社ヤザワ取締役社長、グレープシティ株式会社アドバイザリースタッフ、電脳ライター友の会会長兼事務局長。大手電気メーカーでパソコンの製造、ソフトハウスでプログラミングを経験し、現在はアプリケーションの開発と販売、および.NET対応コンポーネントのマーケティングに従事している。 本業のかたわら、書籍や雑誌記事の執筆活動、セミナーやコンファレンスにおける講演活動も精力的に行っている。代表作に『プログラムはなぜ動くか』（日経BP社刊）がある。 お客様の満足を何よりも大切にする自称ソフトウエア芸人。 今回から「スーパーSEに求められるスキルとは何か？」をテーマに語っていただきます。まず、その中でも、技術革新が日進月歩で進むIT業界で生き抜くための「テクニカルスキル」についてうかがいました。 まずは、ざざっとSEに必要なスキルを挙げてみましょう。それらをまとめると、「
2011年版「あえて今、『システム内製』の勧め」
50歳を過ぎたせいかどうか、元々しっかりしているとは言えなかった記憶力が怪しくなってきた。 つい先日も「はじめまして」と言いながら名刺を差し出すと、「以前お目にかかっていますよ」と笑われてしまった。仕事柄、一度会った人のことは忘れないように心掛けているのだが、これはまずい。 原稿を書いていても、途中で「同じことを前に書いたのではないか」「この逸話はすでに使ったはず」と気になってくる。しかも、いつ、どこに書いたのかをなかなか思い出せない。奥田英朗氏の小説集『空中ブランコ』に、同じことを書いてしまうのではないかと悩む女流作家が登場する。あれほどひどくはないが、似た心配をしてしまう。 題名でお分かりかと思うが、この原稿で書きたいのは、自社で利用する情報システムはできれば内製したほうがよい、ということだ。同じ主張を何度か書いた記憶がある。気になっているのは、次のような言い回しに関してである。 「ク
Javaプログラマであるかを見分ける10の質問-回答編 - やさしいデスマーチ
想定を超えた反応がありましたので、予定はしていなかった回答編をお送りします。ですが、正確な解答を書いても面白くないので、これをネタに面談をした場合に、自分ならどんなポイントを持って選考するかをまとめてみました。 はじめに このエントリーの質問の意図は「優れたJavaプログラマ」を見つける事ではありません。「最低限のスキルを持った戦力が欲しい」という状況です。したがって、優れた指摘をしてくるのであれば超したことありません。設問について議論が発生するならば、この設問を投げる必要がなかったということです。 Javaを詳しく知っている人からすれば間違いでは？曖昧な質問では？と感じる設問があるのは確かです。しかし、優秀な人をテストしたい訳ではないのです。したがって、正確性とか厳密性については求めません。「だいたいあっている」ならば前提条件である「中堅プログラマの補充」の条件を満たすからです。 中堅プ
Javaプログラマであるかを見分ける10の質問 - やさしいデスマーチ
元ネタはこちらですが、「優れたJavaプログラマ」を見分ける質問ではありません*1。次のような状況を想定してください。 受託業務を中心にしている弊社は、Javaで業務系ウェブアプリケーションの開発を行う事になりました。しかし社内のリソースを使うにも１−２名足らない事が見積もりから解っています。そこで、中堅エンジニアを1−2名募集することになりました。正社員か派遣かは問いませんが、経験が３年程度の中堅プログラマが必要です。同等またはそれ以上のスキルを持つ正社員がプロジェクトを牽引しますが、ゼロから教えながら教育することはできないので、必要最低限のスキルを持っていることが条件になります。 こんな状況を想定して、面接の質問を考えてみました。経験が３年程度あれば、問題なく答えられるはずです*2。尚、質問はホーム言語がJavaである前提です。 下記質問にそれぞれ50文字以内を目安に簡単に説明すること
仕事の種類を絞り、流れを作りたい - 虎塚
個人的で未熟な呟きだけど、忘れないようにメモる。 先日、回されそうになった仕事をはじめて断って、先輩にポカーンとされるなどした。 若手は好き嫌いをいう前に勉強だと思って何でもやれ 少しでも業務の幅を広げるのが若手の仕事 仕事は断ったら負け この手の話を自分はけっこう信奉している。なので、いつもは基本的に何でも引き受けたがるから、先輩は「なんだこいつ急に」って思ったかもしれない。 じつは、この半年ほど自分のアサインのされ方に焦りを感じているので、ちょっと変えようとしている。 いま、インフラ実務、アプリ実装、チームのまとめ、社内プロセス開発、技術調査、教育などをしていて、バラバラで、広すぎることに悩んでる（優先順位については、きいても指示はなく、自己責任…）。こうなった原因は、単に人が足りない現実と、若手のうちにいろいろな業務をさせてやろうという先輩上司の親心（？）の両方があると思う。 ツラい
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
エンジニアtype 技術者のキャリアを考えるWebマガジン - 転職＠type
tdtshのブログ» システム開発・構築の方々はシステム運用を理解してあげてください