Web制作をする前にきちんとしておきたいお金の話し。 │ モノづくりブログ 株式会社8bitのスタッフブログです
株式会社8bitのスタッフブログです。こんにちは。株式会社8bitの高本です。 今回は以前からいつ書こうかとずっと思っていた、Web制作とお金にまつわるお話を書いてみたいと思います。 みんながみんなではないと思いますが、Web業界に携わっている方の大半は本当に良いデザイン、良いサイトを作りたい、という思いが強く、出来れば見積りや請求などのお金の話しには関わりたくない、縛られたくないという方が多いように思います。 どちらかというと私もお金の交渉からは、気持ち的にはできれば避けたいと思ってしまいます。 先日、さぶみっとというWeb制作マッチングサイトを先日見ていたのですが、契約や未払いの相談みたいなものが思いのほか多いのに驚きました。 https://hp.submit.ne.jp/qa いくら仲の良いお客さんでもお金の話しになるとシビアになりますし、支払い交渉はなんだか金金言って
SI業界で技術者が軽視されてしまうのは何故なのか - GoTheDistance
日本のSI業界でこそ、専門の技術者の必要性がもっと見直されるべきではないのか？ - 達人プログラマーを目指してを拝読しました。この手の議論は定期的に出てくる根の深い問題でありまして、1億年と2000年前から多くの方に言及されています。しかし、それほど大きい問題であるということです。一概にああしろこうしろで片付く問題ではありません。 色々論点はありますが、「技術を売って社会貢献している業態なのに、一番重要な技術者を軽視するってどういうこと？」という１点に集約でき、上記エントリの主題も同じです。技術onlyの専門家の存在が認められないのが問題だと。しかしですね、「技術者そのものを売ってるんだから、軽視云々を言ってもどうしようも出来ない」という果てしない平行線を辿っていることが見えているでしょうか？ブルーハーツの「弱いものたちが夕暮れ 更に弱い者を叩く」というフレーズが思い起こされます。 技術者
開発とテストの融合こそゴール。続、グーグルはあれほど多くのソフトウェアのテストをどのように行っているのか？
開発とテストの融合こそゴール。続、グーグルはあれほど多くのソフトウェアのテストをどのように行っているのか？ グーグルでTest Engineering Directorを務めるJames A Whittaker氏が書いたエントリを紹介した先日の記事「グーグルはあれほど多くのソフトウェアのテストをどのように行っているのか？」が非常に好評で、「続きがあれば読みたい」というコメントをいただいていました。 Whittaker氏がそのエントリの続き「How Google Tests Software - Part Threeを公開していますので、ご要望に応えて紹介することにしましょう。 品質は開発の問題であってテストの問題ではない 品質とはどのように実現するものなのか？ という問いに対して、Whittaker氏は次のように書いています。 The simple solution to this con
「アリさんマークの引越社」から学んだスピード営業術
Revtank Outtakes / MiiiSH 実は我が家は今月末に引越しをすることになりました。引越し先と転居日も決まり、色々な準備で忙しい日々を送っています。 引越し業者は「アリさん引越し社」に決めました。アリさんに決めるにあたって、最初の見積もり依頼から契約まで12時間強しかかかりませんでした。アリさんの営業に上手くはまってしまったといえば、それまでなのですが、特に不満はありません。逆にすごく満足しています。 どんなやり取りがあったのかを、ご紹介したいと思います。 Old Bakelit phone / aussiegall 申し込み一分後に電話が来た インターネットを利用して引越し業者数社へ見積もり依頼をしました。夜20時頃でした。すると、一分後ぐらいに電話がかかってきました。今回最終的に契約をしたアリさん引越し社でした。 早速お部屋を見させてもらって、見積もりをしたいとのこと
Javaプログラマが知るべき9のこと - @katzchang.contexts
はじめに ソースコードは設計であり、コードの記述は品質に直結するのは言うまでもない。ちなみに、プログラマにとって特に重要なのは保守性だ。コードは書いた直後から保守対象となるからだ。コードは要求文書の範囲で動けばいいと思っている人がいれば今すぐ、ソースコードをコピペして100klに増えるプラグインがいつの間にかインストールされる呪いをかけてあげよう。幸い、ここを読んでいる人にはそんな人はいないだろうと思うけれども。 ということで、コードの品質を下げる要因、すなわちシステム全体の品質を下げる要因となり、かつ使われやすいアンチパターンを挙げ、対策を検討していくことにする。対象は以下： 出力パラメータ 処理状態返却 意味のある配列 無意味な初期化 多すぎるtry-catch 暗黙の順序 コンパイラ警告の無視 過剰なコメント e.printStackTrace() 出力パラメータ メソッドの引数にオ
プログラマーの成長を考えないSIerの仮説は間違っている - 達人プログラマーを目指して
Java EEや.NETはCOBOLやVB6よりも本当に生産性が高いか？ - 達人プログラマーを目指してのコメントで 熟練者も居ることは理解しているが、開発をする上で熟練者ばかりを集めることはできない。このため初心者側にレベルを合わせざるを得ない。 というコメントをいただきましたけれど、これは実に典型的なSIer（の上司）の考え方ですね。SIerの仮説と呼んでもよいくらいですね。とにかく、この仮説の前提となっているのは プログラマーのスキルレベルは一定で成長しない プログラマーは容易に交換可能なリソースである プログラマーは単純労働者である というモデルです。とにかく、この仮説がはびこっているから、いまだにSIerのフレームワークは「初心者側にレベルを合わせざるを得ない」という思い込みで作られていることが多いのでしょう。 COBOL（の初期の）時代ならまだしも、少なくとも現在の開発環境にお
年を取れば取る程会社での居場所は狭くなるの？ - GoTheDistance
こんなことを思ったそもそもの発端はこの記事を読んだから。 会社から「残っても仕事はない。何をするつもり？」「整理解雇になったら、高齢のあなたは一番に対象になる」「お客様が、年齢が高い人にサービスを受けたいと思いますか？」と言われた人もいる。 朝日新聞デジタル：どんなコンテンツをお探しですか？ なんとまぁ切ないお言葉・・・。こんなこと言われた日には涙すら出なそう。 こういう記事を読むと「年を取った人は給料高いだけだから要らない」という話に聞こえるのですが、これは本人の自助努力の問題だけで片付けられるんでしょうかと疑問に感じています。ベテランになっても若手と同じ事しか出来ないから切られるのだ、という単純な話じゃなさそうだけど、どう考えていいのだろうか。 もし必然的に居場所がなくなるとすれば 僕が思いついたシナリオは、右肩上がりで経済が成長できて当然の時代なら誰も文句は言わなかったが、同じ事業を
営業ができる人とできない人の違い - GoTheDistance
営業という言葉に良いイメージを持ってる人はかなり少ないんじゃないかと思います。特にエンジニアは営業さんに「泣かされた」経験がおありの方が多いですし。また、電話爆撃営業や詐欺に近いような営業も多い中、益々うさんくささが先行しやすいのかなぁと思ったりします。 ホントはそういうもんじゃないだろって思うので、自分１人で顧客の所に赴き、話をしに行くことも増え、発注側として営業さんの話を聞くことも増えてきました。そんな中で、営業について感じたことを書いてみます。 1. できる人は相手に問いかける、できない人は自分が話し続ける 相手とのコミュニケーションの中で距離感をつかみ、お互いが負担にならないようなコミュニケーションの土台をまずつかむこと。これが恐らく営業のはじめの一歩なんじゃないか、と思っています。 その土台を作るのに、まず自分のことを立て板に水を流したように話す営業がいますが、その時点で僕は「も
起業で成功する奴らの法則っぽいもの。
知り合いがかなりの数起業して、かなりの数失敗した。 飲食店からＩＴまで職種は様々だったけれど、ここに来てなんとなく法則性が見えて来たのでメモ。 ①自己資金で開業するヤツは潰す。 成功したやつは大体スポンサーを獲得して始めてる。初期資金の多寡がモロに成功率に関わってる上、 誰かを納得させてカネを出させるところから始めてる奴は強い。初期資金５０００万越えの奴らの生存率は１００％。 ②一人でやろうとする奴は潰す。 人材集めに奔走した奴らほど生き残ってる。社長の仕事量が多い会社ほど長く持ってない。 むしろ、仕事を見つけて来てから誰に振るか考えるようないい加減野郎の方が成功している。 ③友人の少ないやつは潰す。 これは圧倒的真理。起業をしようなんて奴は大体どこかクセのあるやつが多いけれど、単にクセのあるだけでは失敗してる。 起業に成功した奴らは大体友人から無利子無期限の借金（というよりは出資）を得る
会社内でもっと自分を認めてもらうための13の手口 - ガベージニュース
多人数で構成される会社の中では、個々の能力や会社内における重要度を判断するために、様々な「ものさし」が用いられる。営業成績や成し遂げたプロジェクトの数、さらには多項目から成るチェックリストで、一人ひとりの総合評価が推し量れる場合もある。それらの数字的な絶対評価の他に、上司や同僚、部下からの評価は非常に重要なウエイトを占める。周囲から「A先輩って頼れるよね」と評価されるのと「Aさん……ああ、そんな人もいるね」とほとんど無視されるのとでは、天と地ほどの差があるのはいうまでもない。【Career Success Partners】では、自分が所属する会社の中でより多くの人に自分の存在を認識してもらい、認めてもらうために欠かせない、13の手法を紹介している。 1.上司が自分に何を期待しているのかを突き詰め、それを果たすよう努力する 何を期待しているか、直接伝えることは滅多にない。会話の中で端々から
ある程度の年齢を迎えたプログラマが抱える悩み - bkブログ
ある程度の年齢を迎えたプログラマが抱える悩み ある程度の年齢を迎えたプログラマが抱える悩みに、「若手のプログラマと比べて、どうやって価値を出していくか」という問題があります。これは言い換えれば「同じような生産性であれば、相対的に給料の低い若手のプログラマに置き換えられてしまうのではないか」という悩みです。 この問題のひとつの解決策は、プログラマ以外の仕事のポジション（たとえば管理職など）に移ることですが、他のポジションには向いていない、まだまだ現役でプログラマをやりたいという場合にどんな戦略があるか考えてみました。なお、後述するように、以下に挙げた戦略は相反するものではなく、組み合わせが可能です。 エキスパート戦略 この分野ではトップクラス、というレベルの専門性を身につけ、その分野に特化してキャリアを築くという戦略です。たとえば、ネットワークやセキュリティといった分野で一流と認められる専門
第3回 なぜ日本のソフトウェアが世界で通用しないのか | gihyo.jp
日米で異なるソフトウェアの作り方 私がシアトルに来たのは1989年なので、こちらに来てもう20年以上になる。最初の10年をMicrosoftのソフトウェアエンジニアとして過ごし、後半の10年は起業家としてソフトウェアベンチャーを3つほど立ち上げている。こうやって1年の大半を米国西海岸で過ごしながらも、日本には毎年数回仕事で帰国しているし、日本語でブログや記事を書いてもいて、ある意味で「日本のソフトウェアビジネスを、一歩離れてちょうどよい距離で見る」ことができる立場にいる。 そんな私が常々感じているのは、日本でのソフトウェアの作り方が米国のそれと大きく違っていること。そして、日本のソフトウェアエンジニアの境遇が悪すぎること―そして、それが「日本のソフトウェアが世界で通用しない」一番の原因になっていることである。 そもそもの成り立ちが違う日米のソフトウェア業界 日米のソフトウェアの「作り方」の
日本人が本当に大嫌いなのは「異質な人々」 - 狐の王国
不景気だからこその移民政策のススメという記事のコメント欄に集まる外国人排斥的な言論に、移民もまた人間であるという記事でelm200さんが怒ってらっしゃる。 確かに日本人は外国人を避ける傾向がある。いや外国人どころじゃない。同じ日本人相手ですら、自分たちの言葉が通じない相手を極端に嫌う傾向がある。 言葉が通じないというのは、日本語という問題だけではない。その仲間うちで使われてる用語や名詞を知らない相手をひどく馬鹿にしたり避けたりする。 有名企業の名前を知らないだとか、名刺の渡し方を知らないだとか。日本人が「失礼」と感じるもののうち少なからずが「知らない」ことによって発生する。だから反社会的な少年たちは決まって「知らねえ」という言葉を発する。 こういった常識が形成される背景には、単一的な文化がある。万人が共通して「知っているはず」の知識というのがたくさんある。「知らないと馬鹿にされる」知識が山
スタートダッシュ型仕事術：実践編
昨日書いた「『時間に余裕があるときにこそ全力疾走で仕事し，締め切りが近づいたら流す』という働き方」というエントリー、Twitterやハテブでたくさんのフィードバックをいただいたが、その中で気になったものの一つが、「そうは言っても仕様がころころ変更になるからスタートダッシュで仕事をしていたら時間が無駄になる」というもの。 まず最初に言っておくと、「仕様がころころ変更になる」のはソフトウェアの宿命。どんなに頭の良い人が設計しても、「作ってみなければ分からない」「使ってみなければ分からない」ことはどうしてもあるので、「アーキテクチャの大幅な変更」「ユーザーインターフェイスの大幅な変更」があるのはあたりまえ。 ぜひとも認識して欲しいのは、「だからこそスタートダッシュで肝となる部分を一気に作って、早めに（仕様変更が必用かどうかの）見極めをする必用がある」という点。特に「作って見なければ分からない」部
プライベートクラウドは、ベンダから主導権を奪還する技術。メインフレームからクラウド化に成功した佐川急便グループのIT戦略
プライベートクラウドは、ベンダから主導権を奪還する技術。メインフレームからクラウド化に成功した佐川急便グループのIT戦略 佐川急便を中心としたSGホールディングスグループは、ベンダや事業ごとに作られサイロ化していた200を超えるITシステムを、クラウドに載せ替えつつ効率化するとに成功しています。 SGホールディングスグループのITを担当しているSGシステム取締役の三原渉氏は、プライベートクラウドを、オープン化によりベンダからITの主導権を取り戻す技術だと位置づけ、コスト削減による戦略投資余力の創出という効果をあげているとのこと。 同グループのクラウド戦略を知ることは、これからプライベートクラウドに取り組もうとしている企業の参考になるはずです。6月30日にフューチャーアーキテクトの主催で行われたイベント「クラウドコンピューティング戦略セミナー」から、三原氏の講演内容をレポートします。 ベンダ
日本のSIerはクラウド普及の逆風なのか？
米国には、日本のSIerのような企業はあまり多くない、という話をしばしば耳にします。「シリコンバレーで奮闘中」というya2kanta氏のブログ余道を愉しむで、7月12日月曜日にポストされた「日本とアメリカのITに関連する違い」というエントリでも、その話題が取り上げられていました。 米国のIT市場の特徴の1つ目として「SIerがいない」ことが挙げられています。 アメリカの企業はシステムの開発／導入／運用を基本的に自社内のエンジニアが行う。日本のようにSIerにアウトソースして、一切を任せるということはない。 もう1つ米国の特徴としては「パッケージ製品を利用する」ことが挙げられています。 米国では、SAPなどのERPツールや、Salesforce などCRM系ツールの導入率が高いようです。よく売れているパッケージ製品というのは、それなりにキチンと考えられて作られているので、導入／利用する事で生
ウォーターフォールの次に行け！〜日本のソフトウェア開発を今一度洗濯いたし申し候
なぜアジャイルが注目を浴びているのか 最近「アジャイル開発」が大きく盛り上がっているように感じます。大規模なイベントが開催され、MicrosoftやIBM等の大手も参画。筆者の周辺では「iPadか？アジャイルか？」という勢いを感じます。最近ではアジャイル支援の仕事も増えてきました。 では、アジャイル開発のどんなところが凄いのでしょう？ 本に書いてある通りのアジャイル開発を実践すれば本当に効果が出るのでしょうか？ 皆さんの中には、トップダウンでアジャイル導入が決まり、「どうしたらいいんだろう」と感じておられる情報システム部門の方もいらっしゃるかもしれません。 この連載では主にユーザー企業の情報システム担当者の皆さんに向けて、筆者が長年のアジャイルの実践経験を通じて学んだ「アジャイル開発における導入成功の秘訣」をこっそりお話いたします。連載の第一回はイントロダクションとして、アジャイル開発の導
内製開発を考えているSI技術者が知っておくべき内製アンチパターン - aike’s blog
数年前から、ゼネコン的なSIerの業態に構造的な限界を感じ社内のエンジニアによる自社開発（内製）を見直す動きが見られます。自分の場合も少し前にSI企業を辞めて今は内製をしていますし、知り合いの技術者にも何人かそのような転職をした人がいます。しかし、彼らの話を聞くと良いことばかりではないようです。 そんなわけで、今回は内製に潜むアンチパターンをまとめてみました。なお、ここでは一般向けプロダクト開発ではなく、社内向け業務システムの開発を想定しています。 ■そこは異業種ですよ 内製ということは、ほとんどの場合その会社はシステム開発会社ではなく、異業種に転職することになります。そのため想像以上に開発の常識が通じないことにとまどう技術者も多いようです。SIのとき、システム開発に理解がないゆえに無茶を言う顧客にあたった経験があるかと思いますが、自分以外の社員が全員そのような人であるおそれもあります。
PHPがいかに駄目な言語か、という話。 - Matzにっき(2008-01-26)
<< 2008/01/ 1 1. 年賀状 2. ゴビウス 3. [Ruby] ZSFA -- Rails Is A Ghetto 2 1. 新年会 3 4 1. The Mythical 5% 5 6 7 8 1. [言語] Substroke Design Dump 2. [言語] A programming language cannot be better without being unintuitive 3. [OSS] McAfee throws some FUD at the GPL - The INQUIRER 9 1. [言語] Well, I'm Back: String Theory 2. [言語] StringRepresentations - The Larceny Project - Trac 10 1. [Ruby] マルチVMでRubyを並列化、サンと東大が
ストアドプロシージャでシステムを構築するとDBサーバの負荷が増えるか - SQLer 生島勘富 のブログ
結論から書くとストアドプロシージャでシステムを構築するとDBサーバの負荷は減ります。WEBシステムと仮定してDBサーバとAPサーバの関係で書きますが、C/Sも同じになるので、C/Sで考える人は、APサーバをクライアントと置き換えて読んでください。 その理由は単純 極めて単純な話です。APサーバで処理しても、DBサーバで処理しても結果は同じになります。 つまり、システム全体で最低限行わなければならない処理量は同じなわけです。APサーバで処理してDBサーバの処理が減るならば、APサーバがDBサーバの処理を肩代わりしなければいけません。 APサーバが肩代わりできる処理 ・四則演算 ・ソート処理 ・マスタ類のキャッシュ（すればの話） APサーバが肩代わりさせるために増える処理 ・SQL文を大量に受け取るネットワークのコスト（AP/DB双方） ・SQL文を実行するためのオーバーヘッドの繰り返し ・A
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
