Life is beautiful

なんというかソフト業界だけでなく半導体業界でもsatoshiさんのいう通りの状況になってます。RTL(Register Transfer Level)設計をしたことがない人間が旨い仕様なんか作れる分けないのに、無意味に分業し、しかも、RTLやSystemCによる「テスト」を軽視。何度も繰り返しが起こり、かえって工数を増やしてます。仕様検証を人手、しかも基本的には机上／目視チェックのみでなんとかしようという考え方。複雑な規格に対応するんでなければこんなやり方でもうまくいくのかもしれませんが。
一部だとは信じたいです。。。

僕も同様に就職活動中の身ですが，この時期だけにいろいろな会社の話を聞くとやはりドキュメンテーションに関する時間がほんとに長くて，そこらへんで時間を調整しないと時間が減ってしまい人月が減ってしまうということを聞きました．いろいろな技術を習得してコーディングの効率が良くなっても結局時間が減ってしまうと予算が減ってしまうということなんでしょうか？

＞UIE Japan（もしくはUIE）では新卒採用は行わないのでしょうか？

UIE Japanでは、新卒も採用しています。もし興味があれば、uiejapan（アット）uievolution.comまで連絡を下さい。履歴書だけでなく、ブログだとか自分が運営しているウェブサイトなどの情報も送っていただけると助かります。

いつも拝読させていただいておりますが、初めてコメントさせていただきます。

某家電メーカーに勤めておりますが、satoshiさんのおっしゃることを明言するソフトウェアマネージャーはおりませんし、少なくとも理解している人とは３人ほどしか出会ったことがありません。自分としては、「プログラムを書く」「詳細仕様書を書く」に加えて、「書いたコードのテストをする」ことを開発者が行うことが全体の開発効率を上げることにも、開発者のモチベーションを上げることにもつながると思っています。開発者は、「動いた」ことに満足するだけでなく「すべてのケースで問題がない」ことを喜びとしたいしするべきです。
もちろん、開発者は抜け穴を見落とすことも多いのでさらにその後の段階としてテスト技術者が綿密なテストを行うことも必要ですが、「プログラムを書く」ことで次の人に渡す人も多く、とがめる人は少ないことが品質の低下につながっていると思っています。

そもそも、IPAのがソフトウェア技術者試験の試験区分と評価基準に定めている内容が、「プログラムを書く」ことと「詳細仕様書を作る」ことを分離したような内容になっており、経済産業省の影響の大きいIPAがこのようなことになっていることを鑑みるに、国のリーダーシップを取る人がsatoshiさんのような視点でものを見ている人があまりに少ないということではないかと思います。

自分がおもっていることにあまり自信がなかったのですが、satoshiさんのような第一線で開発されていた、いや開発されている方が明言されると重みが違いますね。そういうことを明言できるソフトウェアマネージャーがいない会社は今後落ち込んでいくだろうと危機感を覚えました。

以前からこちらをのぞかせていただいておりました。
あまりにも心が動かされたので、はじめてコメントさせていただきます。
私は１５年以上システム開発に携わって参りました。
satoshiさんがここでかかれていることは、的のど真ん中を射てると思います。
私も長年、へんてこな構造に悩まされてきた一人です。
ソフトウェア業界に心の病が多いのもこういった構造が少なからず影響しているとさえ感じています。
「システムを造る中で、一番偉い人は実装する人である」が私の信条です。
（偉いというのは、必ずしもお金のことをいっている訳ではありません;-)）

　以前の業務で売上情報共用Webを発注した時のことです。仕様固めに発注先にお邪魔しエンジニアの方と打ち合わせた時に、「東北の小さな会社がコーディングしているのでこの点の変更は間に合うかわからない」、と言われたのにはびっくりしました。それなりの品質テストに合格させてベンダーブランドとして出荷されるのでしょうが、社内用語とかもわかっててもらっていたエンジニアたちが開発コーディングするのではなかったのにがっかりした(不安を感じた)覚えがあります。

　予想外に沢山の方々からコメントをいただき、感謝しております。しかし、shiroさんの「脚本の作り方も同じ」という点は興味深いですね。ちなみに、それで思い出したのですが、「キャリー」などのベストセラー作家のスティーブン・キングも同じようなことを言っていました。あまり最初からストーリーを決めつけて書くよりも、登場人物の性格設定や状況設定だけを最初に定めておき、後は登場人物自身に物語を作らせるようにすると良いものが出来る、という話だったと思います。

