[連載]Webデザイン入門（1日目） | Stocker.jp / diary
本日から新たに、「Webデザイン入門」というタイトルで連載を始めます。 9月からWebスクールの講師をさせていただいているのですが、そこでカリキュラムとして渡されたテキストには「Photoshop や Dreamweaver 等のソフトの操作説明」しかされておらず、ソフトの操作方法を習得しただけではWebデザイナーとして就職し、仕事していくのは少々厳しいのではないかと思いました。 そこで、ソフトの操作方法と平行して「Webデザインそのもの」について考える時間を設けたいと思い、オリジナルのカリキュラムを作ることにしました。 ここでは、そのカリキュラムの一部をブログ形式にして掲載しています。 既にWebデザインの仕事をされている方はご存知のことばかりかもしれませんが、これからWebデザイナーになりたい方や、今はプログラミングなどデザイン以外の仕事をされていて、これからデザインも手がけてみたいと
![[連載]Webデザイン入門（1日目） | Stocker.jp / diary](https://cdn-ak-scissors.b.st-hatena.com/image/square/8aeba51f4329633993f3f50c3007e124fe9a30ab/height=288;version=1;width=512/https%3A%2F%2Fi0.wp.com%2Fstocker.jp%2Fdiary%2Fwp-content%2Fuploads%2Fb433d63ba5e7a465dbac23082f36bb7f-500x375-1.png%3Ffit%3D500%252C375%26ssl%3D1)
だからwebもリアルと同じでがんばらないとダメなんだって
精神論とかそういうのあまり好きじゃないので、こういうのもなんなんだけど、結構最近よく見かけたり、時には聞かれたりする。 webって儲かるのとか、iPhoneアプリは儲かるらしいね！とか、ブログって儲かるのとかうんぬんかんぬん。 いやそりゃ儲かるっちゃ儲かるんだけど、儲からないっちゃ儲からないわけで、その謎の儲かる感はどこからくるのかなと不思議でしょうがない。特に個人でも色々と始める事ができるのがネット。個人でやるからこそ忘れてはいけないものがあるんじゃないかなぁと。 ※写真はなぜかiPhoneにさして受話器で通話するというオモシログッツを東京で見かけて思わず撮影したものです。 『楽して儲けるカラクリにはまってはいけない』 突然電話きて、情報商材をかったんだけど書いている内容がちょっといまいちと言う事で相談に乗ってきました。 早速、ハンバーグランチでも食べながら資料を見せてもらいました。 内
2011-09-27
欧米（特にアメリカ）の入学試験や、外資系企業の面接で常に聞かれるのが、「あなたのリーダーシップ体験について話してください」という質問です。 大学の入試エッセイでも書かされるし、大学や企業の面接では、過去にどんな場面でどうリーダーシップを発揮したか、事細かに聞かれます。 もちろん入社してからも、リーダーシップは主要な評価項目のひとつとなっています。 ところが日本ではリーダーシップについて問われる機会はごく限定的。中には「今まで、一度も問われたことがない」という人さえいます。 なので、その概念自体あまりよく理解されていません。 たとえば私が日本人からよく受ける質問は、「欧米ではなぜ全員にリーダーシップを求めるのか？」というものです。 質問の意図は、「リーダーシップという、組織を率いるごく少数のトップ人材だけが持っていればいいものを、なぜ欧米の大学や企業は全員に求めるのか？」とか、 「 10人の
オフェンシブな開発〜「納品しない受託開発」にみるソフトウェア受託開発の未来 | Social Change!
定期的にSI業界が終わったという話が出ますが、本当にそうでしょうか。終わるべきは一括発注・請負のディフェンシブなビジネスモデルです。受託はなくなることはありません。ソフトウェアの開発を、他の業界のアナロジーで考えるのではなく、正面から取り組んだビジネスモデルについて語っています。 ディフェンシブな開発 今から5年前に、SI業界における多くの問題の原因がそのビジネスモデルにあるという「ディフェンシブな開発〜SIビジネスの致命的欠陥」という記事を書きました。SIにおけるビジネスモデルは、発注者とベンダーはあらかじめ決めた金額と要件の中で納品と検収を目指すため、利益を出すためには双方がリスクを取らずに「守り」に入る必要があります。その結果、顧客にとって価値を産むかどうかよりも決められた要件通りに作られることを重視することになってしまいます。人月という単位であらかじめ決めるとなれば、単価の安い下請
プログラミングは「名前」が9割。 - このブログは証明できない。
プログラミングというのは、名前をつける行為なんだと思う。 プログラミングで一番大切なこと。 もしも、プログラマーじゃない人に、「プログラミングで一番大切なことは？」と聞かれたら、迷わず「名前」だと答える。もちろん、人それぞれだし、自分はスキルの高いプログラマーじゃないよ、と前置きして。 名前が9割と言ったときの、9割という部分は人によってだいぶ差があるんだと思う。もっと小さいかもしれない。けれど、名前が重要だという点に関しては、反対するプログラマーはいないんじゃないだろうか。 時代や環境で変わる名前。 いま僕がイメージしてる名前というのは、変数名だったり関数名だったりクラス名だったり、とにかくいろいろ。さらに、JavaScriptとか高階関数をバリバリ使うような場合など、名前をつけないという選択肢もある。 なんとなくJavaScriptと書いたんだけど、名前はプログラミング言語や開発環境や
工数見積もりで陥りやすい罠 - プログラマの思索
「ソフトウェア見積り」を読んだ後に「アジャイルな見積りと計画づくり」を読み直したら、とても理解しやすかった。 理解できたことをメモ。 間違っていたら後で直す。 ※追記：一部修正した。 ※追記：Velocityの計算方法を「塹壕よりScrumとXP」から参照するようにした。 【元ネタ】 Twitter / @akipii: 見積について色々考えている。1.0MD(人日)という単位は規模・出来高・工数という複数の意味を持ち混乱しやすいから、ソフトウェア開発の計画づくりに支障をきたしているのではないかという仮説を考えている。その考えを深めるとScrumのストーリーポイントはよく考えられた概念だと思う。 アジャイルサムライで一番難しくて面白い概念～Velocity: プログラマの思索 ソフトウェア開発に特有な技術～ソフトウェア見積り: プログラマの思索 チームは加速するのか～Velocityの使い
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
