2012年01月18日
システム開発とドキュメント
アジャイル開発では最低限のドキュメントでなるべく開発コストをさげ
無駄な生成物は作らない方向だが
保守フェーズで数年たったら開発で使えないヤバイやつがアサインされることがおおい
そいつはドキュメントがないから分からないって必ず言い出す
いままで何度も見てきた同じパターン
プログラムを解析できないし暗号文だとか言い出す
プログラムが分からないからプログラム設計書で日本語で書かれたものをほしがる
でもそんな不要なものは作らない
仕様やマニュアルや開発の経緯などはドキュメントに残すが
プログラムの日本語版などいらないだろ
どうせプログラムの日本語版を作って保守のアホ担当に渡しても
プログラムの解析できないのにどうやってメンテするんだろう
そんなやつはいつも、何がないこれがないって文句言って責任回避して
他人に責任を押し付けて自分はなにも悪くないって顔してる
できることならドキュメントがないからつくった人よんできてそいつにメンテさせようとまでする
でも上の人間もプログラム読めないからプログラムの日本語ドキュメントがないのが悪いってなる
(ほんとに仕様もなにも書いてないクソドキュメントしかない場合もあるけど)
そうやってSIerは無駄なドキュメントを量産して金を稼いできた
せめてプログラムをバリバリ作れなくても見て多少理解できるレベルの人間がほしい
無駄な生成物は作らない方向だが
保守フェーズで数年たったら開発で使えないヤバイやつがアサインされることがおおい
そいつはドキュメントがないから分からないって必ず言い出す
いままで何度も見てきた同じパターン
プログラムを解析できないし暗号文だとか言い出す
プログラムが分からないからプログラム設計書で日本語で書かれたものをほしがる
でもそんな不要なものは作らない
仕様やマニュアルや開発の経緯などはドキュメントに残すが
プログラムの日本語版などいらないだろ
どうせプログラムの日本語版を作って保守のアホ担当に渡しても
プログラムの解析できないのにどうやってメンテするんだろう
そんなやつはいつも、何がないこれがないって文句言って責任回避して
他人に責任を押し付けて自分はなにも悪くないって顔してる
できることならドキュメントがないからつくった人よんできてそいつにメンテさせようとまでする
でも上の人間もプログラム読めないからプログラムの日本語ドキュメントがないのが悪いってなる
(ほんとに仕様もなにも書いてないクソドキュメントしかない場合もあるけど)
そうやってSIerは無駄なドキュメントを量産して金を稼いできた
せめてプログラムをバリバリ作れなくても見て多少理解できるレベルの人間がほしい
2011年09月12日
Excelと自動化
「SIerにはコード記述の自動化からビルド・デリバリの自動化へのトレンドの変化を理解してほしい」
で書かれているのがしっくりくるね
もうそろそろ気づいている人も多くなっていまさら
「Excelで項目定義して簡単に画面ができます」って言う人も
いなくなったとおもっていたら
自信満々についこの間、「Excelで・・・」言われてしまった
ダメだこりゃ〜
次ぎ行ってみよう
チャンチャカチャンチャン〜♪
で書かれているのがしっくりくるね
もうそろそろ気づいている人も多くなっていまさら
「Excelで項目定義して簡単に画面ができます」って言う人も
いなくなったとおもっていたら
自信満々についこの間、「Excelで・・・」言われてしまった
ダメだこりゃ〜
次ぎ行ってみよう
チャンチャカチャンチャン〜♪
2011年09月05日
ソルジャー
「スーツとソルジャーの間にギークがいる」
ってまさしくだな~
SIerにギークのポジションは少ないな
ソルジャーが年取って最前線に立てなくなると次々に若いソルジャーが
追加されていた時代は終わって、最近はソルジャーが高齢化してるな
さらにソルジャーはギークにはなれないから
スーツになるかと思いきや、スーツのスキルも勉強してないから
ただの老いたソルジャーだし・・
老兵は死なず、ただ消え去るのみ
おとなしくリストラされろ!
ってまさしくだな~
SIerにギークのポジションは少ないな
ソルジャーが年取って最前線に立てなくなると次々に若いソルジャーが
追加されていた時代は終わって、最近はソルジャーが高齢化してるな
さらにソルジャーはギークにはなれないから
スーツになるかと思いきや、スーツのスキルも勉強してないから
ただの老いたソルジャーだし・・
老兵は死なず、ただ消え去るのみ
おとなしくリストラされろ!
2011年08月23日
プログラミングの生産性
PG→SE→PMや上流・下流などとわけの分からないことを言っている人をみたら
要注意です。無視しましょう。頭悪いです。
SEです。設計できます。っていうやつで設計できるやつを見たことがない
設計書をフォーマットにのっとって書くのがうまい人はみたことがある
SEって言ってるやつはたいていプログラミング能力のないやつばっかだし
プログラミングにすら挫折しておいてSEと名乗って高い給料もらうのはどうかと思われる
プログラミングの能力は20倍もの格差があるといわれたり
1000の寄せ集めより5人の凄腕PGのほうが生産性が高いといわれたり
自分が今までやってきて感じたのは20倍どころではなく無限大に格差がある
なぜか
できないやつはゼロからコードを書かせたら完成しないので成果はゼロになる
なのでゼロ対1でも無限大
無限大はおいておいて、ちょっとしたPGは1人でサラリーマンPGの5人分くらいは軽くこなす姿は
皆さんもみたことがあると思います
そうなるとできない人の割り当てが自然とできる人に流れてくる
そんなときはどうするかと言うとわざと完成させないか
完成させたけど報告しないで黙っておくかになる
物凄い能力を持っていたとしても、日本企業では仕事の能力に対する評価はないに等しいため
発揮できない。いや発揮してはいけない
下手に物凄いスピードで生産し、できないやつの分を割り振られ
それでもなお涼しい顔で定時帰りをしていると、なぜか嫉妬の目でみられ
はては、批判の対象になったりもする
自分の能力のなさを理解する能力もない人間は、能力のある人間を貶めることによって
自分の位置を向上させようとする
SIerで一番評価されるのは周りの人よりもちょっとだけできる人だ
すごーくできすぎてはいけない
なのでどんな言語でもどんな環境でも割り当てられた機能のプログラミングをちょいちょいと
実装してしまう人は、ひたすらネットサーフィンに明け暮れなければいけない
現場によってはネットサーフィンできないところもあるため
自分専用の便利ツールなんかを暇をもてあましている時間に作らなければいけない
プロジェクトの期間中に便利ツールは公開できない
公開すると・・・・上記の状態で・・・
皆さんは未公開の自分専用の便利ツールをいくつ作りましたか
要注意です。無視しましょう。頭悪いです。
SEです。設計できます。っていうやつで設計できるやつを見たことがない
設計書をフォーマットにのっとって書くのがうまい人はみたことがある
SEって言ってるやつはたいていプログラミング能力のないやつばっかだし
プログラミングにすら挫折しておいてSEと名乗って高い給料もらうのはどうかと思われる
プログラミングの能力は20倍もの格差があるといわれたり
1000の寄せ集めより5人の凄腕PGのほうが生産性が高いといわれたり
自分が今までやってきて感じたのは20倍どころではなく無限大に格差がある
なぜか
できないやつはゼロからコードを書かせたら完成しないので成果はゼロになる
なのでゼロ対1でも無限大
無限大はおいておいて、ちょっとしたPGは1人でサラリーマンPGの5人分くらいは軽くこなす姿は
皆さんもみたことがあると思います
そうなるとできない人の割り当てが自然とできる人に流れてくる
そんなときはどうするかと言うとわざと完成させないか
完成させたけど報告しないで黙っておくかになる
物凄い能力を持っていたとしても、日本企業では仕事の能力に対する評価はないに等しいため
発揮できない。いや発揮してはいけない
下手に物凄いスピードで生産し、できないやつの分を割り振られ
それでもなお涼しい顔で定時帰りをしていると、なぜか嫉妬の目でみられ
はては、批判の対象になったりもする
自分の能力のなさを理解する能力もない人間は、能力のある人間を貶めることによって
自分の位置を向上させようとする
SIerで一番評価されるのは周りの人よりもちょっとだけできる人だ
すごーくできすぎてはいけない
なのでどんな言語でもどんな環境でも割り当てられた機能のプログラミングをちょいちょいと
実装してしまう人は、ひたすらネットサーフィンに明け暮れなければいけない
現場によってはネットサーフィンできないところもあるため
自分専用の便利ツールなんかを暇をもてあましている時間に作らなければいけない
プロジェクトの期間中に便利ツールは公開できない
公開すると・・・・上記の状態で・・・
皆さんは未公開の自分専用の便利ツールをいくつ作りましたか
2011年06月23日
mongoDB
NoSQLとしてKVSが記事になることが多かったが
以前からちょっとずついろいろとさわってきた
KVSだと最初にBerkeley DBがくる
Berkeley DBはSVNのストレージなんかにも使われたり実績豊富
日本の有名どころではTokyoCabinetかな
まあなんにしても
KVSを業務システムに生かそうと考えていろいろ設計方針を模索していたが
どうもしっくりこない
業務システムの場合、検索が重要になるからKVSだと転置インデックスが必要になる
転置インデックスの構築はそれなりにコストがかかるから小さなオンラインリアルタイムバッチ
として実装する・・・いまいち
列指向DBであるBigTableはどうかとGoogleAppEngineをいじってみた
GoogleAppEngineではインデックスをつけることができる
GoogleAppsの中のコビトさんが一生懸命インデックスを構築しているらしいから
自分で転置インデックスのロジックを実装しなくてよい
でもGAEはどうも業務システム作りづらい
以前も書いたが画面項目そのままに否定形構造のデータをそのままストアしたい
MySQLにXMLぶち込んでExtractValueで検索ってやってたけど
最終的にドキュメント指向DBに行き着いた
日本の商習慣である紙の資料ベースのシステムで画面構成も紙イメージそのままに
DBも画面項目をJsonにしてmongoDBにそのままぶち込む
なかなかいい案だと思う
もっと日本でmongoDBの利用実績が多くなるといいな
以前からちょっとずついろいろとさわってきた
KVSだと最初にBerkeley DBがくる
Berkeley DBはSVNのストレージなんかにも使われたり実績豊富
日本の有名どころではTokyoCabinetかな
まあなんにしても
KVSを業務システムに生かそうと考えていろいろ設計方針を模索していたが
どうもしっくりこない
業務システムの場合、検索が重要になるからKVSだと転置インデックスが必要になる
転置インデックスの構築はそれなりにコストがかかるから小さなオンラインリアルタイムバッチ
として実装する・・・いまいち
列指向DBであるBigTableはどうかとGoogleAppEngineをいじってみた
GoogleAppEngineではインデックスをつけることができる
GoogleAppsの中のコビトさんが一生懸命インデックスを構築しているらしいから
自分で転置インデックスのロジックを実装しなくてよい
でもGAEはどうも業務システム作りづらい
以前も書いたが画面項目そのままに否定形構造のデータをそのままストアしたい
MySQLにXMLぶち込んでExtractValueで検索ってやってたけど
最終的にドキュメント指向DBに行き着いた
日本の商習慣である紙の資料ベースのシステムで画面構成も紙イメージそのままに
DBも画面項目をJsonにしてmongoDBにそのままぶち込む
なかなかいい案だと思う
もっと日本でmongoDBの利用実績が多くなるといいな
2011年05月30日
JQueryでの動的Table
JQueryで可変のTableを作成する
<html>
<header>
<link rel="stylesheet" href="http://ajax.googleapis.com/ajax/libs/jqueryui/1.8/themes/redmond/jquery-ui.css" type="text/css" />
<style type="text/css">
input {
margin:0 0 0 0;
padding:0 0 0 0;
}
td {
margin:0 0 0 0;
padding:0 0 0 0;
}
.number {text-align: right;}
</style>
<script type="text/javascript" src="http://www.google.com/jsapi"></script>
<script type="text/javascript">
google.load("jquery", "1.7.0");
</script>
<script type="text/javascript">
$.fn.extend({
Table:function(param){
//tbodyタグの内部を可変にする
var tb = $(this).find('tbody');
//テンプレートレコード
var row = tb.find('tr:first').clone(true);
//初期レコード数
var default_cnt = param?param:1;
var ret = {
//レコード追加
add:function(){
tb.append(row.clone(true));
},
//レコード削除
del: function(index){
tb.find("tr:eq("+index+")").remove();
},
//レコード数
count:function(){
return tb.find("tr").size();
},
//初期表示に戻す
clear:function(callback){
var cnt = this.count();
for(var i=0;i<cnt;i++){
this.del(0);
}
for(var i=0;i<default_cnt;i++){
this.add();
}
if(callback) callback();
},
//指定レコードの取得
getRow:function(index){
var cnt = this.count();
if(cnt<index)
this.add();
return tb.find("tr:eq("+index+")");
},
//全レコードの取得
getAllRows:function(){
return tb.find("tr");
},
//レコードINDEXの取得
getIndex:function(obj){
return tb.find("tr").index($(obj).closest("tr"));
}
};
//初期表示
ret.clear();
return ret;
}
});
</script>
<script type="text/javascript">
$(function(){
var table = $(".table_detail").Table(5);
$(".cleardetail").live('click',function(){table.del(table.getIndex(this));});
$(".add").click(function(){table.add();});
});
</script>
</header>
<body>
<table class="table_detail" border="0" cellspacing="0" cellpadding="0">
<thead>
<tr class="ui-widget-header" >
<th align="center" width="40">NO</th>
<th align="center" >商品コード</th>
<th align="center">商品名称</th>
<th align="center">単価</th>
<th align="center">数量</th>
<th align="center">金額</th>
<th> </th>
</tr>
</thead>
<tbody >
<tr >
<td class="ui-widget-content">
<div class="detailno"> </div><input type="hidden" name="detailno[]" >
</td>
<td>
<input type="text" class="item_code ui-widget-content" name="item_code[]" value="" style="width:80px;" >
</td>
<td>
<input type="text" class="item_name ui-widget-content" name="item_name[]" value="" style="width:250px;" >
</td>
<td>
<input type="text" class="item_price number ui-widget-content" name="item_price[]" value="" style="width:80px;">
</td>
<td>
<input type="text" class="item_amount number ui-widget-content" name="item_amount[]" value="" style="width:80px;">
</td>
<td>
<input type="text" class="item_money number ui-widget-content" name="item_money[]" value="" style="width:80px; ">
</td>
<td>
<button class="cleardetail btn" style="font-size: 70%;height:19px;">削除</button>
</td>
</tr>
</tbody>
</table>
<button class="add btn">追加</button>
</body>
</html>
2011年05月06日
赤字プロジェクト
赤字プロジェクトを撲滅するためにマネージメントを強化しよう
いやいや違うだろう
確かにアメリカチックな職能的プロジェクトチームでボスが絶対みたいなプロ集団では
マネージメントの強化は有効だけど
客先常駐からの帰社組で今やること無いから請負案件に使ってよ的な
サラリーマンチームはマネージメント関係ないだろ
もう十分に会社や部門のラインの奴隷になっているだろう
必要なのはマネージメントの開放の方だろう
ある程度の自由度を与え、外の技術を積極的に吸収し持ち帰って
チームを活性化するような
プロジェクトチームのあり方としてマネージメントから自己組織化を目指すべきだろう
いやいや
自己組織化以前にプロとしてプログラミングしろよ
技術者として継続的な勉強しろよ
おれは昇進しないから
PMやったりテスターやったりパフォチューやったりプログラミングやったりまたまたPMやったり
すげーいい環境
(んっ・・ただ単にいいように使われているだけ?)
いやいや違うだろう
確かにアメリカチックな職能的プロジェクトチームでボスが絶対みたいなプロ集団では
マネージメントの強化は有効だけど
客先常駐からの帰社組で今やること無いから請負案件に使ってよ的な
サラリーマンチームはマネージメント関係ないだろ
もう十分に会社や部門のラインの奴隷になっているだろう
必要なのはマネージメントの開放の方だろう
ある程度の自由度を与え、外の技術を積極的に吸収し持ち帰って
チームを活性化するような
プロジェクトチームのあり方としてマネージメントから自己組織化を目指すべきだろう
いやいや
自己組織化以前にプロとしてプログラミングしろよ
技術者として継続的な勉強しろよ
おれは昇進しないから
PMやったりテスターやったりパフォチューやったりプログラミングやったりまたまたPMやったり
すげーいい環境
(んっ・・ただ単にいいように使われているだけ?)
未来のSIer
最近のシステムのライフサイクルは超高速になってきた
以前は製造に年単位で運用は5年は当たり前だったが
今では開発案件でも2〜3ヶ月でのスパンで、
サービスでは使えなかったらもっと安くて高機能なサービス見つけて乗り換えれば良いじゃん位の
サイクルになってきた
開発サイクルの短縮にあわせて以前の開発スタイルを崩して
アジャイル的なチームが必要になる
プログラミング言語やプラットフォームもWEB開発で軽量で稼働環境をインスタントに構築できる
LAMPなどを採用する
ドキュメントも最小限で、納期やコストに対するリスクを最小限にしようとがんばっているのに
・LAMP構成での開発標準がない
・PHPの言語研修環境がない
・最新技術を理解できるメンバがいない
よーし
軽量開発のための標準化を行おう
生成ドキュメントを準備しよう
言語の研修メニューを考えよう
技術を説明できるメンバを育てて社内に展開しよう
あほか
そんなの準備している間にとっくに使い物にならなくなるって
LAMPなんて最新でもなんでもないし
どちらかといえば古いし
PHPなんて知ってて当たり前
いままでプログラムやアーキテクチャやネットワークや論理設計や
じじい達にとって小難しいことばっかりやっている人間をないがしろにして
管理ドキュメントを一日中眺めたりExcelの数値をいじっているやつに
給料多くあげていたから
下のメンバも見習って難しい勉強するよりExcelながめて給料増やしてきた
だから今すげー困ってる
今後は抜本的な改革をしないとSIerは生きていけない
この会社の未来は・・・・
以前は製造に年単位で運用は5年は当たり前だったが
今では開発案件でも2〜3ヶ月でのスパンで、
サービスでは使えなかったらもっと安くて高機能なサービス見つけて乗り換えれば良いじゃん位の
サイクルになってきた
開発サイクルの短縮にあわせて以前の開発スタイルを崩して
アジャイル的なチームが必要になる
プログラミング言語やプラットフォームもWEB開発で軽量で稼働環境をインスタントに構築できる
LAMPなどを採用する
ドキュメントも最小限で、納期やコストに対するリスクを最小限にしようとがんばっているのに
・LAMP構成での開発標準がない
・PHPの言語研修環境がない
・最新技術を理解できるメンバがいない
よーし
軽量開発のための標準化を行おう
生成ドキュメントを準備しよう
言語の研修メニューを考えよう
技術を説明できるメンバを育てて社内に展開しよう
あほか
そんなの準備している間にとっくに使い物にならなくなるって
LAMPなんて最新でもなんでもないし
どちらかといえば古いし
PHPなんて知ってて当たり前
いままでプログラムやアーキテクチャやネットワークや論理設計や
じじい達にとって小難しいことばっかりやっている人間をないがしろにして
管理ドキュメントを一日中眺めたりExcelの数値をいじっているやつに
給料多くあげていたから
下のメンバも見習って難しい勉強するよりExcelながめて給料増やしてきた
だから今すげー困ってる
今後は抜本的な改革をしないとSIerは生きていけない
この会社の未来は・・・・
プログラマとプロジェクトマネージャ
プログラミング言語の話をしていると、「俺、言語全然わかんね」って請負プロジェクトのリーダーが言っていた
プログラム作れない人はアプリケーションの設計はできない(絶対に)
設計できない人はリーダーできるわけがない
リーダーできない人間はプロジェクトマネージメントはできない
なのにプログラムかけないリーダーやマネージャがたくさんいる
SI業界の不思議
マネージャがプログラミングする必要は無いけど、知っている必要はある
リーダーならなおさら熟知している必要がある。
プログラミングする必要は必ずしもないけど
プログラムかけないのに設計もなにもあったもんじゃない
ごくごく当たり前のことで、だれでもわかることなのに
なぜ?
あほなの?死ぬの?
プログラム作れない人はアプリケーションの設計はできない(絶対に)
設計できない人はリーダーできるわけがない
リーダーできない人間はプロジェクトマネージメントはできない
なのにプログラムかけないリーダーやマネージャがたくさんいる
SI業界の不思議
マネージャがプログラミングする必要は無いけど、知っている必要はある
リーダーならなおさら熟知している必要がある。
プログラミングする必要は必ずしもないけど
プログラムかけないのに設計もなにもあったもんじゃない
ごくごく当たり前のことで、だれでもわかることなのに
なぜ?
あほなの?死ぬの?
2011年04月18日
日本企業
技術系ブログといいながら
最近は技術的な記事が少ないな〜
SIerの今後が見えてこない現状で
去年度は日本企業バリバリのSIerにおけるITの方向性を
技術者と違った視点から観察することができた
その中で感じたことは
日本経済の緩やかな成長とIT産業の未成熟さにあぐらをかいて
経営層たちはいままで十分な勉強を怠っていたなと感じる
IT産業自体は最近まで「人」を必要としていたため
SIerはこぞって「人」をかき集めてきた
そして十分な知識を持たない人材を量産しては、大手SIerにぶち込んできた
それでも絶対的に「人」が足りなっかたので中小SIerは生きてこれた
現在では一般の会社員や主婦でさえも簡単にITに関する情報を入手することができる
もちろん、難易度の高いものから低いものまでいろいろあるが、ちょっと検索すれば、難易度の高い技術を分かりやすく提供しているサイトも簡単に発見できる
一般大衆のITリテラシが高くなればもちろんIT業界に求められる人材は、今まで以上の知識を持った人材が必要になる
しかし、ど素人にけがはえた程度の人材を量産し、その人材が勉強もおろそかに昇格していき、首切りもできない日本企業ではどうすることもできない
経営トップが「変わらなければ」とスローガンを打ち立てたところで「どう変わるの?」って言われて返す言葉もない
しかし日本企業は社会主義的な「空気」が全てを支配しているため
「変わる」→「でも失敗したくない」→「今と違うことをやらなければ」→「前やってたことをやろう」
と過去の成功体験をいいことに逆戻りをはじめてしまった
結果「大手SIerや既存顧客へどんどん人を送りこむにはどうすれば良いか」
などと言う間違った方向へ行ってしまった
もう結果は出始めていて、客先常駐組やSIer常駐組のプロジェクト凍結による本社帰還が始まっている
目に見えて状況が悪化しているにもかかわらず、一度決まった方針は「年度」をまたがないと変わらない
こんな状況のなか自分はおとなしく「空気」となって状況を見守るしかないポジションに追い込まれてしまった
自分はどうでも良いが若い社員たちがかわいそうだな〜
最近は技術的な記事が少ないな〜
SIerの今後が見えてこない現状で
去年度は日本企業バリバリのSIerにおけるITの方向性を
技術者と違った視点から観察することができた
その中で感じたことは
日本経済の緩やかな成長とIT産業の未成熟さにあぐらをかいて
経営層たちはいままで十分な勉強を怠っていたなと感じる
IT産業自体は最近まで「人」を必要としていたため
SIerはこぞって「人」をかき集めてきた
そして十分な知識を持たない人材を量産しては、大手SIerにぶち込んできた
それでも絶対的に「人」が足りなっかたので中小SIerは生きてこれた
現在では一般の会社員や主婦でさえも簡単にITに関する情報を入手することができる
もちろん、難易度の高いものから低いものまでいろいろあるが、ちょっと検索すれば、難易度の高い技術を分かりやすく提供しているサイトも簡単に発見できる
一般大衆のITリテラシが高くなればもちろんIT業界に求められる人材は、今まで以上の知識を持った人材が必要になる
しかし、ど素人にけがはえた程度の人材を量産し、その人材が勉強もおろそかに昇格していき、首切りもできない日本企業ではどうすることもできない
経営トップが「変わらなければ」とスローガンを打ち立てたところで「どう変わるの?」って言われて返す言葉もない
しかし日本企業は社会主義的な「空気」が全てを支配しているため
「変わる」→「でも失敗したくない」→「今と違うことをやらなければ」→「前やってたことをやろう」
と過去の成功体験をいいことに逆戻りをはじめてしまった
結果「大手SIerや既存顧客へどんどん人を送りこむにはどうすれば良いか」
などと言う間違った方向へ行ってしまった
もう結果は出始めていて、客先常駐組やSIer常駐組のプロジェクト凍結による本社帰還が始まっている
目に見えて状況が悪化しているにもかかわらず、一度決まった方針は「年度」をまたがないと変わらない
こんな状況のなか自分はおとなしく「空気」となって状況を見守るしかないポジションに追い込まれてしまった
自分はどうでも良いが若い社員たちがかわいそうだな〜