　ソフトウェア作りではさすがにそこまではしませんが、最初にたてたアークテクチャをコードに落とし込む段階で、設計を変更した方が素直にコードが書ける、コードがシンプルになる、ということが必ず生じます。そこで柔軟に設計を変更できるかできないかで、最終的に出来上がってくるものの出来が大きく違って来ます。私はその過程が良いソフトウェアを作るためにとても大切だと信じているし、そこにこそエンジニアが腕を発揮できる「楽しみ」があると思っています。

　その一番大切な部分をないがしろにする、上流→下流というソフトウェアの作り方では、良いものも作れないし、人も育たない、と感じている私です。

すみません。トラックバックしたら文字化けしてしまいました。
ざっくり削除しちゃってください。

>十分な経験を積んだエンジニアは、その段階でのものが「仮設計」でしかないことを良く知っている。
>だから、その段階で詳細設計書を書くような時間の無駄使いはせず、すぐにプログラム（もしくはプロトタイプ）の作成にかかるのである。

非常に共感しました。

地方でオープンソース系エンジニアをやってると、そんな日本でも流れが変わりつつあるのかなと思います。というのもエンタープライズ系ベンダーのシステムリプレースを請け負うことが増えているからです。

リプレースすべく彼らのシステムを拝見すると、立派な社名とは名ばかりのずさんな内容に唖然とするよりも笑ってしまうことが多々あります。たぶん彼らも、条件さえ許せばもっといいものが作れるのでしょうが、いかんせん価格と品質が釣り合っていません。もしかしたら「東京の」とつくだけでありがたがる地方相手の仕事だからなのかもしれませんけどね。さらに「弊社以外のベンダーが入ると品質が保証できません」という脅し文句のせいか、納入先もオープンソース系への転換に二の足を踏んでいるようです。

それでも彼らの半分以下の価格で倍以上の性能を実現できることが多く、最近はお客さんも増えています。この業界は最先端であるようでいながら、護送船団的構造が色濃く残っているようなので若い人にはオープンソースの世界に飛び込んでどんどん価格破壊を進めてほしいです。

##身の回りにはパソコン黎明史に出てきそうな博物館級のマシンで動くシステムが、「誰もメンテナンスできないけど、とりあえずまだ動いている」状態でたくさんありますよ。失われた10年で地方にばらまかれた公共投資がいろんな形で流れ込んでいるようです。

中島さんの言っていることは家電業界ではそれほどでもないような気がします。
私は大手5～6社の開発の現場を見る機会があったのですが、開発の流れとしては3パターンありました。

①試作機が既にある開発
(1)お試しセット(プロトタイプ基板＋ソフト)を作っている優秀なメーカが数社あり,そこから回路図＋ソフトウェアを購入する。
(2)それをもとに自社で盛り込みたい機能を自社のエンジニアが仕様書にまとめる。
(3)グループ企業の中のソフトウェアの強い企業が開発を担当する。

②メーカに常駐PGが存在する。
(1)基板の設計、開発は自社で行う。
(2)日本には組み込みに強いメーカが数社あり、そこのエンジニアが企業に常駐している。彼らは非常に優秀である。彼らが何年も企業に常駐し開発を行う。

③人材派遣会社から人を集める。
日本には基板開発、プログラムともに派遣で仕事をする人達がたくさんいます。しかしながら、実力差がばらばらで開発もスマートでありません。
この方法の開発体系をいくつかみましたが大抵トラブルを起こしていました。
仕様書を書いたことがないということと,書く人がいつも発注先であるため仕様書を軽視する風潮がありました。しかしながら彼らがオリジナルを仕様書なしで開発し、失敗に到る経験も私は見ています。設計と開発は同じくらい大事なのではないのでしょうか。
だけど、人間的には苦労が多い分、ポジティブで人を思いやるやさしさを持つ人が多かったです。

3つにいえることは大手メーカは基板設計、開発、量産は一流です。しかしながらソフトウェアは3流というか、責任を負わせられるのが怖いためか、自社で行うことはまれでした。組み込みプログラミングは何人も必要ないため、一部の優秀な人間が何度も開発を担当することがほとんどなのではないのでしょうか。
また、現在はMCU(DSP)やOSが複雑になってきたため、ハード、ソフトともにサポートベンダーやRTOSベンダーとの協業を行わないと開発が進みません。したがって、ほぼ全ての大企業がサポート体制を万全にしているため、ソフトウェアの質が低いことはあまりありませんでした。
家電業界では、ほとんどがグループ企業で行われるため、発注の発注はほとんど存在しませんでした。下流のプログラマーの収入の低下というのはないと考えられます。
(他のプログラマ業界のことは分からないです。)

