「詳細設計書F**k」「SIer、Sxxt」的なお話は定期的に（日常的に？）ネットやTwitterのタイムラインを賑わせているように思います。つい先日もそんな感じのblogエントリが少しバズっているのを目にしました。 よくdisられる感のある詳細設計書*1。これは作られるのでしょうか。必要だから？ではなぜ必要？ 『最近の開発では詳細設計書は必要ない』というニュアンスの発言も耳にします。では昔は必要だったのでしょうか。そもそも何のために生まれたのでしょうか。 ……話しは変わりますが、今私はちょうど、年度末のアレコレでとても現実逃避したい気分だったりします。ということで、気分転換に、昔のことを思い出しながら与太話を書いてみたいと思います。 これから書くお話は、以前 ― 正確な時期は覚えていませんがおそらくは10年前くらい ― 私がSIerに勤務していたころ、今でも尊敬している大先輩のエンジニア

これからご紹介する私の試みはなかなか難しい側面があり、物議をかもすかもしれません。また、お見せするのは初めてなので完璧とは言えないかもしれません。私はソフトウェアエンジニアのスキルとその影響力を評価するシステムを開発しようとしています。少なくとも、プログラマが成長していく理想的な成長過程を大まかに描いてみようと思います。評価スコアは0.0から3.0まであり、それぞれの数字は専門能力を開発していく際の出発点を表しています。 このシステムは主にビジネスの観点から見た、ソフトウェア業界が求めるものに基づく 実務的な スケールです。数学的な才能や高速アルゴリズムを書く能力、Linuxカーネルの内部構造に関するプログラマの理解の深さなどを評価するスケールではありません。もちろんこうした能力は重要ですし、通常、エンジニアのスキルとともに伸びていく能力ですが、私のシステムが焦点を当てたいのはそこではあり

前書き 「一緒に働いている以上、プログラマのことを理解して仕事をしたい」そう考えている企画・ディレクションの方は経験則的に少なくない。 ノンプログラマから見て、プログラマの仕事はイメージが湧きづらく、何故その工程にそこまでのコストをかける必要があるのかわからない事が多い。 プログラマは作業の必要性を説明してくれるかもしれないけれど、専門用語も多いしイマイチピンとこなかったりする。 ここで重要なのはまさに「イメージ」だと思う。すなわちイメージを提供するための良質なメタファーだと思う。メタファーが良質であれば より直感的に理解できる。 実際メタファーの力はバカにならない。「Chef」も「Jenkins」も それぞれ 統一的な世界観が学習者の直感的な理解を後押ししてくれる。 というわけで、今回から数回に分けて なるべく「技術的な話」をせずに イメージを想起しやすいストーリーを導入することで プロ

プログラミングを生業としていると、人のコードを引き継いで開発するなんてこともままある訳ですが、そういうときに一番困るのは「使われていないコード」だなー、としみじみ感じます。 使われていないコードがもたらす弊害 特に動的言語で書かれたコードというのは前触れ無く呼び出される可能性があるため、本当に利用されていないのかどうなのか、きっちりと調べあげるのは困難なケースがあります。例えばrubyであれば、method_missingでキャッチしてsendで動的に処理先を振り分けるなんてことをしていると、単純にgrepして利用状況を見るだけでは不十分な場合があります。 そういう意味では「使われていないコード」というよりは、「使われているのか使われていないのかはっきり分からないコード」という方が適切な表現かも知れません。 そういった「はっきりと判断のつかないコード」がある状態だと何が問題なのかと言うと、

多重下請け構造が社会悪になる、というのは場合によってはそうでしょうけどね。 そもそも「事務システムのIT化」ってのは効率化であり、効率化とはともすればマージンを削ることで成り立っているわけですから、その部分におけるIT化ってのは本質的にはリスクの移転（人的ミスやコストからシステムリスクへの）に過ぎないんですけど、もちろん十分な費用対効果があることによって成り立っているわけです。 んで、最近やっているような事務系のシステム投資でどんどん効率化を目指していくってのは業績不振だからリストラしているのと似たような負の効果が発生していることに長い間みんな気づいていなかったんだけど、ようやく問題が出始めた、というのが現状なんだと思うんだよね。 多重下請け構造が昔より問題になっているのはそういう綻びの一端なんだよね。 その結果、同じような作業をしても、どの階層にいるかで給与レンジは大きく異なり、業務内容

