プログラマとしての立場で、どんな開発プロジェクトが嫌か考えてみました。 個人的な偏見満載で、とりとめもなく羅列してしまいました。 なお、フィクションですのでご注意下さい。 書いてから自分で見直すと結構酷いかも知れないと思い始めました。 あらかじめ、言っておきます。ごめんなさい。
プログラマとしての立場で、どんな開発プロジェクトが嫌か考えてみました。 個人的な偏見満載で、とりとめもなく羅列してしまいました。 なお、フィクションですのでご注意下さい。 書いてから自分で見直すと結構酷いかも知れないと思い始めました。 あらかじめ、言っておきます。ごめんなさい。
前回の記者の眼「IT業界の“イジメ”に切り込む」で実施したアンケートでは,411人もの方から回答を頂きました。どの回答も「不当な要求や対応の実態」の一端を表す貴重なご意見でした。ありがとうございました。 今回はそのアンケートの結果と不当な要求や対応の実態がどのようなものかを紹介します。 大半のケースが下請けイジメ アンケートではまず始めに,優位な立場を利用した不当な要求・対応を経験したことがあるかどうかを尋ねました。結果は,59.1%という過半数の方が「不当な要求・対応を受けた」と回答されました。 続いて,「不当な要求・対応」がどのような構図(立場の違い)で発生したのかを尋ねました。一番多かったのは元請け会社の社員(またはユーザー企業の社員)と下請け会社の社員という構図でした(全体の41%)。その中で声として一番多かったのが,「ユーザー企業からトラブルの責任を一方的に押し付けられる」という
企業各社にとって、人材戦略は非常に重要な課題だ。人材の育成に当たって、トップは何を思うのか。企業を担う若いITエンジニアに何を求めているのか。 技術に立脚した新しいサービスを次々に生み出し、「技術を究められる企業」として多くのITエンジニアのあこがれの的となっているグーグル。人材戦略についてはどのような考えを持っているのか。また、内部のITエンジニアはどのような考えを持って開発に当たっているのか。グーグル 代表取締役社長 村上憲郎氏に聞いた。 ■新しい技術が各種のサービスを支える @IT自分戦略研究所とJOB@ITが2007年5月に実施したアンケート「@IT自分戦略研究所/JOB@IT 読者調査 2007年春季版」では、グーグルは「次に転職してみたい企業」の2位。そのほか各社の調査でも、働いてみたい企業として上位に挙げられている。 村上氏は、グーグルの人気の一番の要因として「特にここ2、3
なんかの実装がオープンソースで公開されているときに、同じ機能の実装を行うのは「車輪の再発明」で無駄な行為だといわれた時期がありました。 でも、それは「再発明」ではなく「再実装」であって、とても大切な行為です。 車輪にしたって、ブリヂストンも横浜ゴムもタイヤの開発をいまもって続けてるわけです。タイヤだけでなく、ホイールからベアリングからドライブシャフトから、「車輪」の部品については、いまだにいろいろな会社が切磋琢磨して再実装を続けているのです。 世の中に出ているライブラリを自分で実装してみるとわかることは、自分の実装を持っているという強さです。 たとえ世の中のライブラリに機能的に性能的に負けていたとしても、自分の実装というのは自分のニーズに合わせるという点でとてもいい。特に、処理の途中の値を使えるというのがいいのです。ライブラリでは、入力したら出力が返ってくるまで中身が見れないですからね。
Webアプリケーション開発案件の短納期化、高品質化、低コスト化要求に応えるために、ソースコード自動生成技術を活用する手法が注目されている。アイデア自体は昔から存在するものの、これまで大きく普及してこなかった自動生成という分野が、いまなぜ再び脚光を浴びつつあるのか。開発現場では顧客の高品質化要求や短納期要求により、もはや5%や10%の生産性向上策では負荷を吸収できずにいる。思い切って生産性を5倍、10倍へと上げるためには「できるだけコードを書かない」という発想の転換を行うしかないと気付き始めてきたことが大きい。ここではその技術進化の過程を追っていくとともに、ソースコード自動生成技術分野の最新状況と、これによるソフトウェア開発作業の現場への影響を紹介する。 自動生成技術の歴史 ソースコードを自動生成させるという考え方自体は古く、FortranやCOBOLが全盛の時代から今日に至るまで、さまざま
2007/11/30 ガートナー ジャパンは11月30日、同社のイベント「Gartner SYMPOSIUM ITXPO 2007」でメディア向けのセッションを開催し、「日本の大手ベンダはオープン化で欧米のベンダに遅れて、また次の時代にも周回遅れになりそうになっている。20年は遅れる」(同社 ITインフラストラクチャ バイス プレジデント 亦賀忠明氏)と警告した。 ガートナーがこう警告する背景には、米国でグーグルが急成長し、IBMやオラクル、SAPなどの既存の大手ベンダに売り上げで迫りつつあることがある。グーグルは積極的な企業買収や、ユーザー指向のサービス開発、クラウド・コンピューティングの推進などで他社を圧倒。IBMなどもグーグルを最大のライバルと考え、クラウド・コンピューティングの戦略を練っている。そこにはNECや富士通、日立製作所などの国産ベンダが付け入る隙はなさそうだ。 象徴的なの
またも独り言。 「ハッカーしか扱えないけど、ものっすごく効果的」というものよりは、「それなりの人が扱えて、それなりに効果的」なほうが受け入れられるのではないかという気がしてきました。それって、ある意味のオープン性ではないかと。 その証拠として考えているのがWebサービスとStrutsと"はてな"です。 Webサービスはただのメッセージ交換 Webサービス(SOAといってもよい)というのはデータメッセージングに過ぎません。分散コンピューティング技術で考えれば、CORBAよりも簡単だしJiniなんか比較にならない。当初のSOAPはセキュリティも考えちゃいないしメッセージ種別も同期のみ。でも普及できたのはリーチがある技術だったからです。 XMLなわけだからプログラミング言語やOSを選ばないどころか、EXCELでもいいし手書きしてもいい。マイクロソフトアプリとJavaアプリが会話できるのもWe
2007年09月26日16:15 カテゴリArtMoney 人月を超えるとプログラムしている暇が減る 人月が銀の弾(たま)ではないことが知られて久しいのに、「人月伝説」が衰えないのは、誰が悪いのだろうか? 矢野勉のはてな日記 - プログラマなら人月なんかさっさと超えろ 人月というのは「人月の神話」以来、現場の技術者にとっては「お金の計算にしか使えない単位」なのですが、発注者側に分かりやすいということでいまでも大はやりしています。というか受注者側もまじめにこの単位で計算しています。 実は、プログラマー自身なのではないだろうか。 実は人月というのは、発注者側だけではなく、プログラマーにとっても楽なのだ。人月見積において、プログラマーが考えなければならないことは、「それを作るのにどれくらいの時間がかかるか」ということだけだ。「それを完了するのに何と何と何が必要で、それぞれこれくらいの手間がかかる
2007年02月23日17:00 カテゴリArt 日本発のソフトが少ないのは日本がアメリカではないから With all due respect, I disagree. So would Bill Gates. On Off and Beyond: 日本発のソフトが少ないのは日本人が英語が苦手だから 日本のソフトウエアは自動車同様、ほとんど保護を受けなかった産業の一つだが、そのグローバル競争力は地を這っている。「フラット化する世界」を読めば、Bill Gatesがいかに日本人のソフトウェア開発力を高く評価しているかがわかる。実際ゲームソフトの世界では、世界を支配しているのは合州国ではなく日本である。 また、合州国ブランド出ているソフトウェアにも、日本で開発されたコードがかなり入っている。今時のOSは英語以外の言語もきちんと扱えるようになっているが、これは日本人なしにはありえなかった。Wi
普通のやつらの上を行け ---Beating the Averages--- 著者:Paul Graham Copyright 2001 by Paul Graham これは、Paul Graham: Beating the Averages を、原著者の許可を得て翻訳・公開するものです。 プロジェクト杉田玄白正式参加テキスト。 <版権表示> 本和訳テキストの複製、変更、再配布は、この版権表示を残す限り、自由に行って結構です。 (「この版権表示」には上の文も含まれます。すなわち、再配布を禁止してはいけません)。 Copyright 2001 by Paul Graham 原文: http://www.paulgraham.com/avg.html 日本語訳:Shiro Kawai (shiro @ acm.org) <版権表示終り> 文中、Eric Raymondの "Ho
Heads up! This page uses features your browser doesn’t support. Try a modern browser like Firefox or Chrome for the best experience. sidebar#close mouseup->tweet#update input->tweet#update keydown->tweet#update scroll@window->tweet#update" data-bookmark-id="/gettingreal"> P��� ���� Getting Real The smarter, faster, easier way to build a successful web application Start reading →
2008/03/10 フリーランスのITエンジニアを支援し、開発業務の共同受注を行っている首都圏コンピュータ技術者株式会社(MCEA)は3月10日、同社とフリーのITエンジニア、そしてシステム・インテグレータ(SIer)とがジョイントベンチャーを組んで、開発業務を共同受注する取り組みを新たに始めると発表した。これまで個人事業主であるフリーエンジニアとMCEAとの共同受注だけだったが、新たにSIerとも手を組み、より大規模な開発案件を受注できるようにする。同社はこのジョイントベンチャー方式によってIT業界の悪弊といわれる多層請負構造が構成できなくなるとしている。 MCEAは当初、個人事業主のフリーITエンジニアによる協同組合だったが、協同組合法の改正によって組合員が1000人以上の協同組合は「上場企業以上の透明性が求められるようになった」(MCEA 代表取締役会長 横尾良明氏)ことで、200
Looking for data labeling solutions to power Machine Learning models? Amazon SageMaker Ground Truth allows you to easily build and manage your own data labeling workflows and workforce. Or, use Ground Truth Plus, a turnkey data labeling service that provides an expert workforce and manages it on your behalf. Amazon Mechanical Turk is accessible through both Ground Truth and Ground Truth Plus. Amaz
普通のやつらの上を行け ---Beating the Averages--- 著者:Paul Graham Copyright 2001 by Paul Graham これは、Paul Graham: Beating the Averages を、原著者の許可を得て翻訳・公開するものです。 プロジェクト杉田玄白正式参加テキスト。 <版権表示> 本和訳テキストの複製、変更、再配布は、この版権表示を残す限り、自由に行って結構です。 (「この版権表示」には上の文も含まれます。すなわち、再配布を禁止してはいけません)。 Copyright 2001 by Paul Graham 原文: http://www.paulgraham.com/avg.html 日本語訳:Shiro Kawai (shiro @ acm.org) <版権表示終り> 文中、Eric Raymondの "How to bec
Joel on Softwareposted with amazlet on 06.04.15Joel Spolsky 青木 靖 オーム社 (2005/12) Amazon.co.jp で詳細を見る id:ryoko_komachi:20051218:1135176719でも絶賛されている。 Joel on Softwareを買って読み始めました。 この本が出ることを教えてくれたのは、たしかid:naoyaだったと思うのですが、聞いた時点で買うことを心に決めていました。 というのも「プログラマのためのユーザインタフェースデザイン」で、Joel氏の文章を読んでいて、その経験に裏打ちされた内容がとても勉強になったからです。 というか、影響受けまくりました。 書籍版のJoel on Softwareは、上記のサイトの文章をまとめたものが大部分だそうです。 Joel氏はMicrosoftで働いてい
小飼弾です。ご機嫌はいかがでしょうか。 前回の予告通り、今回はオープンソースの利点ではなく、オープンソースの欠点を取り上げます。 昨今では、さまざまなソフトがオープンソースで提供されています。OSならWindowsやMac OS Xに対してLinuxやFreeBSD、オフィススイートならMicrosoft Officeに対してOpenOffice、WebサーバーではIISに対してApacheやlighttpd、データベースならOracleに対してPostgreSQLやMySQL、ソフトウェアの開発環境ならVisual Studioに対してEclipseといった具合で、デスクトップ環境を全てオープンソースソフトウェアで固めても問題がないところまで充実してきました。Webサーバーに至っては、むしろオープンソースのApacheの方がIISよりも普及しているほどです。 それでは、世の中のソフトウェ
最近のシステム構築では仕様書をきちんと記述しないで、いきなりツールを使ってプログラムを作成することも多いようだ。否定する気はないが、駆け出しのころはしっかり自分の手で仕様書を書いた方がいい。 前回は、SEを目指している皆さんに向けて、仕事に取り組む姿勢の観点からアドバイスを書いた。今回は、SEに求められるより具体的な知識やスキルの向上に役立つ話を書いてみたい。 SEとして必要な知識やスキルは非常に広範にわたる。経験を積み、上級SEになってくればより経営的な知識が求められるが、最初のころは、システム構築に必要な知識やスキルが特に重要になる。今回は、システム構築における基礎的なスキルの開発方法を紹介しよう。 仕様書を書くこと 最近のシステム構築では、仕様書をきちんと記述しないで、いきなりツールを使ってプログラムを作成したり、システムを構築したりする手法が取られることも多いようだ。こういった手法
「意外にC/C++の人気が高いのか」「プログラマには転職しやすいイメージがあるんだ」――。これらは,著者がアンケート結果を集計しながら感じたことである。 読者の皆様のおかげで,日経ソフトウエアは2008年7月号をもって創刊10周年を迎えることができた。その関連企画の一つとして,ITproと共同で,「プログラミング/プログラマに関するアンケート」を実施した。 この「プログラミング/プログラマに関するアンケート」は,2008年4月9日(水)~4月14日(月)の6日間,日経BP/日経BPコンサルティングのWebアンケート調査サービス「ITpro Research」の登録モニターを対象に,専用Webサイト上で実施したものである。回答者総数は3003人。回答者の年齢構成は,40才代が最も多くて39.4%,続いて30才代が34.8%,50才以上が19.3%,20才代が6.2%だった。3003人のうちプ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く