プログラミングできない人間が仕様書を書いているというのは結構ありましたが、すり合わせを頻繁に行う文化が家電業界にはあり、仕様書は開発とともにどんどん変更されていきます。仕様書を書く人とプログラマの間では何度もすり合わせを行います。そのための旅費も会社はきちんと準備しています。
ただソフトウェアがこっち側とあっち側(iPodとitunesような)にまたがり、ソフトウェアの質が商品の質につながる現在、優秀なソフトウェアエンジニアが自社のエンジニアでない場合が多いため、発言権のイニシアチブを取れないことが問題となり、開発者が信頼ある開発者でない場合(経験の薄いエンジニアでその企業の信頼を勝ち得ていない)相当苦労することもまた事実です。
また、毛並みの違うソフトウェア(Webと家電::perlとC)開発は部署間のコミュニティの形成がかぎをにぎるような気がします。

私が思うに、メーカのハードウェア上位の気質が、ソフトウェア開発の軽視や、他企業への発注につながったのだと考えられます。

はじめまして。いつも拝読させていただいております。
エントリーで語られています"根本的に間違ったソフトウェアの作り方"が何故なくならないかを、デフィンシブなシステム開発・オフェンシブなシステム開発という切り口で論じているエントリーを以前読みました。

http://d.hatena.ne.jp/kuranuki/20060116/p1

企業向けシステムを受託開発しているSIerに身をおく私が常々疑問に思っていた事が明快に示されており、なるほどと腑に落ちた反面、酷く絶望的に思った事を憶えています。

>でもあくまで会社は証券会社ですので金融関連の業務が多いとは思うのですが，例えばこういったところでプログラマーとしてソフトウェア開発に関わってきてた人というのは，いわゆるIT市場においても通用できる余地というのはあるのでしょうか？

　十分可能性はあると思います。私が一緒に仕事をしたことのある人の中には、もともとが理論物理学者で、研究の過程で物理シミュレーションのためにやむなく覚えたプログラミングをいつのまにか本職にしてしまた、という人もいましたから。結局のところ、「プログラムを書いていて楽しいか」、「自分はソフトウェアで勝負すべきか」などを根底に近い部分を重視して決めるのが良いと思います。私のまわりには「ソフトウェアを作るために生まれてきた」ような人たちが沢山いますが、彼らの強さは「経験」ではなく「新しい技術を習得するスピード」と「問題解決能力」にあります。そういった素養さえ持っているのであれば、「金融関連のソフトウェアしか作ったことがない」点にが、ハンデにはなったりはしないと思います。

いつも拝読させて頂いています。
初めてコメントさせて頂きます。

私も皆さん同様、激しく同感です。

私は某SIerでエンタープライズ系のSEをやっています。
新人の頃、開発ができなくて設計ができるわけがない！と思っていて、上司にとにかく開発をやらせてくれ！と何度も頼み、運良くやらせてもらうことができました。それでも2・3年です。
しかし、私の周りの上司や後輩を見ると私と同じ経験をしてる人間はほとんどいません。開発などやったことがない人間が、設計と呼ぶには甚だおかしいレベルの設計書を作成します。そんな設計で開発をやらされる側はたまったもんじゃないなと思います。
プロジェクト原価の面からして、ある程度の年齢になった社内の要員に開発をやらせるわけにもいかず、外注するしか手段はなく、社内における開発スキルは空洞化しています。発注する側の我々でさえそのような矛盾した構造の中で仕事をしているのが現状です。
エンタープライズ系は特にそうだと思いますが、顧客の業務に密接に関わるシステムですから、当然高度な業務スキルが必要になるわけです。開発経験がなく適当な設計書を作成して開発を依頼する設計者も問題ですが、私は開発の人間ですので業務のことは一切わかりませんといった開発者にも困ったものです。
ものすごくグレーで難しいところですが、エンタープライズ系のシステム開発においては、設計者側（発注者側）にはもっと開発スキルを、開発者側（受託者側）にはもっと業務スキルをという構造や流れが生まれない限り変わらないのかな？と思います。

『SOAについて、技術的なことは分からないが、経営にとって重要だ』。
ある上流コンサルタントが発した言葉である。このフレーズを聞いた瞬間に、ソフトウェア業界の階層構造における問題点があることを実感した。もし、自分が仕事を委託する側であったとしたら、分からないひとに任せたくないからだ。反対に、技術だけでビジネスを知らない場合も同様だろう。

その後、ゼロからシステム構築を行っていた頃を思う出すことが多くなった。一緒に開発していた外資系コンサルティング会社でも、既に社内の階層構造ができあがっていた。すなわち、経営コンサルタントはSEやプログラマよりも高収入を意味していた。現場のプログラマの不満は、自分を含め当時と変わっていないのではないだろうか。

