新・なぜソフトウェア開発論文を書くのは難しい(と感じる)のか - yumulog
現在の研究テーマ的にシステム・ソフトウェア開発論文を読んだり書いたりする機会が多い。指南文献などもいろいろ読み、以前よりは書くポイントがだいぶわかってきたつもりだが、それでもやっぱりあまり得意ではない。むしろ書くポイントが分かってきたからこそ、その難しさを実感するようになったのかもしれない。なお、ソフトウェア開発論文の執筆の難しさについて書かれた、『なぜソフトウェア論文を書くのは難しい(と感じる)のか』という非常に有名な文章がある。執筆の難しさについて客観的かつとても網羅的に書かれているので、未読の方は、こちらを先に読むと良いだろう。 システム・ソフトウェア開発論文では、導入部で「なぜいままでだれもやっていないのか」「どのような難しさがあったのか」を説明することが重要だと実感している。論文としてまとめる際に、開発する難しさ、そしてその難しさを乗り越えるアイデアがあたかも初めからあったように
プログラマのためのビジネス・マナー講座 - megamouthの葬列
最近、若手のプログラマと仕事をしていると、フレームワークやライブラリの知識はあるのですが、常識が欠けているのではないか、と思う事があります。 業界経験の長い私たちから見ると、ほぼあり得ないようなことを、論理的な正しさだけを基準に決めつけてしまい、結果として営業が苦しむことになったり、クレームに発展するようなケースも見聞きします。 私たちにとって「当たり前」に判断できることを経験不足で判断できずに、同僚から疎まれたり、会社にマイナスの影響をおよぼしているのだとすれば、非常にもったいないことです。 今回は、業界歴20年におよぶ私が、若手プログラマの成長の一助になることを期待して、この業界のごく一般的なマナーをケース別に紹介、解説したいと思います。 商談編 Q.お客様が「Instagramに投稿された写真のうち当社の製品が写っているものを自動的に当社のHPに掲載したい」と仰ったので、「それは出来
ソフト開発で世界と闘った及川卓也氏が見た、日本の弱点と可能性（中央公論） - Yahoo!ニュース
―─外資系IT企業三社をそれぞれ九年間ずつ、二七年間経験されましたが、そんなご経験に関心を持った自動車部品最大手のデンソーから声がかかり、技術顧問をされていますね。 自動車産業は日本にとって最後の砦とも言えるものですが、デジタル化の進展にともなって、MaaS（Mobility as a service、マイカー以外の公共交通機関やカーシェアなどの移動全体を一体のサービスとしてとらえる概念）や、CASE（自動車業界の変革を象徴する造語。接続のConnected、自動運転のAutonomous、カーシェアリングのShared、電気自動車のElectricの頭文字から成る）、あるいはIoT（モノのインターネット）など、取り巻く環境が激変しています。変化の主体は産業のサービス化であり、その背景にデータをいかに有効活用するかという技術や、事業化のノウハウが求められ、そうした点で期待されたのだと思いま
株式会社ドワンゴを退職しました
ex-dwango.md 株式会社ドワンゴを退職しました 2011年3月15日に就職してから今日で8年と3ヶ月半・・・月にして99ヶ月・・・日数にして実に3033日 と・・・計算している間にも23秒が過ぎてしまったわけですが、株式会社ドワンゴを退職しました。 7月からはクックパッドで働きます。 ドワンゴでやってきたこと 2011年に入社して最初は今は亡きニコニコ静画(電子書籍)のバックエンドの開発をしました。 当時はphp縛りだったので仕方なくphp、こっそり gitを導入して会社の公式リポジトリであるsvnには定期的に git-svn でコピーする仕組みを作ったりしてました。 当時CIはちょっと導入されていたもののCDの概念は存在しなかったので、capistranoでphpをデプロイする仕組みを作ってそれも こっそり 運用していました。 浜町時代からドワンゴ社員御用達 BROZERS'
「悪い方が良い」原則と僕の体験談｜Rui Ueyama
ソフトウェアの世界には「悪い方が良い」原則という有名なエッセイがある。キレイにレイヤ分けされた一貫性のある良いデザインよりも、一見手抜きの悪いデザインのほうが実は良いときもあるという話だ。この逆説的なデザイン原則を僕は身をもって体験したことがある。それについてちょっと書いてみようと思う。 僕はlldというリンカの現行バージョンのオリジナル作者だ。リンカというのはコンパイラと組み合わせて使うもので、実行ファイルやDLLを作るのに使用される。lldはプロダクトとしてはかなり成功していて、標準のシステムリンカとして採用しているOSがいくつかあったり、GoogleやFacebookなど皆が知っているような大規模サイトの中で広く使われていたりする。 現在のlldは2世代目で、第1世代のlldは僕がプロジェクトに参加する前から存在していたのだけど、数年前にそれを捨てて一から書き直すということになった。
テスト駆動開発とマイクロサービスのせいで短命に終わったスマホゲームの話
「悪い方が良い」原則をご存じだろうか？ プログラミング言語「Common Lisp」の開発に携わったことでも知られるソフトウエア技術者リチャード・ガブリエル（Richard Gabriel）氏が1990年に発表した有名なエッセイ「The Rise of ``Worse is Better''」で主張したソフトウエア開発の考え方だ。 このエッセイでガブリエル氏は、美しく完全に設計・実装されるより、単純で雑に設計・実装されたソフトウエアの方が良いと説く。彼は前者を「正しいやり方」「MIT/スタンフォード式」、後者を「悪い方がよい原則」「ニュージャージー式」と呼び、ニュージャージー式がいかに優れているか様々な事例を挙げて説明する。 これは一見とても奇妙に聞こえる。 ソフトウエア開発では通常「美しい設計」や「美しいコード」が尊まれる。「車輪の再発明はするな」とか、「階層構造に分けて、要素をいつでも
【SE業界裏話】長年１人で社内システムを開発していた社員が辞めて明らかになったこと:ハムスター速報
TOP > 労働 > 【SE業界裏話】長年１人で社内システムを開発していた社員が辞めて明らかになったこと Tweet カテゴリ労働 0 ：ハムスター速報 2019年5月10日 16:51 ID：hamusoku お客様「長年一人で社内システム開発していた社員が辞める事に」 「ほう」 お客様「社内システムメンテ出来なくなるのでスクラッチで刷新したい。ついては見積もりを。予算感は五千万くらい」 「分かりました」 …（翌日） 「概算見積もり出来ました」 お客様「いくらくらい？」— 戦略的なビビ（Vivi） (@strategic_vivi) 2019年5月9日 「15億円です」 お客様「…は？」 「統計ベースで判断して15億円規模のシステムです」 お客様「…」 「弊社に言える事は一つです。その社員だった方を、年収1億円提示して今すぐ呼び戻して下さい」 世の中には、単に社内SEと呼ばれるハイパーエ
技術者不足の衝撃実態、従来型IT人材は2030年に10万人余る
2030年に「従来型IT⼈材」が10万⼈余る。従来型IT人材は「従来型ITシステムの受託開発、保守・運用サービス等」に従事する。これらは2019年4月23日に経済産業省が発表した「IT人材需給に関する調査」という報告書に出ている数字と用語である。 同報告書を紹介した4月24日付日本経済新聞の記事には「先端人材55万人不足 経産省試算 30年、AIやIoT」という見出しが付けられていた。 先端IT人材は足りないが従来型IT人材は余る 新聞記事の見出しと本稿の題名は同時期のIT人材需給を指している。すなわち2030年に人材不足と人材余剰が同時に起こる。AIやIoTに関わる先端人材は55万人足りなくなるが受託開発や保守運用を担う従来型IT人材は10万人余る。 同報告書は「先端IT人材」と名付け、「AIやビッグデータ、IoT等、第4次産業革命に対応した新しいビジネスの担い手として、付加価値の創出や
気色が悪い「顧客に寄り添う」をやめないSIerに再度警告する
日本の人月商売のITベンダーは「顧客に寄り添う」というフレーズが大好きだ。私からすると極めて気色悪い言葉なのだが、SIerだけでなく下請けITベンダーの経営幹部もよく口にするから、もはや日本のIT業界のアイデンティティーと言ってよい。 最近もこのフレーズを聞く機会があった。富士通の社長交代の記者会見で、時田隆仁次期社長が「顧客第一で顧客に寄り添ってきた半面、自らアイデアを出しながら次のテクノロジーで顧客に新しい価値を届ける部分が不得意になってきた面がある」と発言したのだ。 この時田次期社長の発言の後半部分はまさに正確な認識だ。「自らアイデアを出しながら次のテクノロジーで顧客に新しい価値を届ける部分が不得意になってきた」のは富士通に限った話ではなく、国産コンピューターメーカー共通の大問題である。 昭和の間は少なくともハードウエアでは、国産コンピューターメーカーは顧客に新しい価値を届けてきた。
フリーランスエンジニアがコード書いて稼げる上限｜shu223
フリーランスエンジニアがコード書いて稼げる年収の上限は、だいたい3000万円ぐらいらしい。 この数字がどこから来ているのかというと、 masuidriveさんはCTOというエンジニアの相場観が見えやすそうなポジションを長くやってた方だし、きっとそんな感じなんだろうなと。 3000万を12ヶ月で割ると1ヶ月あたり250万。20人日として単価は12.5万円/日。なんとなくコード書くエンジニアの上限として妥当そうな感じはある。 だから何なのかフリーランスエンジニアは自分で自分に値付けしないといけないのだけど、これが結構難しい。技術力や経験は上がっていくものだし、しかしそれだけで値段が決まるというものでもない。あと基本的に自分の単価は公言しないものなので、参考値もあんまりない。 会社員からフリーランスになったとき、額面上は一気に大きくなるので、「うわーさすがにこれは高すぎでは」とビビっていたが、今
「私はコボラー」、若者の希望を摘み取ってはいけない
2年弱続けてきたこの連載も、今回で最終回である。最終回は、今のIT業界について、思うところを書いていきたい。 新卒社員にCOBOLを習得させて現場に投入していいのか 日本で稼働していたシステムの中で一番使われてきたプログラミング言語は「COBOL」であろう。今でも汎用機では現役のプログラミング言語である。ただ、最新の言語でないことは確かだ。 私の派遣SE・プログラマ時代は汎用機が主流であり、プログラミング言語として当たり前のようにCOBOLが使われていた。仕事としてもCOBOLの需要が多かったので、私も「コボラー」として現場に投入された。これに関して別に不満はなかった。 ただ、今は時代が違う。様々なアーキテクチャー、プログラミング言語、開発手法があり、ITの世界はすさまじいまでの広がりを見せている。そんな時代なのに、希望に満ちて新卒で入社した社員にCOBOLを習得させ、売り上げを確保できる
「責任感がないのか」、ユーザーに転職直後に覚えた違和感と“銀の弾丸”に出会った話
出典：日経 xTECH 2016年 11月 22日 （記事は執筆時の情報に基づいており、現在では異なる場合があります） 「責任感がないのか」 ユーザー企業に転職してシステム担当として初めてかかわったプロジェクトで感じたのは、上辺だけのやり取りでユーザーもベンダーも責任を果たそうとしない奇妙なほど滑稽な現場の姿だった。 私は、IT業界の多重下請け構造の末端での生活に限界を感じて転職し、下請けSE・プログラマーからユーザー企業のシステム担当になった（参照：『「この電話は使われていません」、親身になってくれた友人がIT業界の闇に消えた話』）。28歳の時だった。 転職が決まった際、心に浮かんだことは、たった一つ。 どんづまりから抜け出せた…。ただそれだけだった。 解放感はものすごいものがあった。 転職先の業種はサービス業だったので、私でも、SE・プログラマーではない仕事ができるかもしれない。期待に
開発者必修の7PKとは？
(Last Updated On: 2019年2月5日) 7PKという用語を聞いた事がある開発者も多いと思います。7PKは業界標準のソフトウェアセキュリティ分類です。まだの方はこれを機会に是非覚えてください。CERT Top 10 Secure Coding Practicesと同じく開発者全員に必修の用語と概念と言えます。何故なら、CERT Top 10 Secure Coding Practicesも7PKも知らないのならISO 27000(ISMS)、NIST SP800-171に対応するアプリケーションは作れないからです。 ※ 7PKやCERTセキュアコーディング原則を知らなくても、セキュアなソフトウェアを作ることも可能かも知れません。しかし、それはかなり遠回りになるでしょう。 7PK 〜 Seven pernicious kingdoms: a taxonomy of softw
12年半勤めた金融系SIerを退職しました | 川上徹
あけましておめでとうございます。2018年9月30日を持ちまして、大学新卒入社以来12年半勤務した金融系SIerを退職し、2018年10月1日より事業会社のエンジニアとして働き始めました。年内で試用期間を終了することから、ちょうどよい節目として転職にまつわる思い等をまとめておこうと思います。 前職の概要企業分類としては、大手企業の子会社としてシステムインテグレーションを担う会社。俗に○ー子と呼ばれる会社でした。○に何が入るかはご想像におまかせします。 金融系というのは主とするビジネス領域が金融関係であったという意味で用いています。資本が金融系という意味ではございません。 親会社からの開発案件を請負で処理するか、SES契約で人を出すか、概ね業務形態としてはそのいずれかであったと思います。 現職の概要主に食品を取り扱う事業会社で、ECを主軸として売上を立てている会社です。自社事業に関するシステ
底辺IT企業は『書けない』プログラマとどう向き合ってきたか - megamouthの葬列
新年から夢のない話で申し訳ないのだが、表題のとおりのテーマである。 note.mu という記事があって、むやみに長いので飛ばし飛ばし読んだ。 大意としては、世の中には「書けない」プログラマというのがいて（元エントリでは学生さんのようである。さもありなん）そういう人はどうやったって書けるようにならないんだから、諦めろ、という話のようである。 で、じっと手を見て、下請け底辺のIT企業にいる私たちは、このような人々をどうしてきたろうか、と考えると、「放ったらかし」にしたなあ、と思うのである。 最初のほうは優しく教えていたと思う。話したりハンズオンしている時に、あっこの子、変数のことわかってないな、と感じたら、ホワイトボードを持ち出してきて、例の"x"と書いた箱の絵に矢印を引いて、値が入っている図を書いて、「わかった？」「あ、はい」みたいなやり取りをして終わり、という程度の「教育」である。 だが、
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
technology-budgeting/handbook.md at master · 18F/technology-budgeting
及川卓也 / Takuya Oikawa on Twitter: "レンタカー会社のハーツがアクセンチュアに委託したウェブサイトとモバイルアプリのリニューアルプロジェクトが失敗して、訴訟にまで発展した件は日本だとここに記事化されている。ここではプロジェクトのスコープと金額の話ってまとめられているけ… https://t.co/XDwOLPgD95"
T A R O よわよわ通訳者 on Twitter: "9割のインド人プログラマーが日本のプロジェクトを1年経験して口をそろえて言うのは「日本は大好きだけど、日本企業が顧客の開発プロジェクトでは2度と働きたくない」です。残念ですが現実です。"
Age Of Agile Development
http://jun.artcompsci.org/articles/worse-is-better-ja.html