日本のIT業界を「SIガラパゴス」と言う前に知っておきたい海外ベンダ事情 - プロマネブログ 前回の記事を書いたあと、うっかりしていたことに気づいたので、追記です。 ユーザ企業とベンダ企業との関係については、他国との比較を色々書いたのですが、多重構造について深堀り書くのを忘れてました。 米国の事情についてもうちょい書きます。 下請構造が崩壊したアメリカ 端的にいうと、米国にも日本と同様の下請構造は過去ありました。 日本と同様に、元請けが大規模な案件を受注し、それを２次３次請けにシステム開発再委託するという構造です。 政府調達元請けの平均60.4％が下請け及び補給品に再投資され、それらのさらに平均83.2％が3次へ再投資、さらにその83.2％が再々投資、と繰り返される事により、初期調達額$369M（元請けのみ）は、上記再投資の構造より算出される係数2.06を乗ずる事により、$759Mと推計さ

Photo by Jonathan Kos-Read 今回のpaiza開発日誌は片山がお送りします。 SIerについて語られる際にIT業界の「多重下請け構造」についての問題点が良く取り上げられますが、「多重下請け構造」がITエンジニアにとってどのような問題点があるのでしょうか？ その点について今回は少し整理してみようと思います。 ■「多重下請け構造」とは何か 説明するまでもないかもしれませんが、「多重下請け構造」とは、受託システム開発において、発注者から直接仕事を請け負った元請（たいていの場合が大手SIer）が、請けた仕事を切り出して2次請け、3次請け、4次請けと仕事を下ろしていくピラミッド構造の事を言います。 良くある例で言うと、元請は要件定義や概要設計等の上流工程を請負い、開発・実装などの下流工程は2次請けに委託する、というような構造です。2次請けは自社リソースで開発を賄えない場合に3

「自動化テストが無いコードはレガシー」 「バージョン管理システムで変更履歴を管理しよう」 「継続的インテグレーションで問題の早期発見」 「オブジェクト指向で保守性の高いコードを」 「関数型言語で抽象度の高いコードを」 プログラマやってるときは大事だと思ってたけど 小さい会社を作って経営側に回ってから糞だと思うようになったわ。 上記を全部やっても生産性2倍も変わらん。 バージョン管理はdropbox使って手動で管理、テストも定期的に手動でやらせてる。 コードがぐちゃぐちゃで機能追加が無理だったらサビ残させて作り直しさせればいいし。 （今のところアドホックな拡張の繰り返しでなんとかなってるけど）

デブサミ関西基調講演資料

Excelスクショ問題について周りの方へのお願いと、今職人となっている方への励ましの言葉（元職人より） 2014年8月3日日曜日 ITニュース うつ病 最近一部で話題になっている「SEがテスト工程で画面のスクリーンショットをExcelに延々と貼り続ける作業」について、実際にスクショ貼り職人を経験した自分としては、何か残しておかねばと思い、この記事を書きます。 自分はSEでしたが、うつ病でもうすぐ2度目の休職に入ります。Excelスクショ職人を経験しています。そんな自分が、「Excelスクショに対して疑問を抱いている方」と「今現在Excelスクショ職人な方」へ、お願いと励ましの言葉を述べさせていただきたいと思います。 【参考】 SIerの闇・Excelにエビデンス貼付け - Togetterまとめ あるシステムを開発したら、必ずテスト工程があります。プロジェクトによっては、全くユーザーインタ

「動けば良い」と言う人はエラーが起きてから「動かないじゃないか」と文句を言う。仮令、その人の操作が間違っていたとしても言う。ある「動けば良い」と言う人が酷いバグで右往左往しているのを見て(少なくともその人の)原因に思い当たった。 その人はコードをデバッガで追うのが大好きだ。で、どこでSEGVが出たかを突き止めて、SEGVの箇所にエラーチェックを追加して修正完了とする。その結果、次々と別の箇所でSEGVが発生したり、エラー時のリカバリに失敗したりしている(ここで右往左往)。 NULL参照のエラーが出たということは、NULLであるべきでない変数にNULLが入っている、という状態になっているはずだ。この場合、NULLが代入された変数を参照した箇所は落ちるべくして落ちたに過ぎない。本当のバグはNULLであるべきでない変数にNULLを代入した箇所にある。 つまり、変数が取り得る値は何か、という観点が

「見積もり」は、ソフトウェア開発における大きなテーマであり、ソフトウェア工学における最重要課題の1つでもあります。 前回からお届けしている“見積もり・シリーズ”では、「見積もりの目的（正確に見積もるだけでは不十分）」「見積もりの具体的な方法（精度を上げるため、少なくとも2つ以上の方法で見積もる必要がある）」「見積もりの応用（見積もり値に合わせる制御と再見積もり）」「見積もりの調整（状況に応じて開発量とスケジュールを再見積もりしなければならない）」について、具体的に解説していきます。 シリーズ2回目となる今回は“昔の見積もり技法”を解説します。見積もりを含めたプロジェクト管理は、過去30年以上、ほとんど進歩しておらず、