<< 彼らの強さは「経験」ではなく「新しい技術を習得するスピード」と「問題解決能力」にあります。

Satoshiさんのご指摘に同感です。
ソフトウェア開発では、生産性向上の工夫が開始され、例えば、カレンダーモジュールの共通化や画面モジュールの標準化など、優秀なエンジニアの生産性は一般のプログラマと比較して、数倍、いや、二桁は違っていたと記憶している。元米サン創業者のひとりであるビル・ジョイ氏も、ソフトウェア開発シーンは誰よりもロジックが先行し、キーボードは休むことなく連続して動いていたという。

問題・課題を解決するためには、幅広く良質な情報を選択しなければならない。次に、情報にプライオリティ付けし、再利用できるよう、効率化や工夫を実施する。さらに、リミックス繰り返しながら、新しい自分のアイデアを反映して行く。すなわち、『情報』を『知識』に転換する必要があるだろう。組織としては、個人が持っている『知識』や『暗黙知』を高く評価する仕組み・文化を醸成する必要があると思われる。これを自分は『death process』と呼んでいる。欧米式の成果主義は、プロセスよりも結果を重視している。だが、良い結果を導き出すためには、優秀なプロセスを伴っているものと予想される。

最近、米国の経営書を読んでいると、米国IT企業トップの経営ロジックに関する意見・見解が増えている気がする。若き経営者たちは、自分たちで考え、情報収集・評価・分析を開始しているようだ。

毎回楽しく拝見しています。

私もSEの端くれで４０歳を越えましたしが、いつでもプログラムを書くことをモットーに仕事に望んでいます。そんな自分にとって satoshi さんのご活躍はいつも励みになります。

今回の記事は日ごろ自分も感じていたことが明確に書かれていて大変スッキリしましたが、特に同感だったのが

> 業界全体として国際競争力をなくしてしまう

部分で、私も日頃から危機感を感じています。
そのためにはどうアクションを起こせば良いのか、まだ答えは見つかりませんが、少しでも改善できる方向を模索しています。

　ノブりんさん、新人時代の私の判断なので間違っているかも知れませんが、当時の上司達は、そこまで考えていたとは思えません。それよりも、「このやりかたで今まで何年もやってきたのだから、いまさら変えるとなると大騒ぎだ。私達には私達のやりかたがあるのだから任せておけ」的な反応がとても強かったのを覚えています。当時（１９８５年）は、NTTも民営化されたばかりで勢いもあり、内部に危機感は全くありませんでした。

　その時にも思ったし、今も思うのですが、大きな会社において「自分自身がこれまでのやりかたを変える人になる」というのはとてつもないエネルギーが必要なので、９９％の人はそこは回避してしまうんですね。

御意。
web構築（システムやプログラムも含む）でも同様です。
内部外部の差がある話ですが、使い勝手がよいものなら頼むのも作るのも容易だろうといったユーザの視点に立たない依頼態度をもとに、価格も期間も削られる地方（特に地方省庁や行政の）意識の深さ（ミーハーと不勉強）はなお痛いです。

エンジニアを１０年経験して非常に共感しました。
本日まで色々なメーカさんやＳＩさんと作業してきましたが、
出来る人ほど常に完成(動く)ソフトウェアを作ることから
はじめています。

そのような方々は常にクライアントが
望む動作をできるだけ早く実現、確認して、
最終的なできあがりとのギャップがないようにしています。

本当に料理のレシピだと思います。
顧客にあう料理の味を調整して、
最終的な美味しい料理を作って
最後に顧客が自分で味の調整や料理が
自分でできるようにレシピを作っておく。

最近の日本のＳＩでは、
料理を作ったことないシェフが集まったレストランで
レシピと料理の想定図ばかり作って別の調理人に作らせて結果
まずい料理をお客に出す店が本当に多いです。
本当に美味しい料理を出す小さな料理屋に
気がつく顧客も少ないのも今の現実ですかね。

私は、ジジイになっても料理場で
美味しい料理を作るシェフでい続けたいです。

●関連サイトも書いておきますね。
http://www.hotdocument.jp/

●関連サイトその３
http://document-vb.com/
http://document-access.com/
http://document-excel.com/

すごく同感したので、はじめてブログというものにコメントさせていただきます。

