SIerの下請け開発者ってレベル低すぎない？ - UXエンジニアになりたい人のブログ
ネット上ではSIer批判＝技術のことをわかっておらずプログラムも書けずPMも出来ない非効率でダメダメな上流工程と、 人月単位での労働力提供という業界の慣習に縛られ、持ち前の優秀な技術力・知識を生かせず非効率な作業を強いられているかわいそうな下請け開発者、という構図が確立されているように思います。 自分が関わるまでは、まあそうなんだろうなと思っていましたが、しかし実際にそういう立場のひとと関わりをもつにつれて、どうもそうではないのではないかと思うようになりました。このあたりの実情を書いていこうと思います。 なお、先に言っておきますが本記事で書くことは、上流工程がどうのとか、業界の多重請け負い構造がどうのとか、給料が安くてとか労働条件が過酷でとか、そういう話とは全く関係がなく、純粋にプログラミングのスキルの話だけです。 対象はおもに詳細設計、実装UTだと思ってもらえれば。外部仕様が決まった状態
パフォーマンス３倍を実現した仕事術
当方都内ヴェンチャーSE。 俺がリーダーになってから試しに導入してみたルールのおかげでチームの生産性が３倍になった。 誇らしいことだが、果たして一般的に有効な方法なのかどうか気になるので広く反応を集めたいと思って書く。 そのルールというのは単純、「一日に５時間以上コードを書かない」というものだ。 勤務時間の８時間のうち、本当に仕事をするのは５時間だけに制限する。 そして残りの３時間は会議と称する息抜きタイムにした。 これで生産性は３倍になった。 社長も機嫌も俺の評価もうなぎ登り。 社長はモーレツに仕事をする人で、社員にも同じようにモーレツに働くことを求めていたが、俺は同調しなかった。 普通の人間は集中できる時間に限りがある。 凡人にはよくて一日５時間が限界だ。 それ以上の時間を使っても、単位時間あたりの生産性は下がるばかりだ。 ならいっそ、残りの時間は最高のパフォーマンスを発揮できる５時間
ユニットテストが何のことかわからなかったわけだが。 - 馬車馬のクリップボード
2013-10-08 ユニットテストが何のことかわからなかったわけだが。 私事 いまだにユニットテストって受け入れられないんだろうな - 個人的なまとめこちらの記事を読んだ。 まず最初に、ユニットテストってなんぞ？となり、はてなのキーワードを見たのち、一応グーグル先生にも訊いてみた。結果、単体テストのことらしいと把握。自分が認識してる単体テストと上記の記事で言われてるユニットテストが同じものであるかは置いといて、単体テストをやらないプロジェクトの恐ろしさに震えた。 自分は基本的にエンドさん相手に仕事してる。たまに違うときもあるけど、基本的にエンドさんに直接顔合わせる機会がある仕事が大半。んで、碌にテストしてないようなものを放り込むと最終的に残された人間が泣きを見る状況に陥らされる。 なので、単体テストもしないプロジェクトって経験したことないんだけど、ブコメとか見ると案外そういうプロジ
アジャイル開発の本質 〜 アジャイルとウォーターフォールの違いとは | Social Change!
「アジャイル」という言葉が一人歩きしてしまっていて、たまに話をしていても通じないときがあります。 それくらいアジャイルという言葉が広く知られるようになったんだと思う一方で、かえって話が通じなくて、もどかしく感じることもあります。だからといって、そこで「正しいアジャイルとは」みたいな議論をしたい訳でもないのです。 広まれば広まるほど、そういった言葉の認識の齟齬が出るのは仕方ないですね。その正しい定義みたいなところを追求するのもナンセンスなので、そんなつもりはないですが、ただ自分がどう考えているかについては書いておいても良いかな、と考えました。ここは私のブログですしね。 そこで、この記事では、私の考えるアジャイル開発の本質について、そしてウォーターフォールとの違いについて書きました。 アジャイル開発では機能を全部つくらない これまで私の中で、アジャイルと言えば当たり前の前提がありました。それは
久々に壮絶な自爆、というかブーメランを見ました。 - 30近いおっさんのブログ
「おい！どの口がアジャイル出来るって言ってるねん！」 さて、私にしては珍しくブチ切れ気味で記事を書いているのでこんな事書いていますが、ここからは、効果を本当に上げるアジャイル開発を実施したいときのリクルートで、どういうスキルを持った人を雇えばいいか？という話を進めたいと思います。これはとてもシンプルな一言で言えます。 テスト駆動開発が適切にできる能力があること この一言につきるのです。クライアントの皆さんは、是非アジャイルベンダーを雇うときはプログラマの人にこの能力を要求してください。注意しないといけないのは、テスト駆動が適切にできていないプログラマは、わかっていない事すらわかっていないこと、そして、営業さんとかマネージャさんのレベルだと、「テスト駆動が適切にできる人かどうか見分けがつかない事」が問題になってきます。これは、まともにテスト駆動ができる人がその人と話をすればテスト駆動をちゃん
【書評】アジャイルソフトウェアエンジニアリング
アジャイルソフトウェアエンジニアリング (マイクロソフト関連書)著者／訳者：Sam Guckenheimer、Neno Loje、日本マイクロソフト監訳、TFSUG監訳、トップスタジオ出版社：日経BP社発売日：2012-05-24単行本：320ページISBN-13：9784822294687ASIN：4822294684 日本マイクロソフトの長沢さんから献本いただきました。ありがとうございます！ まず結論から言うと、いわゆるアジャイルな開発におけるライフサイクルやプロセスと技術の関係を「実践」という観点でまとめた本としてオススメできる本だと思う（ただしアジャイル初心者の人にとっては難しいです）。 本にマイクロソフトやVisual Studioという文字があるので、それ以外の環境で仕事をしている人はスルーしてしまいがちですが、内容はVisual StudioやTeam Foundation
継続的インテグレーションを再考 - プログラマの思索
「継続的インテグレーション入門」を読んでみて、もっと早く読んでおけば良かったと後悔した。 内容がとても素晴らしかったので、理解できたことをラフなメモ書き。 【元ネタ】 Togetter - 「SIerは自動化する対象が違っているのでは？」 Continuous Deliveryをポチッた - watawata日記 Continuous Delivery - haru01のめも アジャイルなインフラのつくり方とデータマネジメント - メソッド屋の日記 インフラやデータ移行の自動化～アジャイル開発の最後の問題: プログラマの思索 Continuous Delivery～TDDとCIの次に現れた自動化の概念: プログラマの思索 【1】「はじめに」に、キーボードに「Integrate」というボタンが貼られていて「こんなに簡単ならいいのに」という雑誌の広告から始まる。 この挿話は、ビルド＆デプロイの
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://capsctrl.que.jp/kdmsnr/diary/20100601.html