情シ部は意識の改革や戦略的な人事をやらなくてよいのか
情シ部が真に企業の情報戦略部門になるためには少なくとも解決しなければならないものが三つある。それは「技術の空洞化の問題」「情シ部員の意識の問題」「戦略的人事の問題」である---と前回，主張した。そして，そのうちの一つ“技術の空洞化”に対する意見を述べた。読者の方々からもたくさんコメントを頂いた。さて「技術の空洞化」の次の問題が「情シ部員の意識の問題」と「戦略的人事の問題」である。今回は，この二つの問題を取り上げる。 部員の意識改革を図れ 情シ部が企業の情報戦略を立てて全社の情報化を推進するには，情シ部の人にそれなりの自覚が必要である。自覚だけでなく，営業部門や管理部門，生産部門など利用部門のシステム化を適切に指導・リードし相談相手になることも重要である。システム開発や保守や運用にかかわる諸々の事項をしっかり行なうことはもちろんである。 歴史的に見ると，企業がコンピュータを使い始めた40～5
第44回 ビジネス創造の障害となったシステム部
企業のシステム部は，現場部門から出されるシステム化要求の背景や業務の本質を十分に理解しなければならない。そうしないと，企業に変革をもたらす有効なツールとしてのIT（情報技術）が宝の持ち腐れになる。しかし往々にして，システム部は既存システムの手直しや機能追加，クレームなどの対応に追われ，現場が何を考えているのかに無関心になりがちだ。システム部を含めた企業の全員が情報システム化の狙いや目標を共有すべきである。 本記事は日経コンピュータの連載をほぼそのまま再掲したものです。初出から数年が経過しており現在とは状況が異なる部分もありますが，この記事で焦点を当てたITマネジメントの本質は今でも変わりません。 首都圏に3店舗を展開する都市型百貨店を営むA企業グループの年度計画検討会議での出来事だ。システム部のY部長が，役員・部長を前に来年度のシステム部の方針を説明した。 「当社は，情報通信技術の新しい潮
【連載】社長のアタマ (3) すべてのエンジニアはITアーキテクトたれ!! (2) | エンタープライズ | マイコミジャーナル
豆蔵の山岸社長は、企業において業務とITの切り分けが難しくなっている今日、工学的手法を用いて業務全体のアーキテクチャを描いていくことが重要であり、それを実現するのがITアーキテクトだと語っています。今回は、「ITアーキテクトは具体的にどんな役割を果たすべきか」「良いITアーキテクトはどのようにして育てるべきか」について、山岸社長の考えをお聞きしました。 ユーザーとパートナーの"あるべき姿" 豆蔵代表取締役社長 山岸耕二氏(撮影:永山昌克) ユーザー企業のIT部門やベンダーやSIerといったパートナー企業の今後の姿はどのようなもので、その中で、ITアーキテクトはどんな役割を果たしていくべきなのだろうか。 山岸氏は、「ユーザー企業のIT部門は今後、自社のIT戦略を立案するという役割が高まっていく。一方、パートナー企業は、単にシステムの開発・実装を請け負うだけでなく、戦略の実行をサポートすると
「ITエンジニアは職人気質を取り戻すべき」
「ソフトウェア開発の匠」。このタイトルには、ソフトウェアエンジニアは現代の匠（たくみ）になるべきだという筆者の思いを表現している。現在のソフトウェア開発は、残念ながら多くの人が過去の職人気質（かたぎ）を捨て去り、サラリーマン化しすぎている。ビジネスの価値を高める最適なソフトウェア開発の姿について、自ら描くことをしていない。 しかし、ただ旧来の職人気質を取り戻すだけでは駄目なのである。ヨーロッパのマイスター（匠）のように尊敬されるためには、ビジネスを知り、ビジネス価値を高める職種になることが必要である。それが、ITエンジニアの目指すべき匠である。そのような人材像を「ソフトウェア開発の匠」とし、本連載では、そこに近づくための考え方や解決法を読者にお伝えできればと思う。 まず第1巻（連載第１～2回）では、現在のソフトウェア開発手法が未熟であることを、さまざまな問題を例に述べる。そして、これらの問
技術を超えたSEになれ
前々回，筆者は「SEマネジャの中には『SEは技術屋だ。俺たちは技術の仕事だけすればよい』と考えているように見える人が少なくないが，それではダメだ。だから，営業担当者や経営者から『SEはビジネスに無関心過ぎる。何を考えているのか分からない』と見られるんだ云々」と述べた。きっとSEマネジャの中には筆者の意見に賛同する人や異論がある人などいろんなSEマネジャがいるはずだ。それは筆者が考えるに，そのSEマネジャが「IT企業の中のSEのあり方やSEの仕事をどう考えるか」によると思う。そこで今回は「IT企業の中でのSEのあり方」について考えてみたいと思う。 筆者は第一線のSEの任務は「会社のビジネス目標の達成に貢献し，顧客の満足度を向上する」ことであると考えている。そのためにSEという職種がある。これが筆者の考えるSEのあり方の原点である。もちろん，SEの仕事はIT企業の性格，ハードウエア・メーカー，
ITエンジニアは、彼女に何をしてあげられるか：＠IT自分戦略研究所の「おすすめエンジニアライフ」：エンジニアライフ
本音が語れるエンジニア参加型メディア「＠IT自分戦略研究所 エンジニアライフ」。日々、ITエンジニアの「生の声」を公開している。 ここでは、＠IT自分戦略研究所 編集部おすすめのコラムを紹介する。あなたのエンジニアとしての成長に役立つ内容であれば幸いだ。 ■結婚は人生の墓場か？ 某メーカー系グループ企業に勤める中堅ITエンジニア、ホリススム氏の新コラム「結婚は人生の墓場となり得るのか？」。「ITエンジニアにとっての結婚」をテーマに、赤裸々に語る。 第1回は結婚前のエピソードから。「ITエンジニアは彼女に何をしてあげられるか？」と悩むホリ氏の目に飛び込んできたのは、新しくできるレジャーランドのシステム構築仕様書だった。 ■資格の死角 Web系プログラマ兼GNU/Linux系技術者、早川勇太氏の「若人視点」。今回は、資格にまつわるコラムだ。 学生時代は、資格は「アピールになる」「単位になる」「
滋賀限定、残業なし、社内SE。そりゃ苦戦するでしょう
滋賀限定、残業なし、社内SE。そりゃ苦戦するでしょう：転職活動、本当にあったこんなこと（20）（1/2 ページ） 多くのITエンジニアにとって「転職」とは非日常のもので、そこには思いがけない事例の数々がある。転職活動におけるさまざまな危険を紹介し、回避方法を考える。 皆さんが転職を考える場合、いろいろな条件を検討することでしょう。勤務地、年収、仕事内容、企業規模……。優先順位を付けがたいものも中にはあろうかと思います。 しかし、すべての条件がかなう転職先に巡り合うことは難しいのが実情です。すぐに転職をしたい場合、長期的にじっくりリサーチしながら転職したい場合、それぞれで状況は異なってきますが、絞り込みの方法を誤ると、どちらにしても苦戦するかもしれません。 今回は、転職活動の「落としどころ」という点から、事例を踏まえてお話しします。皆さんの参考になれば幸いです。 複数の案件に追われる毎日。こ
エンジニア名乗るなら最低限がプログラム : インフラエンジニアに成る
ネットワークやるならプログラムも当然やる。 結局、究極的に技術力を追求するしかない という結論を出してしまうとこうなる。 もちろん、下流工程にいる限りは必須ではない。 下流工程にいるエンジニアから次を考えると プログラムも頭にいれる必要が出てくるということ。 もっというなら、プログラムは 最低限必要な技術力のひとつにしか過ぎない。 IT業界に必要な技術とはなんだろうか。 私は以下の3つだと思っている。 ・ハードウェア ・ソフトウェア ・ネットワーク この3つの組み合わせによってIT業界の職が決まる。 Web系ならソフトウェア＋ネットワーク。 組み込み系ならハードウェア＋ソフトウェア。 場合によっては＋ネットワーク。 サーバならネットワーク＋ソフトウェア。 できればハードの知識があるとなおよい。 そうなると話は簡単だ。 全部できるのが一番いいに決まっている。 そしてこのいずれかに偏ることによ
SEは美しいドキュメントを作れ
SEは仕事上，開発計画書，提案書，システムの鳥瞰図や概要図，業務フロー，業務分担図などさまざまな資料を作る。打合わせ資料，進捗報告書やトラブル報告書などの類もある。そしてそれをお客様に提示する。そんな時，お客様から「この資料は良くまとまっているね」，「この図は上手いですね」，「凄く分りやすいです」などと言っていただけるといろいろなメリットがある。 ドキュメントは強力なコミュニケーション・ツール まず，お客様に「このSEはやるな！」と思っていただける。すると信頼を得やすい。新規顧客だとその瞬間に自分を売り込める。その効果は絶大である。 次に，顧客に自分が言いたいこと，訴えたいことをより的確に伝えることができる。すると顧客との間での，勘違いや早とちりなどの誤解が大幅に減る。システムの開発範囲や要件の範囲などの打合わせでは，その効果は少なくない。 即ち，ドキュメント力はSEにとっては強力なコミュ
私だってもう少し「技術者」でいたかった ― ＠IT自分戦略研究所
私だってもう少し「技術者」でいたかった：ITアーキテクトが見た、現場のメンタルヘルス（8）（1/2 ページ） 常にコンピュータ並みの正確さを要求されるITエンジニアたち。しかし、ITエンジニアを取り巻く環境自体に、「脳を乱す」原因が隠れているという……。ITアーキテクトが贈る、疲れたITエンジニアへの処方せん。 ITエンジニアとしてキャリアを積んでくると、仕事の内容は、一担当者のものからリーダーのものに変わってくると思います。 「自分はコンピュータが好きでIT業界に入った。人の管理はややこしいからしたくない。でも、会社や体制がそれを許してくれない」。そう思いながら仕事をしているITエンジニアは多いのではないでしょうか。 今回は、仕事の変化に合わせて、自分のメンタルヘルスをうまく維持していく方法を考えてみましょう。 「駄目」「できません」しかいわない部下 あるITサービス会社に勤めるグループ
「やらされ仕事」では成長は止まってしまう：ＩＴ業界のマーケティングを問う：オルタナティブ・ブログ
「仕事は自ら作るもの」とはよく言いますが、実際にはほとんどの仕事は与えられるものだと思います。上司から与えられる仕事、お客様から与えられる仕事など、仕事のでもとは様々ですが、やりかたは自ら考えるとしても、その内容は他者から命じられるものだと思います。 その一方で、仕事をどのようにとらえるかは自分自身で決めることができます。与えられたことを単純にこなすだけの仕事とするか、それともその中で自ら考えて内容を充実させていくか、それは当人の自由だと思います。いろいろ工夫した結果が評価されるかどうかは、上司やお客様によりますが、その過程での経験は、評価と関係なく力として蓄積されます。 いわゆる「やっつけ仕事」、「やらされ仕事」として仕事をしている場合には、仕事の過程で得るものはありません。若干の知識や、なんとなくこなしたという実績は残るかも知れませんが、簡単に言ってしまうと、「誰か他の人でもできること
「プログラマ35歳定年説」を思い起こさせるIPAの調査結果 ― ＠IT
情報処理推進機構（IPA）はIT人材の育成を目的とした予備調査の結果を2月18日に発表した。IT業界の転職についての調査で、40歳代を境にIT関連業務から、ITとは無関係な業務に転職する人が50％を超えるなど、一部でささやかれる「プログラマ35歳定年説」を思い起こさせる結果になっている。 IPAはIT人材育成について5つのテーマで調査した。一般企業やIT企業の人材動向の調査結果は1月29日に公開した（参考記事： IT企業、新卒採用苦戦の理由は「仕事のイメージが悪い」）。今回は教育機関向け調査のほかに、オフショア開発、IT人材の派遣、個人事業主、転職などについての調査結果を発表した。教育機関向けについての記事はこちら（学生の「人気」「質」低落傾向で大丈夫？ 大学情報系学部を調査）。 転職についての調査は、IT業界で勤務経験がある約500人の転職経験者を対象に2007年7月にWebアンケートを
企業組織と情報システム部門――「話通じてる？」 ― ＠IT情報マネジメント
この連載では、ITなしでは企業経営が立ち行かない現状を踏まえ、CIO／情報システム部門／情報システム子会社に元気になっていただくための「モノの見方・考え方」を提供します。 CIO／情報システム部門／情報システム子会社を元気にする 私は若いころ（今も年齢以外は十分若造ですが）、ベンダ／SIerのSEとして、お客さま企業に常駐させていただいていました。そこで感じたのは、情報システム部門や情報システム子会社の皆さま（われわれSIerから見ると直接のお客さまです）は、なぜエンドユーザー部門（直接の利用者）／オーナー部門（利用者ではないが、その業務を取りまとめている部門）に対して遠慮がちに話をするのかという疑問でした。エンドユーザー部門／オーナー部門から強く要望されると、その企業にとって最適ではない解であっても受けるケースがあったのです。 しばらくすると、エンドユーザー部門やオーナー部門と一緒に仕事
楽しむことを思い出そう
実在する，ある開発者の話だ。彼は，およそ10年前に大学を卒業し，とあるシステムハウスに入社した。大学は文系でコンピュータの経験はほとんどなかったが，これからはコンピュータの時代だと思ったからだ。 その会社は，いわゆる派遣型のシステム開発も請け負っており，彼は某金融系企業に出向くことになった。そこで，ホスト・コンピュータを使った営業支援システムの開発/更新チームに組み入れられた。新人研修で約1カ月，みっちりCOBOLプログラミングを仕込まれた後，すぐに現場で働き始めた。 それから約10年。転勤や異動もなく，ずっと同じ派遣先で，COBOLによるシステム開発を続けてきた。ダウンサイジング，オープン化，.NET，Web 2.0といったIT界の動向は，はたで見聞きするだけで，仕事には無縁だった。10年間COBOLだけという自分のキャリアは，今どきのSE/プログラマとしては少数派かもしれないとは思う。
「プログラマ35歳定年説」:ITと人間の意外な関係 - CNET Japan
あるサイトで連載の話を進めていて、そのコンテンツを考えていた。目次を書き出しているときにふと「プログラマ35歳定年説」なるものを思い出した。 プログラマ35歳定年説とは、「プログラマは年齢を重ねて行って、35歳ぐらいになったらSEなりマネジメントなり、次に行かないとオマンマ食べられないよ」というものだ。 「そういえば、自分もそう言われてきたっけ・・・。若いころは「俺たちがシステム作ってんだ！実力があれば絶対に大丈夫。ふざけんな！」と思っていたよなぁ。」 ふと考えれば私は今36歳。その説によれば定年を迎えている年齢だ（笑）。年金はもらえないが・・・。 プログラマ、SE、マネジメント、経営の一通りを経験してきて、その説の私なりの考えを書いてみたくなった。 35歳プログラマ定年説は本当か？・・・私にとって かつては技術力に自信があったし、楽しいプログラマ人生を送ってきた。そんな私だが、今もし誰
あるソフトウェアエンジニアの 1 日
メディア関係者向けお問い合わせ先 メールでのお問い合わせ: pr-jp@google.com メディア関係者以外からのお問い合わせにはお答えいたしかねます。 その他すべてのお問い合わせにつきましては、ヘルプセンターをご覧ください。
喜ばれる情報系システムの作り方---目次
達人のこだわりに学ぶ 使ってもらえない--。これが情報系に対する最大の悩みである。 状況を打破するにはシステムの作り方を変えよう。 データ活用のニーズは時間とともに変わるもの。 重要なのは，ITエンジニアが情報系のあるべき姿を描くことだ。 目次 第1回 喜ばれる鍵は三つの“スピード” 第2回 迷わせない画面：一つの画面 第3回 迷わせない画面：使い慣れたツール 第4回 迷わせない画面：文字情報の可視化 第5回 検索速度の向上：DWH専用アプライアンス 第6回 検索速度の向上：インメモリーDBの活用 第7回 検索速度の向上：DWHと端末間に中間サーバー 第8回 短期リリース：市販ツールをプロトタイプに 第9回 短期リリース：自作にこだわらず
情報システム部門よ，野に下れ
今回は，社内ユーザーの立場から見た情報システム部門を取り上げる。 情報システム部門（以下，情シス部門）は，システム構築の中核的存在である。システム運用や保守に機能を特化させたケースもあるが，そもそも情シス部門は，SI（システム・インテグレータ）にシステム構築を依頼する場合の取りまとめ窓口であり，システムを自社開発する場合はそのプロジェクトの中心になるITプロフェッショナル集団だ。ここでは，情シス部門を本来の機能を備えた組織として捉える。 ユーザー部門の立場からは，情シス部門に対して言いたいことが山ほどある。いろいろな問題も孕（はら）んでいる。システム構築を成功させるために，どうしてもそれらの問題を解決しなければならない。 周囲とのあつれきを生むコミュニケーション力の欠如 まずユーザー部門から見た情シス部門の印象を，現場の声で列挙する。ここでは，第一線ユーザーの生々しく泥臭い意見にこだわる。
デキる技術者になるためのちょっとした心掛け － ＠IT自分戦略研究所
将来に不安を感じないITエンジニアはいない。新しいハードウェアやソフトウェア、開発方法論、さらには管理職になるときなど――。さまざまな場面でエンジニアは悩む。それらに対して誰にも当てはまる絶対的な解はないかもしれない。本連載では、あるプロジェクトマネージャ個人の視点＝“私点”からそれらの悩みの背後にあるものに迫り、ＩＴエンジニアを続けるうえでのヒントや参考になればと願っている。 ■リーダーシップトライアングルにおける位置付け この連載では、システム開発プロジェクトにおけるリーダーシップを中心に、「私の視点＝私点」を皆さんにお届けしております。 今回は、リーダーシップトライアングルの中心であるLoveに関係します。Loveについては、第10回「正しいことをし、行動力を発揮するココロ」を参照いただければと思います。 ■コーヒーショップでの出来事 ここのところ、ちょっと堅苦しい話が続いたので、今
システムを捨てる技術
ユーザー部門の要求に応じて、既存システムの機能を追加開発して改善。新たなシステムも次々に構築していく――システム部門の多くは、このような姿勢をとってきた。だが、もはや限界だ。システムの老朽化や複雑化に伴い、保守・運用コストは増す一方。「IT投資を抑制せよ」という圧力も、かつてないほど強い。いま求められるのは、不要なシステムや冗長なシステムを思い切って“捨てる”覚悟と技術である。 「基幹系で利用するメインフレームのなかには、30年ほど前からずっと使っているプログラムがある。これがシステムの保守・運用を困難にしてしまう。常々減らそうと努力してきたが、それでもいつのまにか増えてしまう」。岡村製作所の山木健一情報システム部部長は、こう証言する。 「利用部門の要請もあり、次々に新しいシステムを開発してきた。その結果、複数のデータベースを同時に運用しなければならなくなり、各システムのデータを連携させる
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