元々は、前職の雇用形態を正社員から契約社員に変わることになったのがきっかけで、 独立する決心をし、会社役員にもなった訳ですが、おかげさまで早くも3年が経とうとしています。 今回は3年間に起きたことを一通り書いてみたいと思います。 ★noteにも書いてみました。投げ銭的に購入して頂けるとうれしいです。 最初に行ったこと始めるにあたりやったことはこれくらい。始めるのはとても簡単なんですよね。 開業届、青色申告の申請税務署に、開業届と一緒に用紙1枚出すだけの簡単な手続きです。 青色申告は複式簿記の知識、手間が必要になりますが、65万円の控除はでかいのです。 事業用銀行口座を作り、ネットバンキングの契約をするプライベートの口座とは別に、事業用の口座を作りました。 現在メインで使っているのは、三菱東京UFJ銀行です。クレジットカードを持つのをやめたので、VISAデビットカードを作り、それで経費を払い

誕生日に id:aereal さんに頂いた本。ありがとうございます！ UNIXという考え方―その設計思想と哲学 作者: Mike Gancarz,芳尾桂出版社/メーカー: オーム社発売日: 2001/02メディア: 単行本購入: 40人 クリック: 498回この商品を含むブログ (141件) を見る たいへん有名な本。原著は1994年に書かれていて、古典という感じ。 大きな一枚岩のソフトウェアよりも、cat、sort、uniq、sedやawkのような小さくて便利なツールを組み合わせることが好まれる。UNIXの世界には、こういった、UNIX開発者やユーザがが大事にしている哲学があり、そのおかげで、この本が書かれた1994年、そして現代においてもUNIXが広く使われることになった。この本では、そういったUNIXの考え方のエッセンスの部分を9つの定理にまとめてとして詳しく教えてくれる。 スモール

『「納品」をなくせばうまくいく』を読み終えました。この本はソニックガーデンという、とあるドメインで話題のソフトウェア開発会社の話が書かれています。著者の倉貫さんとは何度か遊ぶ機会があり、以前からいろいろお話を伺っていたのですが、今日は本書を読んだ感想を交えながら、自分なりに感じたことをぼろくそに書いてみようと思います。 システムインテグレーターというカースト制度を学ぶ 僕は新卒で中堅のSIerに就職しました。ほとんどが2次受けで、外資系のSIerに常駐してシステムを作ってました。その現場は、想像していたのとはちょっとちがって、X次受けという透明なカースト制度がありました。 「これ作っといて」みたいな感じで仕事を丸投げする人や、ろくにシステムもつくれないのに上流工程とやらで論理破綻した仕様書を作る人など、プロフェッショナルってなんだっけ？ と考えさせられることばかりです。 また、1次受けだと

iOS アプリの構造がどのようになっているのか理解しなくても簡単なアプリを開発することは可能です。実際自分も iOS アプリの開発をはじめたことろはそうでした。しかしアプリの構造を理解していないと複雑なアプリ、例えばタブとナビゲーションを組み合わせたアプリやマルチタッチやジェスチャーを使ったアプリなどを作ろうとしたときにハマることが多いです。 本記事では iOS アプリの構造について説明します。 一番単純なアプリの構造 それでは iOS アプリの中でも一番単純なアプリの構造がどうなっているのか見てみましょう。 iOS で一番単純なアプリは画面を一つ表示するアプリです。画面を一つ表示するアプリはシングルビューアプリケーション(Single View Application)といいます。 ラベルもボタンもなく、ただ真っ白な画面を表示するだけのアプリがどのような構造になっているのかみてみましょう

ネタ元: 「エンジニアをつくる」という理念掲げていたら、エンジニアが社内からいなくなった件 | 新田章太の「エンジニアをつくる」ブログ 話の発端は、 俺がDMTCについて知ってること，またそれに対する所感 - 職質アンチパターン がFacebookで話題になっていて、やばいなぁと思っていたら主催者もやばかったみたいな話。 内容自体ただヤバイんだけど、その中でも明確にツッコミを入れておきたい部分があった。 僕らの強みはDMTCを通じて、沢山のお客様とのつながりがあること このつながりを活かして、 国内外のIT企業で働くエンジニアのスキルを定量化しよう というひとつのテーマにいきつきました。 http://maximum80.me/archives/821 この部分についてFacebookで俺はエンジニアをバカにしてるって書いたけど、もうちょっと具体的に落としこもうと思った次第です。 ものさし