JavaエンタープライズアーキテクチャにおけるHTML5 - Enterprise ☓ HTML5 Web Application Conference ...Yusuke Suzuki
SEはピンチに陥った時にどんな姿勢・態度でSEマネジャーと相談すれば良いか。「切り開け!」シリーズの前回(ピンチに強いSEは「どうしたら良いでしょうか」と言わない)はそれについて述べた。今回は第4回を書く。 アプリケーション軽視の状況が長年続く 顧客は営業や工場、人事・経理など、いろんなシステムを開発する。その目的は企業の競争力の強化や生産性の向上などを図るためである。コンピュータはあくまでもそのための道具である。顧客にとってはアプリケーションが先で、コンピュータはあくまでも後である。 そのようなシステムを受注して開発するIT企業には、顧客の業界や業務、アプリケーションが分かるSEが不可欠である。ITに強いSEばかりでは、まともなシステム開発はできない。特に元請けのIT企業にはこのことが要求される。これには誰しも異論はないと思う。 だが、筆者には日本のIT企業やSEはアプリケーションをあま
はじめに IT系の業務区分には、プログラマー(PG)、システムエンジニア(SE)、コンサルタントという区分けがあります。しかし、これらにはどういう違いがあるのかわかったようでわからない感じもします。ここでは、ITコンサルタントという立場から、PG、SE、コンサルタントの違いについてお話します。 PG、SE、コンサルタントの違い PG、SE、コンサルタントの違いは以下の通りです。 お客様の状態から何をすべきかを導くのがコンサルタント 作るべきものをどのように実現するかを考えるのがSE 実現すべきものを作り込むのがPG 現場の実態 上記区分を完璧に守っている組織を筆者は見たことがありません。なぜなら、非効率だからです。優秀な方は、PG、SE、コンサルタントの全てができますし、そうでない方は何もできません。要は、優秀な方が全部に関わり、そうでない方を支えるのが最も効率的だからです。世の中にはプレ
2014-04-03 逆ギレしたSEを、ラーメン屋に例えて笑い話に昇華してみる 日記 ネタ 昨日、1+1を0+1と計算するSEに115万ぼったくられた話 - しろぐらまー と日記を書いた。 だが、今日読み返したら、超絶つまらない。 しかも、ムカついたことの核心にあえて触れなかったため、単に情弱ぼったくられ乙な日記になってしまったので、書き直す。 昨日の日記の主旨はこうだ。 「SEにある仕事を頼んだら、依頼通りに上がってこなかった」 私は、その事実や金額にムカついたのではない。 ただ、そのまま書いても面白くも何ともないので、ラーメン屋に例えて書く。 SE(以下S)=ラーメン屋、A=そのSEを紹介したデザイナー、です。 私「ラーメン食べたいんだけど」 A「いいお店、紹介するよ」 (ガラッ ラーメン屋のドアを開ける) S「……」 私(あれっ?挨拶もないの?) (席に座る) 私「メニューありますか
プログラマの業界は、同じソフトウェアを作るという作業でありながら、大きく2つの形態にわかれています。 小売業界が、コンビニやデパートなど、同じモノを売るという作業でありながら全く違う形態があるのに近いです。 この分化は、2010年ごろのGREE/DeNAの人材獲得合戦で明確に形ができたように思います。 なので、もう5年たって、定着しつつある感じでしょうか。 その2つの形態というのは、労働集約型の業界と、知識集約型の業界です。 労働集約型はSIで多い多人数開発の業界で、知識集約型がサービスで多い少数精鋭型の開発です。 知識集約型の業界は、最初こそちょっとお花畑すぎる感じもありましたが、最近は落ち着いてきており、徐々に経済的に均衡するところに収束していくと思います。それでも比較的めぐまれた労働環境ではあり続けると思います。ただし、常に勉強が求められる業界ではあります。 問題は労働集約型の業界で
客先のファイルシステムをバックアップなしで消し飛ばした事あるけど、 特にトラウマになってないな。 多分、最初の時点で「終わった」って気分になったからだと思う。 人間、助かるかどうかの瀬戸際にいる時が一番精神が削れる。 もうどうやったって助かりようがない、という状況に置かれたら、特に迷ったり気を揉んだりする事もない。 (残業しないで済むかどうか、休日出勤しないで済むかどうか、という瀬戸際が一番疲れるのに似てる。 「しないで済むわけがない」という状況なら、定時は気にならない)
コードも書けないSE(笑)とか言ってるアホ共は ガチでメーラとWordとExcel,パワポ(しかも2003(笑))、teraterm、FFFTP位しかつかわねーからさ あいつら本気でXP(笑)、メモリ1GBで足りてるとか思ってるからタチがわりーわ。 ・コードがかける若手SE(笑)がEclipseとかMySQL、Oracle,Chrome,Firefox,IE,Java,.netと使うからある程度スペックが欲しい。(と言っても今時の5万で買える普通スペックで良い。。) ↓ ・若手が新しいPC寄越せと要求 ↓ ・年食ったコードがかけないSE(笑)はOffice2003(笑)位しか使わないし、めんどくさいから要らないと抜かす ↓ ・先輩がいいって言ってるのにお前らが要求するのか?とか言って取り合わない。 ↓ ・ほんとに必要な最前線の若手にまともなPCが行かない、その結果朝にパソコン起動してメーラ
WBS法のメリットとデメリット WBS法のメリットとしては、以下のものが挙げられます。 工期と工数、体制(人件費)までを同時に見積もれる 個々のタスクは非常に正確 タスクの深さであるテストの段階数やドキュメント化の程度を完全に取り込める 客観的であり理解しやすい 対してデメリットを挙げると、以下のようなものがあります。 A.タスクごとにバッファを取ってしまい、コストやスケジュールが過重になりやすい(後述) B.設計の精度をかなり進める必要がある。概算という使い方が困難 C.実績のないシステムではタスクごとの見積もりの類推が困難 一般的なタスクからの見積もり方法について解説します。この手法は特に方法論化されているわけではなく、ごく一般的に用いられている方法です。 ここでは、SEが1人、プログラマ(TT1、TT2)2人のほか、SEのアシスタント(いわゆる新人ぐらい)が1人というチーム構成を例と
つい先日、富士通がグループで抱える3万人ものSEを再教育して、職務転換を行う計画であるというニュースを知りました。 富士通の3万人SE職務転換大作戦は成功するのか? - GoTheDistance 一つのシステムを複数の企業などが利用するクラウドサービスがこのまま普及すれば、顧客の要望を聞いて個別システムを作り込むSEは仕事がなくなり、余剰人員問題が顕在化するからだ。 クラウドの普及により、オーダーメイドでシステムをゼロから構築する必要がなくなり、そもそも顧客からの要件をまとめてシステムを設計するSEの仕事が不要になったり、基盤を構築、運用するエンジニアが不要になるということは、最近になってよく言われることであり、特に新しいことではありません。もちろん、クラウドの普及によって、これらの伝統的なSEの仕事が少なくなり、人員が余るという議論は間違いではないと思います。 ただし、一方でより本質的
わが「心の師匠」の一人に元SEの方がいらっしゃって、今、50代半ばの彼が20代のばりばりSEだったころの話。 お客様との打ち合わせで、「こういうことしたいんだけど」と言われると、つい「あ、それ、無理です」と反応し、「こんなことはできるのかな?」と言われれば、「ああ、ダメですねぇ」と答えてしまったのだそうです。 しばらくは辛抱強く相手をしてくださっていたお客様が、とうとうキレて、 「私たちは、コンピュータに関しては素人だ。だから、技術的にできるかどうかなんかわからない。でも、”したい”ことはある。あなたたちSEは、私たちが”したい”ことをどう実現するかを考えるのが仕事ではないのか。”こうすればできる”とか”こういう風に条件を変更できませんか?”とか言ってくれれば、こちらも考える。どういう風に問題解決をするか、共に考えてほしいと思って、こうやって話をしているのだ。 だから、二度と”できない”と
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く