原発稼動するしないではなくて事故の責任明確化を争点にしてほしい - アンカテ
食中毒でも責任者は処罰されるんだから、原発事故の責任を取る人がいないのはおかしい。 責任を取らなくていいならやることを変えられるとは思えないので、それを前提にするなら、現実的な比較は、脱原発か次の原発事故かどちらを選択するのかという話だと思う。 どちらにしても経済は滅茶苦茶になるが、事故で滅茶苦茶になるのは経済だけではないので、その比較なら脱原発の方がまだマシだと思う。 私は、3.11後しばらくは、「自分は数年後餓死するのかもしれない」と考えていた。原発を止めたら経済が破綻して、自分の仕事はなくなり、文字通り食えなくなるかもしれないと思った。それでも原発は止めるしかないだろうと思った。議論するまでもなくやがてそうなると思っていたが、幸か不幸か、その予想ははずれた。自分が普通と思うことが、世の中からとんでもなくズレていた、ということは何度も経験があるが、今回は特にそれを痛切に感じた。 しかし
9割の起業家がやってしまう5つの失敗
1970年生まれ。「従業員１０名以下の会社」を専門とする税理士。 クライアント先を「小規模でも超優良な会社」「しっかりと利益の残る会社」「経営者、社員が幸せになる会社」にするためのサポートを行っている。そのため、一般的な税理士業務に加えて、経営戦略や会計・財務の面からのアドバイスにも力を入れている。 大学卒業後、10年半の会社員生活ののち、脱サラし、山本憲明税理士事務所を設立。順調に売上を伸ばしていたが、将来の税理士業界や経営の在り方に疑問を感じ、最小限の人数での効率的な経営に方向転換。６人いたスタッフを１人にした。 1000人を超える中小企業の経営者と会い、税理士業務の傍ら、「経営」と「実生活」のバランスのとれたライフプランを提案することを心がけている。 「1人でも多くの経営者の手助けをしたい」との思いから、小規模企業の経営者を対象とした「ひとり経営戦略塾」を運営するとともに、「ナノ企業
継続インテグレーションは強みではなくなった: 柴田 芳樹 (Yoshiki Shibata)
Subversion/Gitなどを使用したソースコード管理、Jenkinsを使用した継続的インテグレーション、様々なxUnitフレームワークを使用した自動テストなどをソフトウェア開発組織として実践することは、今日では、その開発組織の技術的な強みではありません。 それらを実践しないことが、ソフトウェア開発組織の「弱み」なのです。また、組織としてそれらの実践を推進しない、あるいはサポートできないマネージャも「弱み」となります。さらに、大規模なソフトウェア開発組織においては、それらのためのインフラ整備をプロジェクトごとに立ち上げなければならず、サポート部門が存在しないことも弱みとなります。※1 ※1 プロジェクトを始めるごとに、ソースコード管理やJenkins用のサーバの調達、OSから様々なツールのインストールを一通り行うためには、それなりの時間を要します。したがって、バックアップをも含めて環境
最近の開発現場はギャグとしか思えない - rabbit2goのブログ
知人とコソコソと世間話。最近の開発現場は面白いことが多過ぎるという点で意見が一致してしまう。その一例。 人の入れ替わりが激しくて技術やノウハウが蓄積しない。忙しくなるとスキルよりも経験よりも頭数を揃えることを主目的にやたらと人を集めるものの、プロジェクトが終わると直ぐさま関係を切ってしまうので継続的な蓄積が何も残らない。 コンプライアンスの掛け声の下、関係者以外にも情報が見えてしまうホワイトボードやRedmineによる情報共有はご法度。セキュリティ対策も厳しくなる一方なので、ソフトをダウンロードしてパソコンに入れるだけで、正義感の塊のような監視委員から直ぐさま電話がかかってくる。 行き当たりばったりの対策を取り続けているので、何か問題が有ってもブレーンストーミングで出てきたようなアイデア案ばかりが続く。根本原因を探ることをしないし、そもそもそんな追求を行うスキルすら無い。 人月単価に惹かれ
『SIエンジニアの自分戦略 -急がば回れ、選ぶなら近道-』ノート
2012/10/09に開催された『SIエンジニアの自分戦略 -急がば回れ、選ぶなら近道-』のノートです。 SIをやっている人には是非読んでほしいです。私のノート作成スキルを割り引いてもさておいても …です。 ※(2012/10/10追記)上の文について、言葉の選び方が不適切だったので修正致しました。「私の資料作成能力の限界で、okachimachiorz1様の伝えたいことの半分も伝わっていないかもしれない。だけど、それでも読む価値がある内容です」ということが、上の文で私が言いたかったことです。申し訳ないです。 ◆今日の勉強会について ◇今日の構成 ・最初にokachimachiorz1様の話を40分くらい ・その後休憩を挟んで来ている人達で感想、深く聞きたいということを皆で話合う ・Q&A ◇この回をやろうと思った経緯 ・okachimachiorz1様のブログを一生懸命呼んでいるうち、そ
受託開発脳から自社開発脳へ切り替えの7つの壁 - ヴェルク - IT起業の記録
これ、思ったより大変でした。 自分含め、うちにいるメンバー全員、 これまでの経歴では受託開発をメインにやっていたため、 自社サービス開発の経験はかなり少なかったです。 でも、ヴェルクでは、受託開発をしつつ、 時間を作って色々と作っていこう、というスタンスのため、 起業直後から色々と企画を考えていました。 でも、受託開発脳から自社開発脳への切り替えは思った以上に苦労しました。 要件定義等でお客さんと一緒に要件を考えたりしますが、 最終的に「やりたい事」を持っているのはお客さんになります。 要件定義の前の企画やグランドデザインと言った分野は お客さんの戦略に沿ったものになります。 だから、最終的には、誰かが答えを持っている事が殆どです。 そのため、ゼロからそれを考える事があまりないんですよね。 いざ、ゼロから自分たちで企画を考えようと思った時、 いろいろと壁がありました。 1. 本当の意味での
伽藍、バザール、ノウアスフィア、おなべ(3) L'eclat des jours(2012-04-11)
_ 伽藍、バザール、ノウアスフィア、おなべ(3) さてやっと1998年春を迎えて『ノウアスフィアの開墾』だ。おそらく、伽藍とバザールにくらべてがくんと知名度は落ちる（つまり、みんな2項対立は大好きだけど、協調の話や未知の用語には興味がないんだろうなぁと勝手に推測しているおれだった）。 ノウアスフィアとは、『ヌースフィア』（でぐぐれ）のことで、ぐぐればわかるが、すさまじく怪しい用語だ。もっともこの論文の中ではソースコードが存在する思考空間を意味している。 この論文のテーマは、なぜハッカーはソースをオープンにするのか、なのだが、内容はむしろ、「なぜオープンソースは、ソースの自由な改変を許すライセンスなのに、改変したソースが元に戻るのか？」の解明に軸足がある。 推測だが、ネットスケープをはじめとする企業が自社のコードベースをオープンにした場合に、そこから知らないうちにフォークされてもっとうまいこ
プロジェクト・マネジャーが知るべき97のこと
プロジェクトの様々な局面で意思決定を迫られるプロジェクト・マネジャー。本書は世界中で活躍するプロジェクト・マネジャーによる97本のエッセイを収録した書籍です。ソフトウェア開発においてマネジャーに求められることは何か、人とチーム、さらにステークホルダーの管理、プロジェクトプロセスやプロジェクト要求、契約、国際化への対応と地理的に分散したチームの管理などについて、経験豊かなプロジェクト・マネジャーが自らの体験を踏まえて解説します。プロジェクト・マネジャーを勇気づけ、新たな気づきをもたらす一冊です。日本語版には、奥沢薫、神庭弘年、重木昭信、芝尾芳昭、冨永章、初田賢司、林衛による11本の書き下ろしを収録。 目次 監修者まえがき はじめに 01 できるだけ早期にユーザーを巻き込む バービー・デイビス（Barbee Davis） 02 モグラたたき開発を避けよう ベンカト・スブラマニアム（Venkat
伽藍、バザール、ノウアスフィア、おなべ(1) - L'eclat des jours(2012-04-09)
_ 伽藍、バザール、ノウアスフィア、おなべ(1) エリック・レイモンドの伽藍とバザールが19991997年(翻訳版の日付を最初書いていた。以降修正済)なので、もう15年も昔のことなのか。それだけ年月がたてば、ソフトウェア開発者でも、プレジデントやダイヤモンド並のいい加減な知識でいい加減なことを書いたりしたりするのだなぁと感慨もある。 感慨もあるが、少なくともソフトウェア開発そのものを仕事にしているのなら、もう少しまともな知識を持つほうが良いんじゃないか？ とも思う。 というわけで、読まずに済ませるOSSの歴史入門を簡単に書いてみたり。 ただ、どれも読めばささっと読めるものばかりなので（山形浩生の訳も読みやすい）、リンクもつけたし本物を読んでももちろん良い。 まずは、『伽藍とバザール』だ。 さて、1997年。Linuxが実用的なOSになってきたころの話だ。FSF（GNUの組織）が1980年代
langturn.com is coming soon
is a totally awesome idea still being worked on. Check back later.
2012.03.24開催
アジャイルサムライ他流試合から半年、原著者を迎えて他流試合はAgile Samurai Dojo Gatheringと名前を改め、ふたたびの道場大集合となるイベントを開催します。 今、日本で一番熱心にアジャイルについて語っている人達の経験に触れ、それを自分の言葉で議論する事でアジャイルサムライへの新たな一歩を!! 開催概要 日程: 2012.03.24(土) 10:00 - 18:00(予定) 会場:オラクル青山センター （東京都港区北青山2-5-8） 参加費用: 早期割引(3/12(月)まで):4,000円(税込)終了しました, 通常料金: 6,000円(税込) 懇親会: 前売:2,000円(税込), 当日:2,500円(税込) 運営: Agile Samurai Dojo Gathering 2012実行委員会, (株)永和システムマネジメント ハッシュタグ: #agilesamura
nabokov7; rehash : ライブドアという会社の話をしよう - Q12. 次世代ブログサービス(になるはずだった) nowaの撤退をどうみた？(下)
March 10, 201213:50 カテゴリライブドアという会社の話をしよう ライブドアという会社の話をしよう - Q12. 次世代ブログサービス(になるはずだった) nowaの撤退をどうみた？(下) さて、前回からの続き。 社運をかけて招集された nowa の開発チームは、プログラマ、ディレクター、デザイナー、マークアッパ、どれをとっても精鋭チームというべき豪華な面子が勢揃いしていた。 一方の「旧ブログ」チームは、それまで一人でブログを支えて続けていたベテランのエンジニアが辞め、あとを僕ともう一人とで継いだものの、その片方の人も別会社に移って行ってしまって、エンジニアは僕一人だけになっていた。マネタイズのプランもなくただの金食い虫だった「旧ブログ」には大した長期戦略も与えられず、広告営業案件の狩り場と化して、宣伝用のブログパーツばかり作らされていた。 基本的に旧ブログチームの役割はデ
視点・論点 「職場のパワハラ 解消への取り組み」 | 視点・論点 | 解説委員室ブログ:NHK
東京大学教授 佐藤博樹 厚生労働省に設置された「職場のいじめ・嫌がらせ問題に関する円卓会議」のワーキング・グループが、今年の1月30日に、職場のパワーハラスメントに関する報告書をとりまとめました。 円卓会議が設けられた背景には、職場のいじめ・嫌がらせが、近年、社会問題として顕在化してきたことがあります。 職場の「いじめ・嫌がらせ」という言葉を使いましたが、同じ内容に関して「パワーハラスメント」も使われています。そこで以下では、「パワーハラスメント」あるいは「パワハラ」を使うことにしたいと思います。 職場のいじめ・嫌がらせに関する相談は、図にあるように、平成１４年度は約6,600件でしたが、年々増加し、平成22年度では約39,400件となっています。 また、従業員個人に対するアンケート調査によると、図にあるように、「職場で自分がいじめにあっている」とした人は約６％で、「職場でいじめられてい
品質に厳しい組織で、なぜ品質が劣化するのか？ - 現場のためのソフトウェア開発プロセス - たかのり日記
このエントリーは「Software Test ＆ Quality Advent Calendar 2011」における12/18分として書いています。 12/17は @NoriyukiMizuno さんによる 「ソフトウェアテストの勉強会。1年目。」 というエントリでした。 今回は、以前から感じている矛盾について、私なりの考えをまとめたものです。 特に、マネージャーや経営層と呼ばれる人に読んでもらいたいと思っているのですが、このブログの読者層を、考えると、あまり多くはなさそうなので、以下に示す問題について、悩んでいる／苦しんでいるような人から、うまく伝われば良いと思っています。 矛盾する問題 私は、SEPG（Software Engineering Process Group）という役割上、いろいろなソフトウェア開発のプロジェクトや組織に関わってきました。 絶対数で言えば、そんなに多くはない
会議室につながれた首輪を外そう：日経ビジネスオンライン
今回は、私がこれまで出席した会議の中で、もっとも「キツイ」と感じた会議を初めに紹介したい。 どんな会議だったかというと、まず会議の時間は「8時間」。会議の参加者は「不明」（10～13人か）。会議目的は「顧客への提案内容の検討」。会議の結論は出ず、私に「丸投げ」。こういう会議であった。 詳細を書いていこう。 推測だけで「あーでもない、こーでもない」 私が上司から呼び出されたのが午後4時である。そのとき私はある顧客対応に追われており、デスクに張りついて手が離せない状態だった。しかし上司に「すぐ終わるから」と言われ、私は無理やり会議室に連れ込まれた（ちなみに私を会議室に引っ張り込んだ上司はほかの会議室へと姿を消した）。 まだ分煙のポリシーがない時代だった。会議室内にいたマネジャーたちはこぞってたばこをふかし、パチンコ店かと思うぐらいに室内は曇っていた。私はたばこを吸わないので、1歩室内に入ると、
［課題管理編］ツールを押し付けてはいけない
課題管理に向くサーバーソフトやGoogleドキュメントといったクラウドサービスなど、便利なツールを手軽に利用できる環境が整ってきた。そうしたツールを使うと、効率よく課題管理ができる。 しかし、ツールを導入しさえすればうまくいくとは限らない。特に、複数の開発現場を担当する「掛け持ちプロマネ」にとって要注意である。 掛け持ちプロマネは、それぞれのプロジェクトの管理業務に十分な時間を割けないもの。そこで「ツールでカバーしよう」と考え、課題管理のツールを現場に導入し、メンバーにツールを利用してもらって管理の効率化を図ろうとする。そして、ついメンバーにツールの利用を任せきりにしがちになる。 確かにツールは便利なものだ。だが、それを現場に押し付けてはいけない。 入力の煩わしさなどでツールが使われず このことは筆者の実体験から言える。以前に筆者が担当していたあるプロジェクトでのこと。そのプロジェクトでは
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
TechCrunch
エンジニアtype 技術者のキャリアを考えるWebマガジン - 転職＠type
TechCrunch | Startup and Technology News
https://www.jitu.org/~tko/cgi-bin/bakagaiku.rb?bakaid=20120222