自分はとにかくものづくりが好きで開発の仕事をおよそ５年程していますが、
現在所属する会社がまさに完全な下請けで、上から指定された何とも使い勝手の悪い開発環境で、ご大層な設計書をもとにつくられたシステムの中身をみて驚きました。オフショアに出したときに書かれたと思われる意味不明な変数名、変な日本語コメント、その後いろいろな下請け会社がくっつけていったと思われる様々なレベルのコード。

設計から実装まで一貫してやっていればそんなことにはならないのにと思うのですが、なぜ日本のこの業界は上流・下流という構造なのか理解できません。ものづくりとか技術が日本の強みとか言うわりにこれでは...と悲しくなります。

「創る」ことが好きな自分としては設計から実装まで全部やりたいと思うのです。自分は大手SI企業のように設計にだけ携わった物には責任が持てません。こんな考え方はきっと会社には理解してもらえませんが。

うーん、月３０万か...インド人Javaプログラマーでも４，５０万は貰わないと、やってけなかったなｗ
　真面目に答えるとプロトタイピングがすらできない「開発リーダー」が都市銀行の第三次オンライン位まで確かに「存在」した。情報系だけでもCOBOL換算で最低500万STEP以上あるから、アーキテクチャの基本設計以外は構造化設計して仕様書「だけ」で分割するより方法がなかった。だから仕様書の変更に２０個のハンコがいる稟議書制度でっていうと信じられないだろうが、事実だった。
　逆に言うと（特にメインフレーマー）ＳＥにはキーボードすら打てない人間ができてしまう。実際に元日本ＩＢＭの上司が電子メールを秘書室に「打たせていた」（社長が激怒したが）。だからRADやプロトタイピング、オブジェクト志向型言語（クラス）がでてくる訳だが中々採用されなかった。
　理由は簡単。COBOLとPL/1（最悪は）RPGしか使ったことのない人間に理解できなかったから。これだってサブルーチンは有った筈だが、人月換算で取ってきた下請け仕事で生産性を上げると手取りが減ってしまうｗ　したがって最終的には同じ業務を会社毎に設計・開発することになってしまうｗ 膨大な無駄だったが「日本的」業務は「個別対応」すべきだと主張して結局はERPに全て淘汰されてしまった。
　この体質を持ってる人間が管理職レベルにいるから零細SIPSあたりはもう悲惨。勝手に原価割れの仕事取ってくるは勝手に無料で仕様変更を認めてしまうは未だに生産性が極めて低い。そういうブラックにいるのならsatoshiさんの様に自ら勉強して生き残りをしなければいけないが、ちょっと優秀で素直な人間は上から言われることを鵜呑みにしてしまう癖がある。
　嫌な思い出が思い出がある。ちょうどsatoshiさん位の歳に社長と掛け合って新人コンサルタントの講師をした。会社初めてのUNIX研修。まぁ、telnetでloginしてviとgccでサンプルプログラムをコンパイル実行するだけなんだが、反応は良かった。逆に上司からは恨まれた。オフコンの運用に使う筈の新人だったから。半年後、その新人に会ったらリースシステムの運用管理をしていると言う。「やっぱホストっすよね！」目を輝かせていた。無論、IBM S/38（AS/400ですらない）は「ホスト」とは云わん。さらに半年後、RDBMSの外資に転職した。社長には慰留された。ただし、３００人のRPGプログラマーを喰わせてやって欲しい、と。実際３年以内に全員クビにされたそうだ。こうなると誰が悪いのか良くわからんね。

大きなプログラムを一人で書いたことがあり、ソフトウェア開発の全体像を分かっていることが、効率の良いプロジェクトの上流プログラマに求められる条件なのは当然なのに、現在のありかたは非効率で理不尽だと本当に同意します。
プログラミングというものづくりはもっと創造的であるべきで、ストレスにまみれた泥仕事であってはならないと、一人のアマチュアプログラマーが願っています。
このような記事を通して、少しでも多くの方が影響されて考えを変えれば良いのですが。

とても共感します。

勝海舟はこういう言葉を残しています。『アメリカでは、政府でも民間でも、およそ人の上に立つものは、みなその地位相応に怜悧でございます。この点ばかりは、まったくわが国と反対のように思いまする』鳩山元首相やら菅元首相を見ると、こういうのは日本人の体質なのかもしれません。

全体を監督する立場の人に必要な能力とは何なのか？サッカーボールに触ったことの無い人がサッカーチームの監督になんてなれるはずがない。

最近、世界中でウイルス蔓延のせいでストレスも広まっている模様。
そのストレスがいずれにあらゆる病気をまたらす。
それを踏まえて皆様に催促のストレス解消方法を伝えたいと思います。
下記のリンクでご覧になって下さい。
https://youtu.be/2OpQfNPjc9g