BCPという考え方。 | いすみ鉄道 社長ブログ
いすみ鉄道のようなローカル線は、鉄道会社といっても零細企業です。 こういう小さな会社は、社長が何を考え、どういうポリシ―や方向性で進んでいるのかを皆さまに直接お伝えし、ご理解いただくことが大切だと考えています。 このブログでは、地元の情報やイベントなども併せて、「いすみ鉄道の今日」をお伝えいたします。 どうぞお付き合いくださいますようお願い申し上げます。 関東南部に雪が降るとか降らないとかの予報が出ています。 先週は予報が的中して一部でかなりの積雪があったようですが、こういう時に私がいつも思うのは、ＢＣＰという考え方が日本人にはまだなじんでいないということです。 ＢＣＰというのは英語で(Business Continuity Plan）の略です。 どういうことかというと、災害などが発生してもきちんと業務を継続できるようにあらかじめ計画しておく会社ごとのプランのことです。 東京地方に大雪が降
ニュース: 愚痴はあなたのポーカーをダメにする？
愚痴はあなたのポーカーをダメにする？ Daniel Negreanu の優れたプレイヤーは泣き言を言わないというコメントを受けて、不平を漏らすことがどうプレイに悪影響を及ぼすのかについて考えてみます。 Daniel Negreanu Daniel Negreanu はいつでも人が話題にしたくなるような話を提供してくれていますが、先日の当サイトのインタビューでのスーパーハイローラーについての見解も、ツイッター上で大きな注目を集めました。中でも特に話題となったのは、最高ステークスでプレイする人たちの間の最大の共通点のひとつが、運の無さをぼやいたりしないことだという彼の考えです。 それはそういうことじゃないと思うよ。これは偶然じゃない。こういうイベントではプレイの話以外で、泣き言を聞かされることが少ないんだ。他人に力を与え てくれるような話が交わされることのほうがずっと多いね。世界を変えるような
staticおじさん達に伝えたい、手続き指向とオブジェクト指向の再利用の考え方の違いについて - 達人プログラマーを目指して
何が良いプログラムかという点はもちろん人やコンテキストによって異なりますが、少なくともプログラマーとしての私の信念としては、 機能拡張や変更が容易なプログラム 単体試験によって正しく動作することの検証が容易なプログラム どういった内容が記述されているか理解しやすいプログラム といったものこそ、「品質の高い」プログラムが持つべき性質として、まず真っ先に挙げるべき事項であると考えています。もちろん、前提として顧客の要件に従うということは大切なことです。しかし、一般に要件は長期にわたって変更されるものですし、使い捨てのプログラムを除けば、プログラムを長期にわたって保守するコストという点も見過ごすべきではありません。したがって、ユーザーの目には触れない上記の性質をもっと重視すべきだと思うのです。 DRYの原理 上記のような性質を満たすプログラムを作る上で大切になってくる原理として、DRYの原理とい
技術を伝えても、技術者の価値はなくならないという話 - プログラマでありたい
増田で、この記事が話題になっていました。 正社員に仕事を教えたくない 私は今年で契約が切れるパート。同じ部署に昨年、数歳年下の新入社員が配属された。 彼女は私が少ない仕事から数年かけて学び、また効率的に処理できるように試行錯誤して会得したノウハウを、たくさんの仕事の中でどんどん吸収している。これまで私しか使えなかったソフトも、ほぼ同じくらい使えるようになった。 この記事書いた人の仕事の内容はよく解らないので元ネタに対するコメントは差し控えます。一方で、これを見ていたIT系エンジニアのクラスタっぽい人々が、技術職にとっては技術を伝えると自分の価値が無くなるよなぁ的な発言をしているのを幾つか見たののが興味深かったです。なので、ITエンジニアにとっての技術と、それを伝えるということを考えてみました。前提として、ITエンジニアの技術についてです。製造業の技術流出は別の問題だと思うので、対象にしてい
4 月にエンジニアとなった人たちに知っておいてもらいたいこと
個人的な経験を書きますが、ぼくはエンジニア生活 10 数年で 5 社を転職して渡り歩いています。そして、その 5 社すべてでなにかしらの勉強会なり研修なりといったものをやってきました。 そして、それが仕事であろうとなんだろうと自分がエンジニアに研修なり説明会なりをするときは、自分がもらったものを返すつもりでやってきました。そのときそのときは当然所属している会社があるわけですが、その会社のため (だけ) にやったことは一度もありません。プロジェクトによって参加している人の立場も発注元だったり受託開発の常駐エンジニアだったり様々だったので、あくまで一人のエンジニア同士として自分が伝えられることをなるべく伝わるような言い方で伝えるということをやってきました。その中では所属会社へ都合の悪い話も出たりしますが、これは所属会社へのコミットメントとは別の話です (PHP 使ってる会社で PHP の悪い点
成長期ベンチャーが陥る新卒教育の罠〜 あらゆる悲鳴は“甘え”か 〜 - WETな備忘録
おうふ... IT系のベンチャーが大きくなるのを目の当たりにしてますね。時代的なことかもしれないですね。「会社の規模も大きくして自分が作った会社を盤石のものにしたい」と考えるその気持ちは分かります。そして当然「新卒を大量に採用する」というフェーズに入っていく。 しかし戦力の補充のため「新卒を大量に採用」し始めた会社が、思ったように「戦力の増強」が実現されず、期待されていたような成長曲線を描かない、という現象も多く見られるですね。これは何故なんだろうと。 それには多くの要因があると思うけれど、ここでは「新卒教育」にフォーカスをあてて考えてみた。 目次 仕事ができる者になってほしい「教育」 見落とされがちな人材の評価軸 ベンチャーの組織構成の変遷と「教育」の盲目 「組織の重心」を回復するためには まとめ 仕事ができる者になってほしい「教育」 新卒を大量に採用しはじめると、しかしその中には「仕事
プロジェクトリーダーに必要な6つの能力。スクラムの生みの親が語る、絶えざるイノベーションの創造（後編）
プロジェクトリーダーに必要な6つの能力。スクラムの生みの親が語る、絶えざるイノベーションの創造（後編） スクラムは、アジャイル開発における方法論の中でもっとも普及している方法論の1つです。スクラムという用語を用い、その考え方を最初に提唱したのは、1986年に一橋大学の野中郁次郎氏と竹内弘高氏が日本企業のベストプラクティスについて研究し、ハーバードビジネスレビュー誌に掲載された論文「The New New Product Development Game」でした。それが1990年代半ばにジェフ・サザーランド（Jeff Sutherland）氏らによってアジャイル開発の方法論としてのスクラム（アジャイルスクラム）になったわけです。 1月15日に都内で開催されたアジャイル開発をテーマにしたイベント「Scrum Alliance Regional Gathering Tokyo 2013」では、2
給料が毎月UPする会社は作れるか 〜ライフ・ワークバランスを実現出来る理想の就労環境を目指して〜 - 業務用iOSアプリのfeedtailor社長ブログ
僕は自分の会社を、就労環境の悪しき先入観をどれだけ打ち破り覆す事が出来るかを示す実験場であると説明する事があります。もちろん仕事ですから命がけで「労働」というものについて試行錯誤しているという意味なのですが。その為、普通はなかなか無い制度が沢山あったりします。 家族誕生日休暇 結婚記念日休暇 個人用Mac/iPadの購入資金支給制度 採用時の試用期間無し 副業を強く推奨 基本的に残業禁止 Twitterやfacebookの活用推奨 アイディア1つ500円Amazon券支給の提案制度 電話禁止、メール禁止 経営者である僕は、組織(内部)論的観点では「優秀な人財と最高の環境こそが冨の生産を最大化する」という持論をもっています。それを自らの組織で実験している感じ。100%成功しているとは言えませんが、 4年間でiOSアプリ開発を全て内製で80個以上リリースした実績(エンジニアは4人) 完全独立系
これってIT業界も全く同じじゃねえ？あるいは何故デカイ店のコックは育たないか：プロジェクトマジック：オルタナティブ・ブログ
僕には、いろんな人に自慢しまくっている従兄弟がいる。 彼とは1歳違いなので、小さい頃から仲が良かった。例えば、僕が最初に暗記した英文は、"This is a pen"ではなく、"Your name is shit!"なのだが、それは親の仕事の都合でアメリカに行っていた彼から、6歳の時に伝授されたのだ。 現地のガキとの戦闘用語として。 ガリ勉派の僕とは違って彼は勉強が嫌いだったらしく、若い時からフランス料理の世界で修行を重ねた。やがてシェフにのし上がり、今年になってついにオーナーとして自分の店を出した。30代で一国一城の主である。立派だ。 料理人の世界は努力と創造性と技術による、競争の世界である。そこで結果を出してきたことに対して、僕は素直に彼を尊敬している。 ちなみに、彼の料理は滅茶苦茶ウマイ。彼の料理以外で太るのは悔しいから、僕は他のフランス料理屋には行かなくなった。 先日も食べに行った
採用面接での「何か質問はありますか？」をチャンスに変える5つの質問例 | ライフハッカー・ジャパン
Jefferson McDowell氏はIT専門家であり、節約や子育て、キャリアアップなどに関するブログ「See Debt Run」を運営するブロガーでもあります。今回はJefferson McDowell氏が「就職・転職面接で使える『逆質問』のヒント」を教えてくれました。 採用面接の最後に聞かれるお決まりといえば「何か質問はありますか？」でしょう。しかし、ほとんどの面接で必ずといっていいほど聞かれる質問にも関わらず、返答を準備していない面接者があまりにも多いように思います。場合によっては、この返答は面接の中でも一番大事なものになり得ます。返答によって、面接官はあなたが何を一番重要視しているかがわかるからです。 万が一「いえ、聞きたいことはすでに聞きました」とでも答えようものなら、面接官には会社に興味がない、無関心な人だと思われてしまいます。さらに良くないのは、今までの面接の印象を一瞬で台
金を払って人に会う米国人、タダでも会わない日本人：日経ビジネスオンライン
「米国なら50万円でも数千人集まるのに日本ではタダにしても数百人ですよね」。 セミナーやカンファレンス、シンポジウムといった人が集まる催しの話である。本職は記者のはずだが催しを企画することもある。趣旨と題名の決定、プログラムの作成と講師依頼、催しの告知、当日の立ち会い、報告記事の執筆などやることは結構ある。数えたことはないもののかかわった催しの数は50回を超えているだろう。 企業や各種団体にも似た仕事を担当している方がおられる。本業を補完するためにセミナーを企画している人たちである。お会いすると必ずといっていいくらい冒頭の話になる。 例えば、IT（情報技術）関連のカンファレンスを開く場合、米国ではオーランドやラスベガスといった場所で1週間くらい開かれる。色々な値段があるものの数千ドルはする。 驚くのは冒頭の発言の通り、数千ドルを払ってやってくる参加者が数千人いることだ。失礼ながら日本で無名
日本のユーザー企業は忍者のようなプログラマーをもっと登用して重用すべきでは - 達人プログラマーを目指して
あの記事から一年、ひがやすを氏が以下のエントリーで、プログラマーとして、新しいサービスを作ることの難しさについて書かれています。 僕と君とSIerの生きる道 - yvsu pron. yas 確かに私自身は、サービスを作る側に回った(まだISIDにいるけど、ベンチャーで働いているようなものです)のですが、身を持って面白いサービスを作る難しさも経験しました。 面白いサービスを作るのはほんとうに難しい。その後、マネタイズにも成功するのはさらに難しい。サービスを作る側に回って成功するのはほんの人握りの人なんです。 もともと一年前におっしゃっていたことは、SIerのビジネスに将来性はないから優秀なプログラマーは自分でサービスを作る側に回らなくてはならないし、単によいコードを作れるだけでなくて、自分からアイデアを考えられるようにならなくてはならないということだったかと思います。一年前この記事を読んだ
僕と君とSIerの生きる道 - ひがやすを技術ブログ
SIerに対するバッシングは、高まる一方です。 私もSI業界からはさっさと抜けだしたほうがいいのエントリでSIerには未来がないからサービスを作る側に回ったほうが良いと書きました。 確かに私自身は、サービスを作る側に回った(まだISIDにいるけど、ベンチャーで働いているようなものです)のですが、身を持って面白いサービスを作る難しさも経験しました。 面白いサービスを作るのはほんとうに難しい。その後、マネタイズにも成功するのはさらに難しい。サービスを作る側に回って成功するのはほんの人握りの人なんです。 これは、自分でやってみての正直な感想。やらなきゃわからなかったことなので、自分のしたことに対する後悔はありませんが、日々ものすごいプレッシャーです。 チャレンジし続けないと落ちぶれてしまうのエントリの通り、私は現状維持を嫌い、常に新しいことにチャレンジする前向きな性格ですが、それでもこのプレッシ
第18章 製品仕様はどうあるべきかを考える
第18章 製品仕様はどうあるべきかを考える PRD よ、安らかに眠れ 製品仕様については、旧態依然とした仕様書が延々と使われているように思う。完全に製品仕様書をなくして、アジャイル開発手法を使えばいい、という人たちもいる。これには、他の問題がいろいろあるが、この主張は多くの点で外れてはいないと思う。 でも、ここは先走らずに、現在使われている紙ベースの仕様書の問題点から議論しよう。 もちろん製品仕様書と言ってもさまざまだ。まずは呼び方だが、製品要求仕様書 (Product Requirements または PRDs)、市場要求仕様書 (Market Requirements または MRDs)、ビジネス要求仕様書 (Business Requirements または BRDs)、機能仕様書 (Functional Specs または FS) などがある。これらの文書は、扱うトピックもまったく
"プライドに傷がつくことは、山頂からの景色を眺めるためであれば取るに足らない" - naoyaの寿司ブログ
http://d.hatena.ne.jp/tictac/20120110/p1 を読んで。本論とは少し外れちゃうんだけど うまくやる学生はそういう困難にぶつかったとき、自分の力不足と馬鹿さ加減に滅入る気持ちと闘い、山のふもとで小さな歩みを始めます。彼らは、プライドに傷がつくことは、山頂からの景色を眺めるためであれば取るに足らないということを知っているのです。彼らは、自分が力不足であると分かっているので助けを求めます。 このくだりはわかるような気がする。ソフトウェアの開発をやっていると、ときおり新しい言語とか、新しいプラットフォームにチャレンジしようということがある。iPhoneアプリを作りたい、とか、たまには毛色の違う言語を触ってみよう、とか。なんやかんやでもう10年以上、プログラミングはしているので、そういう新しいものを学ぼうと思ったときに、自分の能力を過信してか、いきなりそこそこ質実
いち早く70%〜80%程度の完成度で人に見せられるものを作ることがいかに重要か、という話 - 肉とビールとパンケーキ by @sotarok
去年の年末、Facebookで以下の様な画像が流れてきて自分もついついシェアしたんだけど、久々に、というか、自分にとってのここ最近の課題をドンピシャで突かれたような気がして、しばらく頭から離れなかった。 出展: 中村 修治 - 中村 修治さんの写真アルバム | Facebook 「プロ」か「アマチュア」か、というのはこの際どうでも良くて、この図の、上の曲線が、目指すべきところだなって話なだけなので、とりあえずその話をまとめてみることにする。 けど、まぁ、だいたい、こういう話をまとめるのは苦手だし途中で面倒になってしまうので、以下サブセクションだけ先に作ってみたものの、ちゃんと書くかどうかわからない... が、まあ、いい！あと、なんかグダグダ書いてしまいそうだけど、結局、サブセクションのタイトルにしたことをこねくりまわしているだけです。 作ってみるまでわからない 何にも言えることだけど作って
品質に厳しい組織で、なぜ品質が劣化するのか？ - 現場のためのソフトウェア開発プロセス - たかのり日記
このエントリーは「Software Test ＆ Quality Advent Calendar 2011」における12/18分として書いています。 12/17は @NoriyukiMizuno さんによる 「ソフトウェアテストの勉強会。1年目。」 というエントリでした。 今回は、以前から感じている矛盾について、私なりの考えをまとめたものです。 特に、マネージャーや経営層と呼ばれる人に読んでもらいたいと思っているのですが、このブログの読者層を、考えると、あまり多くはなさそうなので、以下に示す問題について、悩んでいる／苦しんでいるような人から、うまく伝われば良いと思っています。 矛盾する問題 私は、SEPG（Software Engineering Process Group）という役割上、いろいろなソフトウェア開発のプロジェクトや組織に関わってきました。 絶対数で言えば、そんなに多くはない
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
コードの複雑さを上げずに「世界の複雑さ」と戦うために読んでおきたい良書5選【2012年のインプットlog-和田卓人】 - エンジニアtype