なぜシステム会社の見積りが「ボッタクリ」に見えるのかを、きちんと説明する。
どうもしんざきです。曲がりくねったSQLを読んで、モニターを威嚇しつつ不要なjoinを削除しまくる仕事で主に生計を立てています。 こんなまとめを読みました。 某大手企業の本社を辞めるという人『古い会社は社内の体制も古い。癒着してるシステム会社も全然ダメでテキストの左揃えを右揃えに変えるだけで300万取られる』（現在は非公開） ワイの妹ト○タの本社やめて転職するらしいんだけど、「古い会社は社内の体制も古くてダメ。癒着してるシステム会社も全然ダメで、テキストの左揃えを右揃えに変えるだけで300万取られる上、バグ（仕様）だらけで仕事にならない」って言ってたの印象深い。 これ、もともとの話の情報量が全然なくって、何のシステムの話かも分からなければシステムの規模も分からないので、300万が高いのか安いのか妥当なのか、というのは勿論なんとも言えないです。 もしかするとこれはぼったくり案件なのかもしれま
量産型プログラマを撲滅したい
プログラマの生産性の差は、出来る人と出来ない人で10倍とも100倍とも言われる。そんな馬鹿な、と思われるかもしれないが、事実だ。 むしろ、一緒に働かせると、出来るプログラマが、下手に作られたプログラムの修正をしなければいけなくて、全体の生産性を落とすことになる。 つまり、出来ないプログラマはチームで働くと、生産性をマイナスにするのだ。厳しいことを言えば、いない方がマシなのである。 ソフトウェア開発に猫の手はいらないのだ。 では、出来ないプログラマとはどんな人たちか。 コピペで書くプログラマだ。他で動いているプログラムをコピペして、なんとなく直して書いているプログラマだ。 なぜプログラムが動くのか、どう書けば動くのか、わかっていない。 ただ沢山のプログラムを書くだけの量産型プログラマだ。こういう人のプログラミングは、デバッグさせてみて、横で見てるとすぐにわかる。 まず、エラーメッセージを見な
硬直しきったプロジェクトで働いた思い出 - tehepero note(・ω<)
2015-04-29 硬直しきったプロジェクトで働いた思い出 ふと昔いたプロジェクトについて思い出したので書く。 経歴 2006-2009 中小SIer 2009-2012 フリーランス 2012-現在 サイバーエージェント 今日の話は中小SIer時代のこと。本エントリでは所属会社と呼ばせてもらう。 所属会社について 社員30名くらいで、当時で設立8年目くらい。 自称ベンチャー企業 自社製品もあったが、基本客先に常駐するスタイル。いわゆるSES契約というやつ。月に一度、帰社日というやつがある。 プロジェクトジョインの経緯 2008年当時、体力の無い所属会社はリーマン・ショックの影響で火の車。1・2年目社員の多くが社内失業者に。 会社としては、社内失業者を何とか現場に出したい。3年目以降で会社の主力メンバーと共に、社内失業者がバーターでジョインできる現場が優先された。 所属会社の1年目若手（
泥沼プロジェクト振り返り
はじめに ちょっと前まで結構激しく泥沼化したプロジェクトにいた。 その頃はプロジェクトも僕も相当疲弊していて、何も考える時間がなかった。 ある程度、月日が経って今なら もう少し客観的にあの頃のことが考えられるかなと思い書いてみることにする。 振り返りをし、自分としてもプロジェクトとしてもどうあるべきであったかとか そういう立派なことが考えられればいいのだが。 とかく、Slide Shareとか世の中は成功事例は多く発信される。 けど、失敗事例のほうが共通して当てはまったりする。 前提 ・古典的なウォータフォール ・古典的なStruts1系ベース内製フレームワーク ・Java SE 6 ・QAとかいない ・デザイナーとかいない ・フロントエンドエンジニアとかいない アンチパターン 当時のプロジェクトを振り返って、明らかにこれは駄目だっただろというところ。 ◆プロジェクト全体 ・決定者がいない
「何を使って設計書を書いていますか？」と尋ねよう: 設計者の発言
業務システムの複雑膨大な設計情報を効率的に管理するために、Excelのような汎用ツールではなく、専用のCADツール（システム開発用の設計情報管理ツール）を使おう。そのように主張しているのだが、反応はさまざまだ。もちろんほとんどの技術者が賛同するのだが、所属組織にそれを導入できるかどうかになるとビミョーだったりする。 専用ツールを用いることの効果のひとつが、設計の巧拙がはっきりする点だ。スキルレベルの高い組織であればそれでいいだろうが、そうでない組織は現状維持を望むかもしれない。Excel方眼紙（細かい方眼紙状に設定されたExcelシート）で設計書を書くやり方は蛇蝎のように嫌われているが、それが設計の拙さを見えにくくするための隠れ蓑として役立っていることがある。彼らはExcel方眼紙がもたらす壮大な無駄を棚に上げ、「新たなツールを導入すれば、余計な学習コストがかかる。だいいち、ツールベンダー
DevOpsなんてくそくらえ - razokulover publog
先日こんなことを言われた。 「テストを書いた成果を見せよ」 と。 ショッキングだった。 経緯 わたしはいまレガシーなコードに囲まれている。 もちろんテストもほとんどないピカピカのレガシーちゃんである。 レガシーちゃんは「Ctrl+F5 & tail -f 駆動開発」により開発が進められており、日々進化している。 このまま進化をつづけるといつかモンスターになり(もう軽く怪獣っぽいが)、開発スピードがどんどん遅くなり、メンテナンスやバグつぶしでエンハンスとなるような開発ができなくなる。このままじゃマズい...。 こういった事態を一新すべく、手探りながら私含め数人の先輩たちで「DevOps」に取りかかることになった。 バズワードにもなっているが「DevOps」とは、 従来型のシステム管理や調達（ITILを含む）といった、保守的でプロセスを中心に据えた運用からよ>り戦略的でアジャイルな、そして自動
コンピュータシステムを「ビジネスとしての系(システム)の一部」として見ることが出来るかどうか - がるの健忘録
相変わらず「金の話とエンジニアの話の真ん中くらい」をふらりぶらりしているおいちゃんでございます。 ふと、偶然ではあるのですが。 ちょいとばっかり「壮絶な」ものを拝見したのと、そこに起因して随分といろいろ、考察できるネタがあったので。 その辺の考察の…途中経過、程度のものを、Blogにて。 とりあえず今回俎上に挙げるのは２タイプ。どちらにも共通しているのは「DRYなにそれ？ レッツコピペ駆動開発！！」な行動原理。 A)複数個所のテストだろうがどんだけ単純作業の連打だろうが「僕は」黙々と丁寧に根気よく続けます B)テスト？ なにそれおいしい？ 理想論として耳にしたことはあるけど、現実、テストなんてやってらんないよ？ Aは、割と典型的な「無能で勤勉な人間」。 http://d.hatena.ne.jp/gallu/20081114/p1 の話を思い出すのであれば、彼らは速やかに[除隊 | 馘首
“素人集団”が強みに 基幹システムを自社開発するハンズラボ
2013年4月に設立したハンズラボは、一見すると“非常識”と思われるような取り組みによって事業の拡大を図っている。 東急ハンズのIT子会社であるハンズラボが、基幹系など自社開発したシステムをクラウドサービスに移行する作業に取り掛かっている。年内に作業を完了するとともに、自社開発の経験を生かして外販に乗り出す。最大の売りは、オーダーメイド型システムを早く、安く作り上げること。得意とする小売業にアプローチする。 業務に精通するITメンバーたち 2013年4月に設立したばかりのハンズラボには、約30人のエンジニアらがいる。多くは、東急ハンズ社内の公募によって、前身のIT部門に異動してきた20代から60代の社員。彼ら、彼女らは業務に精通するが、ITの専門家ではない。そんなITの素人集団で、2008年からシステムの自社開発を始めた。（関連記事：東急ハンズ、ITソリューション会社「ハンズラボ」設立 ク
なんでもかんでもクラウドにあげるのか？ - 急がば回れ、選ぶなら近道
某エントリーの話で、「なんでもかんでもクラウド化なのか？」というお話もご意見も多数頂戴いたしまして。一応念押しですが、そういうつもりはまったくないですよ。以下、個人的な補足メモです。会社の意見ではありません。一応、会社の公式声明は「できるものは、とっとクラウド化したほうがいいですよ。」です。 クラウド化の是非については、いろいろあるでしょう。ユーザーの所属する産業毎にシステムのあり方・考え方は違うでしょうし、当然クラウド化すべきだという意見や、いやそもそも無理があるという意見もあると思います。ただ、今までのように先例がないから無理、という理屈は通用しなくなっているのが現状でしょう。その意味では無茶な理屈ではなく、普通に選択肢としてクラウド化が候補になっている、と思います。その上で、クラウド化しない、するという議論が普通にできる状態になりつつあると思います。 そんな中でいろいろ思うところをち
コードクローンと品質 - プログラマーの脳みそ
コードクローンと品質について話題になっている。元ネタはこちら。 ソースコードの品質についても、みずほ証券は問題を指摘している。今回のバグがあったプログラム全体について、「ソースコードの著しい重複が見られるなど、エラーの潜在する率が極めて高い作り方をされており、品質が極めて低い」と主張。これに対して東証は「コードクローン（記述の重複）を含むプログラムは、含まないプログラムと比較して信頼性が高いことが定量的な研究で裏付けられている」と反論した。 ［論点3］どんな開発手法を適用すべきか | 日経 xTECH（クロステック） この「コードクローンを含むプログラムのほうが信頼性が高い」というのはどこからきた話題なのかという話。 僕が昔読んだ論文で似たような話があったなと思って探してみた。 コードクローンに基づくレガシーソフトウェアの品質の分析(PDF) 本論文では，20年以上前に開発され，拡張COB
人月を超えるエンジニアリングの未来 - GoTheDistance
ご無沙汰してしまっているmark-wadaさんより問題提起を頂いたので、最近話題になった「超高速開発」と絡めて書いていきます。 もしSIerのエンジニアがジョブズのスピーチを聞いたら（１） - Wadit Blog. もしSIerのエンジニアがジョブズのスピーチを聞いたら（２） - Wadit Blog. もしSIerのエンジニアがジョブズのスピーチを聞いたら（３） - Wadit Blog. もしSIerのエンジニアがジョブズのスピーチを聞いたら（４） - Wadit Blog. 僕のエントリに対する和田さんのご指摘をまとめると、ソフトウェアを作るにあたっては上流と下流の断絶があるのはマイナスなのは理解できるし、コードを書く時にはその断絶があると望むものを作ることは出来ないのも確か。だが、システムを作る時にはそもそもレイヤーをもう１つ上に上げるべき。スクラッチでコードを書く必然性など無い
はてなブログ | 無料ブログを作成しよう
うめぇヨーグルトソースでもいかがですか。個人差にもよりますが。もしよろしければ。 お久しぶりです。 最近うんめぇ〜と思ってるヨーグルトソースがあるので、書いていこうと思います。 ヨーグルトとハーブ類をもりもり使うので、そういうのが食べられない方にはうんめぇソースではないです。ごめんなさい…。もしよろしければお茶だけも…旦~ 【用意する…
Kingfile Driven Developmentと継続的デリバリー - GeekFactory
KDD（Kingfile Driven Development）は、キングファイルと大量の紙をコミュニケーション手段とする開発手法である。日本のSI業界で広く導入されており、デファクトスタンダードとなっている。キングファイルの重厚感はエグゼクティブを中心に好印象を与えることが多く、顧客満足度の向上に貢献している。「顧客が最も欲しいのは重厚なキングファイルである（キリッ」と結論付けている調査レポートもある。 キングジム キングファイルSD A4S 青 1470アオ 出版社/メーカー: キングジムメディア: オフィス用品 クリック: 2回この商品を含むブログを見る もはや常識となっているKDDであるが、近年のシステム開発の複雑化や短期化に伴い、キングファイルの出荷（デリバリー）に要する時間が問題視されるようになってきた。多くのプロジェクトではプロジェクトもしくは工程の最終段階にキングファイルを
冷たい方程式（1） 技術力は勘定に入れません：Press Enter■：エンジニアライフ
ふつーのプログラマです。主に企業内Webシステムの要件定義から保守まで何でもやってる、ふつーのプログラマです。 電話が鳴った。 あたしはワンコールで受話器を取り上げた。別に待ちかねていたわけではなく、朝から続くしつこい頭痛に干渉する電子音を一刻も早く断ち切りたかっただけだ。 「はい、日比野です」 『受付です。ホライゾンシステムサービス株式会社様がいらっしゃいました』 「すぐ行きます」 あたしは受話器を置いて時計を見た。14:12。約束の時間より約10分の遅刻だ。 ――まあ、遠いから仕方ないか 腰を上げたとたんに立ちくらみに襲われた。椅子にへたりこみそうになるのをぐっとこらえて、窓際の席でヒマそうにしている磯貝課長に呼びかけた。 「課長、ホライゾンシステムさん、いらっしゃいました」 「あいよ！」 磯貝課長の脳天気な返事を後頭部で受けておいて、あたしは頭を揺らさない程度に早足でフロアを出た。さ
三版開発の勧めっていうか考察 - がるの健忘録
いくつかの元ネタがあるのですが…とりあえずわかりやすいところで、ここ。 アジャイルだウォーターフォールだいう前にさぁ http://msg.errobj.info/weblog/0902/000845.html 一見「これはこれで発注側の本音だよねぇ開発側も真摯に受け止めないといけないよねぇ」って思うのだけれども、冷静に読みつつそこに「経験からくる背後周囲の状況を重ねあわせる」と、概ね -検閲削除- な感情を呼び起こします。 最終的に「好意的な戦略へのプレゼン」にしたいので、王道にしたがってまずは「気になるところ、まずい点」から。 顧客の出した要望は開発側でまとめてくれよ。顧客が自分でまとめた要望なんて穴だらけなんだよ。 この要望でどんなものが出来上がるのか、開発側は頭ん中にすぐに組み立てられるだろうさ。けど顧客側にはわかんないんだよ? どんなものが出来上がるのか想像もつかないのに、最初か
SIerがExcel→Javaのコード自動生成をPGに押し付けるのは善か悪か？ - 達人プログラマーを目指して
以前Java EEや.NETはCOBOLやVB6よりも本当に生産性が高いか？ - 達人プログラマーを目指してにて 何でもかんでもとにかく自動生成させたがる。特にExcelなどの表から大量のクラスを自動生成させるなど。たいていそのようにして生成されたクラスはゴミで保守も大変なものになりがちです。 ということを書いたことに対して、会社の忘年会で上司や同僚の間で議論が盛り上がって興味深かったので、ここで自分の考えを再度整理させていただきたいと思います。（忘年会で1次会、2次会の間ずっとこういった話題で話が盛り上がるというのはかなり特殊な部署なのかなとは思います。「SIerのやり方はXXだ」一口に言っても、それは全体的な一般傾向を表しているのであって、実際はさまざまな人々がいることを忘れてはなりません。あくまでもそういう意味で捉えてください。） それで、私の周りにはプログラミング好き、技術好きが多
不可能へのチャレンジ - ( ・ω・)ノ＜しすてむ開発。
最近の仕事ではこれでもかーーってくらいにレビューがある。 紙を作る基本〜詳細設計ってフェーズから ソースコード作る工程も。 もーあれじゃね？ クラス図とシーケンス図まで作ってなお、ソースのウォークスルーとか無駄じゃね？ なんだか心配で心配で心配でしかたがなくて、 心配していないほうがよかったと後からしみじみ思うようなことをしていると思う。 いや、している。 ちなみに、いろんないわゆる設計書をつくり、 ソースも作らないうちからクラス図をつくり、 「これでリスク回避だ」っと思い込むために苦労を背負い、 あとは製造工程だ！なーんて言っているけれども 設計図の通りに作ってテストすれば考えることなく出来るー っと思惑通りになんて行っていない。 製造ではなく製作している。 OOPとしてあるべき姿を模索すべく単機能にまとめるためにクラス作るとか インタフェースを定義しなおすとか、アダプタクラス用意して出
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
https://twitter.com/sotarok/status/1779070109577019789
まとめよう、あつまろう - Togetter
他社にノコノコ話を聞きに行くこと、あるいは引っ込み思案がもたらす致命的な損害について：プロジェクトマジック：オルタナティブ・ブログ
