リストラされる寸前だったときのこと - グローバル経営の極北
少し個人的な話を。 ここで書いたように、2008年の夏ごろの私は、コンサルの仕事でまったく成果が出せずに、長年の持病にも悩まされ、完全に八方塞がりの状況。しかも業績の不振から、会社ではリストラのプログラムが動き始めていました。 そして「使えないコンサル」だった私は、案の定その対象の一人となり、異動先が見つからなければそのまま退職せざるを得ない状況に。 でも、ここまで追い込まれて「負けず嫌い」の火がつきました。自分を売り込むプレゼン資料を徹底的に磨き込んで、社内の知り合いには異動の可能性を聞きまわり、前職のメーカーの事業部門長に久々に会ってもらい状況を聞き、同時にエージェントに会って転職の可能性も探りました。 その努力が実り、社内の間接部門で人を募集しているという話を聞きつけ、面接の機会を得ることができました。改めて「売り込み」資料を磨き直して、面接に向けて準備。転職の面接ばりの真剣さでした
わたしのバイモーダル戦略 : 小野和俊のブログ
このところ知人からよく、「小野さんはプログラマーから経営者になった」と言われる。これはまさにその通りで、かつてソースコードを美しくリファクタリングすることに情熱を燃やした私は、いまは組織をより良いものにしていくことに情熱を燃やしている。つまりリファクタリング対象がソースコードから会社に変わったのだ。 そんな私が今やや苦戦しつつもやりがいを感じて取り組んでいるのが、「2つの異なる文化の共存協調」だ。具体的には、大企業的な文化とベンチャー的な文化を共存させ、かつ協調させようにしようとしている。ウォーターフォール的な文化とアジャイル的な文化の共存協調、と言い換えることもできるだろう。 アプレッソでかなり自由にやってきた私にとって、当初、セゾン情報の動き方は不慣れであり、また動きが遅く感じることもあった。だが少しすると、こうした動き方や文化にも相応の合理性があり、アプレッソで取り入れることが望まし
わたしが新入社員の時に学んだこと | タイム・コンサルタントの日誌から
紅海を見下ろすホテルのレストランで、私たちは食事していた。相手はサウジアラビア有数の財閥企業のBusiness Development担当ディレクターだ。いわゆるアラブ風の白い民族衣装ではなく、ふつうの背広にネクタイの服装をしている。年齢は、たぶん私と同年代か、少し若いかもしれない。しかし財閥トップの信任の厚い彼は、もうすぐ役員のポストに手が届くだろう。 戒律厳しいサウジの食卓では、けっして酒は供されない。それでも、一緒に食事をするというのは、知り合ったばかりの人間同士がうちとけるには最良の手段の一つだ。デザートを食べ、食後のお茶やコーヒーを飲む頃には、出自を含めていろいろなことを話し合うようになっていた。 レバノン出身の彼は、きわめてきれいで立派な英語を話す。イギリスの大学を出て、英国企業に就職し、さらにMBAを取得して別の会社のポストを得た。結局、11年間イギリスに住んだという。それか
就職して9年が過ぎる - 兼雑記
転職して7年が過ぎたというのを読んで気づいたんだけど、そろそろ入社後9年が経過したらしい。僕は結構長い期間をここで過ごしたことになるんだなと思った。ちょっと以前のことを振り返ってみようと思う。言うまでもないけどこれは僕の書ける範囲での個人的な感想と体験談であって会社の見解等を表しているものではない。 きっかけ わりと重要でない Borgチーム (の周辺) いつのまにやらBorgという名前を普通に言って良くなっている。嬉しい。まあ当時もぶっちゃけ、秘密だから出してないっていうよりは、単に誰もアカデミア的なキャリアに興味が無いから出してなかったんだと思う(私見)。 さて、当時Borgというかクラスタマネージメントのあたりでは、コンピュータのリソースて適当にたくさん使ってるけど、これ節約したらすっげー支出減ったりしない？みたいなのがホットで、なんかとりあえず色々な人々が色んなことをやっていた。い
日本でインターナショナルチーム文化を作る方法を考えてみる - メソッド屋のブログ
今まで、幾つかのポストで書いてきたのですが、私は今のインターナショナルチームのポジションをとても気に入っています。楽しく、気に入ってるだけではなく、実際の生産性やワークライフバランスも過去最高です。 私は、「Be lazy」の回で書いた通り、「Be Lazy」を極めるために、「エッセンシャル思考」を実践しています。日本Microsoftは相当素晴らしい会社ですが、それでも、正直いうと、日本で「エッセンシャル思考」を実践すると、若干肩身が狭い思いをします。かといってこの人体実験をやめるつもりはありません。私の職業上の次のゴールは、「世界のどこでもご飯を食べられる様になること」だからです。 simplearchitect.hatenablog.com 一方、「Be Lazy」の考えを、チーム丸ごと受け入れてくれて実践しているお客様がいます。そうか、チーム丸ごとその考えを受け入れるならば、問題な
プログラムにコメント書かない文化もあるよって話｜NZ MoyaSystem
以下の記事を読んで。 530000micro.hatenablog.com 僕が勤めている会社では、原則、プログラムにコメントを書かないのがルールです。 人生で初めてプログラムに触れてからこのかた、プログラムには必ずコメントを書けと指導されて来ましたし、自分自身も、後輩たちにちゃんとコメント書けよと言い聞かせてきました。そんなわけで、最初に全然コメントのないソースコードの山を見たときは、正直「ゲッ、なんじゃこりゃ……」と面食らったのは確かです。 ところが、「なぜうちのプログラムにはコメントがないのか？」と同僚に尋ねてみると、実に納得の行く回答が返ってきたのでした。 なぜコメントが必要なプログラムを書くのか？ 同僚いわく、「コメントが無くても読めるようなプログラムを書け」という思想が根底にあるのだそう。 適切に関数や変数が命名され、スコープがきちんと管理され、ロジックの流れが整理されているコ
GxPで学んだ、ただ一つのこと - Digital Romanticism
パラダイムを学ぶことと、実際にデリバリーすることとのバランスについて。あるいは転職報告。 導入 9月末を以て、グロースエクスパートナーズ株式会社を退職しました。４年と２ヶ月の間この会社にお世話になっていたことになりますが、その中できわめて多くの貴重な経験をさせていただいたと思っています。退職を決めてから、４年前に自分が書いたエントリ（SIを仕事にするということ）は何度か読み返しました。その中でGxPを表現した次の言葉は、今読んでも正しかったと思います。 ソフトウェアをデリバリーすることには、多くの「泥臭い作業」が伴います。そしてその「泥臭い作業」は本に書かれたり、語られたりすることがあまりない。それはたぶん、語るまでもなく当たり前のことであったり、語れるほどには言語化されていなかったり、語るほど面白くなかったりするせいでしょう。だからといって、「そういうこと」をしなくていいわけではない。こ
Shibu's Diary: ソフトウェアの世界は螺旋を周りながら進歩している
渋日記@shibu.jp 渋川よしきの日記です。ソフトウェア開発とか、ライフハックを中心に記事を書いていきます。 npm周りでごたごたがありました。その前にはCocoaPodの問題もありました。その前にはGemの話も話題になりましたよね。 うんこれ。2年ぐらい前にnode.jsで開発していた時にも、node.jsのnpmのエコシステムいつか破綻するよなぁって思ってた。で、去年cURL as DSL作ったんだよね。Rubyのコード生成はまだないけどね。 https://t.co/1C0yw0KPib — 渋川よしき (@shibu_jp) March 6, 2016 上記のツイートはgemに絡んでのツイートであって、コンテキストはnpmではなかったのだけど、なんか予言めいたツイートに見えちゃったのかもしれないけど偶然です。ここまで、いくつかの文化の変化がありました。 SourceForgeや
日本でアジャイル / DevOps 導入が進まないのは「文化」を変えないから - メソッド屋のブログ
私が初めてeXtreme Programming に出会ったのは確か2000年だと思う。実際に初めてのプロジェクトを実施したのが2001年。それからすでに15年が経過していることになる。そんな長い間アジャイル、そして DevOps の日本での導入に関わってきた。日本のアジャイル導入に関しては全て成功とは言わないが、かなり成果は上げてきたとは思う。だけと、今日は自分の導入ポリシーの誤りに気付いて、新たなステージにいける気がしたので、そのことを共有してみたい。 2002年 尊敬するアリスターコバーンと、XP JUG関西のメンバーと清水寺で。私が写真撮ってたのかなw Alistair.Cockburn.us | Alistair's first trip to Japan sept 2002 日本はアジャイルの導入がこれからという噂を聞いたけど本当？ これは、私がマイクロソフトの面接の時に、当時
「メールの添付ファイルにパスワードかけて、別メールでパスワードを送る」に言いたいこと - 病みつきエンジニアブログ
(2015/8/29追記) 最初に代案だけ書いておくと、(メールで送る程度の秘匿性のものは)「Proself」みたいな別プロトコルを使う、です。 メールパスワードでは、パスワードに規約をつけることもできません。 また、この話は企業等においてのルール化の話です。 ファイルをZIPで暗号化し、まずZIPをメールで送り、しばらくして別メールで8文字程度の乱数パスワードを送るという謎のプロトコルが日本企業で流行っているが、ZIPのパスワードは総当たりでかなり高速に解析できるし、そもそもパスワードをメールで送っているので効果が疑問。— Daiyuu Nobori (@dnobori) June 17, 2013 もう何年前のネタなんだろうという感じでもあるのですが、2015年現在もこの慣習はなくなっていないように感じます。 実際社会人になってからも、残念なことに一度言われたことがありますし(受け売り
転職してから4年が経ちました - 科学と非科学の迷宮
といっても4月1日の話なのでもう一ヶ月以上も前になるのですが、色々と忙しくて後回しにしてました。 ブログで転職報告してから4年の間、どういう仕事をしてきたのか書いてないことに気づいたので、せっかくなのでちょっとまとめてみようと思います。 1年目(2011年) 「朝、ベッドから起きると、そこが職場になっていた」 この感覚は今でも忘れません。オフィスも同僚もいなかった私は、在宅勤務という形で Cloudera での仕事を始めました。1Kの小さいマンションに住んでいたため他の作業部屋がなく、自分のベッドの横の机がそのまま仕事場になりました。 サポートエンジニア(今は COE = カスタマー・オペレーション・エンジニアという名前になっている)として今の会社での仕事を始めたのですが、肩書き通りの仕事だけをしていればいいなんていうことは当然あるわけもなく、日本にいる唯一のエンジニアとして何でも仕事をこ
メールに返信をしないアメリカ人のメンタリティ - Thoughts and Notes from CA
「メールでアメリカ人に問い合わせをしているが返信がこない」、というのは外資系企業に勤めていればよくある話。その内容が難しければ難しい程、返信率は悪くなる。もちろん、日本人でもレスの遅い人、しない人はいるが、度合いの問題。アメリカ人の場合はかなり気合をいれて、しつこくプッシュしないと返事がもらえないことが多い。 一番良いのは電話をすることで、電話をしてみると「おぉ、あの件ね、見た見た」みたいな感じで話が進むことが多い。メールで聞いていることを一々電話しないといけないのはかったるいし、時差や言語の問題があって容易ではないし、そもそも「お前、見てるんなら返信くれよ」という思いもある。 でも、そういうことで頭を痛めている人は、理解しておいたほうが良い彼らのメンタリティがある。それは「何度もプッシュされないということはきっと大事なことではないんだ」という考え方だ。メールを出して返信がしばらくこないも
クソコードと呼ばない - ppworks.jp
新しい現場にはいったときに心がけていること、クソコードと呼ばないこと。 誰かのコードを読んでいるとそりゃまあクソコードを見つけることがある。その時どう立ち向かうかという精神論の話。 例えソレがそうであってもソレを口にするとネガティブが蔓延する。思ってもイイ、でも言ってしまってはならない。あるフェーズに置いては必要だった し、現に動いていて価値を提供している のだ。あるべき姿を叫ぶの簡単だ。あるべき姿を見ているなら行動しないといけない。見つけたらリファクタだ。出来るところからやるんだ。 Shut the fuck up and write some code & 許可を求めるな Pull Request せよ— 🌈KOSHIKAWA (@ppworks) 2014年5月23日 クソはクソと言える空気や文化は大事。良くないものを指摘できるようにはしたい。口の前に手を動かそう。プログラマーなら
コードレビューをし合える文化がチームを強くする - ppworks.jp
コードレビューしてますか？ 「コードレビューをしよう - pblog」でも触れたのですが、 今回はコードレビューの話です。 コードレビューって何からして良いか分からなかったり、レビューアーに負担なんじゃないか、、、って尻込みしがちですが、レビューしてもらう前に気を付けること、なにをレビューしてもらうのか、そして逆にレビューするのか、そして何が起きるのかあたりを考えていきましょう。 レビューして貰う前に気を付けること レビュアーの負担を減らすのは大事です。 コーディング規約に沿っているか？といった簡単なレビューは、犬にやらせるという方法もありますが、そもそもgit-pushする前に、ローカルのgit-commit時点で対処しておくというのもありです。 犬 is rubocopですし、 rubocopやjshintなどをgit-hookにまとめて設定できるpre-commit gemが便利そう
クリエイティブな人は趣味にお金がかからないというのは本当か？ - ふろむだ＠分裂勘違い君劇場
自分で「文章書いて、絵描いて、楽器を弾いて、プログラム書いて、写真とってれば」それだけで楽しい、という人がいる。 それにはまったくもって同意なのだが「それにカネがかからない」という点には全く同意できない。 私は、趣味で文章を書いたり、写真を撮ったり、サイトを作ったりしているが、ものすごくお金がかかる。 たとえば、私は娯楽小説を書くのが好きなのだが、これって、パソコンとテキストエディタだけでは書けない。 これは「娯楽」小説なのだから、面白くないと話にならない。とことん面白くなるまで、何度でも執念深く書き直す。そのうちに、足りないものが見えてくる。 そして、足りないものを補うには、金がかかることがわかってくる。 想像だけで書いている文章って、やっぱ面白くならない。ジブリの背景の木は、想像で書いたものは１本もないという。全部観察して書いているそうだ。小説も同じで、現実を精密に観察し、登場人物の生
プログラマーとして夢想する作り捨てを許さない組織文化 - 何か着ていればいいよ
自分がソフトウェア開発プロジェクトにプログラマーであったり、プロジェクトリーダーであったり色々な役割を担いながら参加してきて、常に悩まされてきた問題についてちょっと考察してみようと思います。 それは作り捨てと個人的には呼んでいる、小規模な案件に比較的多く見られる事象です。 作り捨てとは何か？ 作ったシステム、PJ等を技術的負債を残して放置すること と、とりあえず定義します。 作り捨てられてしまったシステム…。そこでよく見るアンチパターンを列挙してみます。 ユニットテストなし 仕様書なし 機能仕様書 試験仕様書 その結果どのように動くのが正しいのか分からない その場しのぎの実装 staticおじさんの猛威 神オブジェクト コピペの嵐 などなどの実装のヤバさ 動作環境がない バージョン管理されてない 既存機能にテストがないと正直泣ける。 ユニットテストを作る工数を見積に入れざるを得ないけど、高
KAIZEN platform Inc.に入社しました - fukayatsu.dev
KAIZEN platform Inc.に入社しました 8月末で前職を退職して、9/1の今日が初出社でした。 今日は開発環境のsetupと、小さいpull-requestを2つ出して帰宅しました。 ※ 慣れるまでは会社に行きますが、いずれは主にリモートで開発すると思われます。 なぜKAIZENなのか KAIZEN platform Inc. #hiring OSSのように作る オープンなコミュニケーション リモートワーク 自動化 コードとしてのインフラ 一言で言えば、↑のような組織・文化に非常に共感したからですね。 あとは、Developer Productivityという職種で募集を掛けているのも面白いなーと思いました。 自分はドックフーディングが好きなのもあり、生産性を上げるためにchatbotを作ったり、staging環境の自動生成の仕組みを作ったりしてきたので、本筋のプロダクトを作
リーダブルなコードを保つためには、コードが読まれるような文化をつくらなければならないのではないか | mah365
アプリケーションに不具合が起こっても改修しやすい、仕様も確認しやすいコードであるためには、可読性の高い（＝リーダブルな）コードである必要があります。プロダクトを継続して改善していくためには、コードがリーダブルであるということは必要条件です。 リーダブルなコードである、というのは個人の資質の問題なのか？ ところで、「僕らのコード、リーダブルじゃないよね」と言ったときに、 テクニックの浅いプログラマがいるからリーダブルにならないんだよねー。 リーダブルコードを読んでない奴がいるせいだ！ テクニック以前に意識が低いよね。そういう文化だし、仕方ないよね。 と、自身のチームメンバーに責任を持って行きがちな気がするのですが、本当にそうでしょうか？ 確かにリーダブルなコードを書くためには、ある一定の技術水準、テクニックは必要です。でも、それが全てなんでしょうかね。 読まれないコードの可読性が高くたってし
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
長文日記
自己組織化チームはなぜ必要か？
