［PR］システムインテグレータがアーキテクチャ設計から導入支援まで提供すべき理由。グロースエクスパートナーズ
［PR］システムインテグレータがアーキテクチャ設計から導入支援まで提供すべき理由。グロースエクスパートナーズ システムを開発し、その価値をユーザーに届けるというプロセスにおいて、コードを書く作業が占める割合は3割もないのではないか。新宿にオフィスを構えるシステムインテグレータ、グロースエクスパートナーズ株式会社（以下GxP）の執行役員 鈴木雄介氏は、GxPのシステム開発を見渡しつつそう説明します。鈴木氏は日本Javaユーザーグループ会長でもあります。 システムインテグレータにおいて、あるいは開発者と呼ばれる人たちにとって、優れたコードを生み出せる能力はつねに注目されるものです。しかし鈴木氏は、優れたコードを活かすためにも、コード以外の部分の重要さにも目を向けるべきと言います。 その示すところを、顧客の課題や要望を、アーキテクチャ設計の段階から顧客と一緒に考えていくGxPのシステム開発を通し
詳細設計書ってよくわからない - 未来のいつか/hyoshiokの日記
わたしは、情報システムと呼ばれているものを作った経験がないので、よくわからないのだが、世の中には詳細設計書というのがあるらしい。 下記参照。 http://gm7add9.wordpress.com/2012/11/30/%E8%A9%B3%E7%B4%B0%E8%A8%AD%E8%A8%88%E6%9B%B8/ プログラムの詳細設計をやる人というのがいて、その人が書くらしい。あくまで自分には経験がないので、伝聞、想像でものを言っている。 プログラムの詳細設計というのは、プログラムへの要求仕様というのがあって、それを実現するために書くらしい。要求仕様というのは最終的な利用者が、こーゆーものが欲しいとか、こーゆーことができたらいいなということを、なんらかの方法で、なんらかの形でまとめたものらしい。 そんでもって、要求仕様を作る人と、詳細設計を作る人と、プログラムを作る人と、テストをする人と、
SIerの中の人がヤル気を失っていく理由 - ひがやすを技術ブログ
SIerで働いているみなさん。ヤル気十分でいきいきと働いていますか？ Yesと胸を張って言えない人、新人の頃はどうでしたか。 入社したころは、みんなヤル気にあふれているんです。なのに、三年も経つとヤル気がな くなって、惰性で仕事をするようになる。 これは、SIerだけでなく、大企業で共通に見られる傾向です。 なぜ、徐々にヤル気を失っていくと思います? それは、「自分の頑張りではどうしようもない」「頑張ってもそれほどプロジェクトが良くなった気がしない」「頑張ってもそれほど評価につながらない」という経験を積み重ねるたびに、だんだんと無気力になってしまうためです。 努力が無効だという経験を積んでいくと、誰も努力しなくなりますよね。そうやってヤル気を失ってしまうのです。 規模の大きいプロジェクトにいるほど、その傾向が強くなります。なぜなら全体に占める自分の割合は、ほんの僅かなので、どんなに努力して
SIerを退職し、Web系に転職しました - arveltのソフトウェア技術メモ
銀行系列の中規模SIerを退職し、 受託と自社サービスの開発を行っている小規模Web系に転職することになりました。 7/30が最終出社日でした。8/1からは新しい勤め先へ向かいます。 １．これまでやったこと ２．これからやりたいこと ３．なぜ転職しようと思ったのか なお、３はいわいる自分語りを含む上に長いのでご注意ください。 読ませる知り合いもいないのに何故書いた。 １．これまでにやってきたこと。 オープン系の基幹システムの保守開発に携わり4年ほど。 Java、COBOL、ExcelVBAをメインにやっていました。 もちろんSQLも普通に書いたりしつつ、触ったことのあるDBはOracle、PostgresSQL、SQLServer。 業務知識は主に流通系。Web開発とかもやりました。Javaでstruts1.Xとか、ASP.NETとC#とVBとか。 それと個人的欲求に基づき、Android
業務プログラマーはこの先生きのこれるのか - novtan別館
SIerはなくなると言われて久しいです。僕もそれは間も無くやってくる現実だと思います。少なくとも、従来型のSIという仕事自体はなくならないけど、そのやり方は大きく変わると思っています。いくらクラウドだSaaSだなんだといっても業務要件を自動で書いてくれるわけではなく、何が正しいかの判断もしてくれません。今までにもまして、何を組み合わせてどう作るかを考える必要がでてくるし(従来であればスクラッチで作ります！ってのが出来たものもそんな金かけるなんてアホかと言われる世界です)、そうなるとエンジニアは広範な知識と経験を持って勝負しなければなりませんね。 しかし、いわゆる上流の工程が今にもまして重要になる反面では、下流の仕事が減っています。コアロジックさえ設計書に書いておけば、それ以外は自動生成されてテストしするだけだしテストも自動化されてるよ〜なんてことになるといわゆる大量な作業をもくもくとこなす
長時間拘束の仕事はエンジニアの首を絞める
今やほぼ週1の更新さえもおっくうになりつつあるのが危険だと思いつつ。 書くネタはたまに思いつくけれど文章に起こすとなるとそれなりに時間かかるのでなかなか…。 最近は色んなことをインプットする時間がなかなか取れずに、ちょっと焦ったりしている。いちおう技術者の端くれとして生きているので、新しいネタなどは仕入れていかないと、どんどんついていけなくなるのでそういう時間を作りたいとは思っているものの、その気がある時は時間がない、時間がある時は気が乗らないという感じで日々過ぎているのがマズイなあと。 特に仕事面だと、毎日長時間会社に拘束されるような仕事の仕方は良くない。火消しだのデスマだのに突っ込まれたり遭遇したりすることが多いけど、そればかりやってると本当に自分の生活って何よ、って気になってくる。 30代になると今までの経験とかノウハウを切り売りして、インプットを怠ってもある程度までは仕事は回してい
アマゾンにおけるソフトウェア開発の仕事について感じたこと - 達人プログラマーを目指して
ちょうど、先日アマゾンのオープンハウスというイベントでお話をさせていただく機会があったのですが、開発者向けの20日のセクションだけで90名近くの方々にご参加いただきました。平日にもかかわらず、多数の方々にご参加いただき、どうもありがとうございました。 私自身は、昨年秋にSIerからアマゾンに転職してまだ半年ですが、この機会にアマゾンにおけるソフトウェア開発の文化や考え方について、ブログでご紹介できる範囲でまとめてみたいと思います。 私は、ずっとブログに書いてきたようにSI業界からの転職だったのですが、一般的なSIerにおけるソフトウェア開発の考え方や手法といろいろな面で違っているということは予想していたというか、もともと覚悟の上での転職でした。それでもやはり最初のうちはあまりにも大きな変化に自分の仕事のスタイルを合わせるのにいろいろと苦労しました。基本的には転職したての頃に抱いた感想（転職
ソフト開発をステップ数で見積っていることに疑問を持たなくてはならない - レベルエンター山本大のブログ
ステップ数を見積もり根拠にする会社さんは、いまだに多い。嘘じゃない。 お世話になってる会社さんもそういう仕組みをとってるところがあって、いいにくい部分もなきにもあらずだが、お世話になってるからこそいいたい。 そんなことやってちゃだめだと。 １キロステップの生産性指数をだして、今回の開発は10キロだから１０００万円とか。 汎用機時代ならまだ百歩譲ってわからんでもないけど、オープン系という言葉すら死語になりつつあるこのご時世において、ステップ数が１キロ（１０００行）だったら１人月とかどうこうという話は、もはや見積もりでもなんでもなく、こじつけだ。 フレームワークのコアのコードも、 ビジネスロジックの肝のコードも、 ネットワークの通信コードも、 自動生成したコードも同じ１ステップとカウントする。 見積もり時の計画ステップ数と、実際に開発したときの実績ステップ数を比較して 次の開発の値決め（ダンピ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Private Site