タグ

仕事に関するkoudaiiiのブックマーク (11)

  • 伊藤直也が語る「仕事の流儀」第3回──OSSプロジェクトのように組織をつくる|CodeIQ MAGAZINE

    伊藤直也氏が語る「仕事の流儀」の第3回は、暗黙知を作らない組織の作り方。オープンソースのスタイルで組織を作ればいいという直也氏は、KAIZEN platform Inc.において、どのような行動をとっていたのか。 ある取り組みによって、KAIZEN流の行動哲学が生まれたという事例をもとに語っていただいた。 by 馬場美由紀 (CodeIQ中の人) 暗黙知を作るな、すべてを形式知に変えよ 前回は、Sqwiggleを活用したリモートワークGitHubを活用した開発について述べました。 開発プロセスは、まあアジャイル開発っぽいですね。アジャイル開発というか、スクラムで求められている他のプラクティスについて、KAIZENのリモートワークではどのようにやっているかをもう少し説明すると、まずデイリースタンドアップ、いわゆる朝会です。リモートでやってるので、スタンドアップといいつつ立ってはいないんです

    伊藤直也が語る「仕事の流儀」第3回──OSSプロジェクトのように組織をつくる|CodeIQ MAGAZINE
    koudaiii
    koudaiii 2014/07/16
    「許可を求めず、謝罪せよ」という行動哲学
  • 「プロ」が持っている特徴について

    プロは全方向に優れているわけではなく、限られたリソースを的確な方向に注ぐのがうまいのだという話を軸に、若い人にエールを送る連ツイです。

    「プロ」が持っている特徴について
  • エンジニアでも出来るサービスのアイデアの出し方 - ainameの日記

    以前にも書いたのだけど、今年頭ぐらいからコード書く以外のことが出来るようになりたいと思い始めて、休日とか平日夜にコード書くのやめたり、休みの日に積極的に家の外に出るようにしてみたりしていた。 最初、自分がべるのが好きなのでに関するサービスを考えようと思って、TokyoWallkerとかおとなの週末などの雑誌の情報や、友人らの情報を元にいろいろ外してみたり、会社の近くの上手いパスタ屋さんが出版してるパスタレシピを買って実際に自分で作ってみたり、肉フェスとか唐揚げフェスとかタイフェスなどのイベントに参加してみたりしてみて、それ自体はまぁ楽しかったのだけど、サービスを思いつくまでに至らず。に関して何かやろうと思うのは一旦諦めて違う分野で考えだした。 新しいサービスを考えるために、自分以外に2名(どちらも会社の同期で、1人はエンジニア、もう1人は総合職)とチームを組んで一緒に案出しを

    エンジニアでも出来るサービスのアイデアの出し方 - ainameの日記
  • 運用エンジニアから開発エンジニアになるためにやったこと · As a Futurist...

    Web の会社でエンジニアを始めて 4 年、ずっと運用エンジニアをやってました。運用とは端的に言うと、社内外の他人が作ったソフトウェアを期待通りに動作させるためのエンジニアリングだと思ってます。アプリケーションはもちろん開発者が作ったものですし、MySQL や Apache や Linux も全部他人が作り上げたソフトウェアであり、それらの設定を変更したりパッチを当てたり運用ツールを駆使することで、協調動作させることに磨きをかけてきました。 ただ、いつまでたっても他人の作ったものの面倒を見てることには変わりないし、運用ツールを開発したところでそれはあくまで誰かが生み出す価値のサポートにすぎないのが自分的には満足できなくて、ずっとアプリケーション(ビジネスロジック)が作りたいと思ってました。 で、今年の始めからたまたまタイミングよく新規開発の部署に入ることになって、いきなり開発者をやることに

    運用エンジニアから開発エンジニアになるためにやったこと · As a Futurist...
  • 客の質によってサービスを変えるのは妥当かどうかについて|More Access! More Fun

    Twitterのタイムラインに面白い画像が流れてきたのでFacebookとGoogle+に「Twitterで面白いの見つけた」と投稿したらめちゃバズった。 反応は大きく分けて◎が90%、×が10%という感じ。極端に分かれた。 ◎ 面白いシェフ 正直で良い このお店行きたい 自分も場所だけ取ってくっちゃべってるだけのグループには腹立つ 当たり前だけど誰も言わないだけ。よく言った。 × こんな店絶対行くものか 客をなめてる 営業努力を欠いてる 客に対しての態度が嫌だ 自分はどうかと思うと、これこそ究極のワントゥワンマーケティング(死語)だと思ったなりよ。 何回も書いているが、売り上げの90%は10%の顧客が占めているというアレだ。デパートも最上の客には家まで外商の担当者が出向いて注文を受ける。サービスの内容が一般客と全く違うわけ。たくさんお金を払う客には上質のサービスを提供し、その客が逃げてい

    客の質によってサービスを変えるのは妥当かどうかについて|More Access! More Fun
  • 恋人を"かわいい"と紹介できる人になりたいと思った - horahareta

    こんばんは、吉ユータヌキです。 最近ふと思ったことがあるのですが、 "恋人の良い所を人前で言える人っていいな"と。 僕はプライドが高いくせに恥ずかしがりなので 『彼女どんな子なの?』って聞かれたら 『変な子ですー!たいしたことないですよー!』と彼女を巻き込んで卑下していました。謙遜とは違うんですよね。 男同志の会話なら必ず出てくる 『顔はかわいいの?』という質問には 『かわいくないです!』って言ってました。 今になって当にヒドいこと言ってるなーと思ってね。 その卑下は誰の為だったのかと。別にノロけたって良かったのにね。 もちろん実際に会ったときのハードルが上がっちゃうってのもあるけど、誰にどう思われ様が恋人をかわいいと言える人になりたいと思った。 紹介してもらったら『深海魚!?』みたいな子が出てきたこともあったけど、友達が幸せそうに紹介してくれるから、それはそれで良く思えた。 かわいい

    恋人を"かわいい"と紹介できる人になりたいと思った - horahareta
  • テストコードを書く文化を根付かせたい─和田卓人|【Tech総研】

    におけるテスト駆動開発(TDD)のスペシャリストとして知られる和田卓人氏。講演活動やハンズオンイベントを通してテストの重要性を語り続けている。その深奥にあるプログラムの哲学とは── 父親がデータベース設計を得意にするソフトウェア・エンジニアで、受託開発の会社を経営していました。私は大学在学中からその仕事を手伝っていて、その延長で大学を出るとその会社の一員になりました。 そのころのことで一番印象に残っているのは、電子政府関連の公共システム開発に関わる大規模プロジェクトへの参加です。複数のSIerやソフトハウスが関わり、要件定義に時間をかけ、膨大な設計文書をつくっては、何千人というエンジニアを投入する、典型的な大規模システム開発です。私はそこにSEの一員として参加することになりました。 ただ、私は初日から生意気にも「Excel設計書を書き続けるために来たのではありません」と嘆願して、基盤

  • 社内勉強会の作り方(1)期待してはいけない10のこと - Satoryu's Diary(OpenShift支店)(2014-04-03)

    _ 社内勉強会の作り方(1)期待してはいけない10のこと 予め申して起きますと、タイトルは釣りです。ようこそいらっしゃいました。 今日、某社*1の方々が社内での技術コミュニティや勉強会を立ちあげたい、という思いから、弊社での社内勉強会の事例を聞かれたので、少し話をしてきました。 遡ること2011年9月に、色々な思いを込めて、弊社の社内勉強会としてRakuten Tech Talkを立ちあげました。初めはせいぜい20〜30人の参加者で、色々な人に声をかけて、あーでもないこーでもないと、色々悩んだり考えたりしながら続け、ここ数回の開催では100人規模の参加者が集まることもある会になりました。現在、自分含めて3人で、直接の業務と関係なく、ボランティアとして運営しています。 この規模に至るまでに、何をしたのか、というのを聞かれることもあるのですが、正直に言うと、地味なことしかしていません。会場とな

  • コードの綺麗さの先にあるもの - Fashionable Life

    2012-11-30 コードの綺麗さの先にあるもの 久々の更新になりますね。せっかくなのではてなブログに移りました。 昨日弊社代表の 「コードが汚くてもいい」っていう社長のインタビュー記事に対して 「コードが汚いのは悪だろ」って脊髄反射してるブクマコメントとかツイートが たくさんあるのでCTOとしての自分なりの意見を書いてみようと思う。 実際の現場 最初に記事を目にしたプログラマー達はまぁ「コードは汚くてもいい」にしか目にいかないだろう。そんな会社で働きたくないって思うかもしれない。この会社には汚いコードが溢れてるんだろうなと。 脊髄反射的にブコメしたり、ツイートされているものは全て拝見させていただいた。 では実際の現場はどうなのか。 盛大に勘違いされてそうだが、そもそもの大前提としてうちのコードは別に汚くない。 綺麗、汚いとかの定義は人それぞれだが、仮にその評価軸をリーダブルコード(可読

  • HRTの原則 〜ソフトウェア開発はバーでしっとり語り合うように 〜 : 小野和俊のブログ

    「HRTの原則」という言葉をご存知だろうか。 これは書籍 Team Geek ―Googleのギークたちはいかにしてチームを作るのか で紹介されている言葉であり、書ではほぼ一冊すべてをかけてこのHRTの原則とその実践方法とを様々な角度から紹介している。 1. 謙虚(Humility) 2. 尊敬(Respect) 3. 信頼(Trust) の3つの価値が大切にされており、エンジニアとしてもチームや組織、顧客との対話においてこれらの価値を重んじていくことが成功につながる、というものである。 あらゆる人間関係の衝突は、謙虚・尊敬・信頼の欠如によるものだ Team Geek p.15 プログラマとして成功するには、最新の言語を覚えたり高速なコードを書いたりするだけではいけない。プログラマは常にチームで仕事をする。君が思っている以上に、チームは個人の生産性や幸福に直接影響するのである。 Team

    HRTの原則 〜ソフトウェア開発はバーでしっとり語り合うように 〜 : 小野和俊のブログ
  • いいアドバイスをもらうための相談の仕方 - 2012-12-05 - ククログ

    物事の進め方や問題の解決の仕方などを決めるとき、他の人に相談します。しかし、いざ相談してみると、うまく相談できずに、もどかしい思いをしたり、相談の時間がいたずらに長くなって相談相手に迷惑をかけてしまったりすることがあります。うまく相談できていないときは、自分の状態をうまく伝えられず、相談相手を困らせたり、役に立たないアドバイスをもらったりします。 相談する目的はいいアドバイスをもらうことです。「いいアドバイス」とは、「自分の状態を良くするのに役立つアドバイス」です。いいアドバイスをもらうと、相談した自分の状態をいい方向にもっていくことができるからです。いいアドバイスをもらうためには、相談の仕方に気をつける必要があります。今回は、他の人に相談していいアドバイスをもらうための相談の仕方について説明します。 いいアドバイスをもらうためには伝える情報に気をつける いいアドバイスをもらうためには、相

    いいアドバイスをもらうための相談の仕方 - 2012-12-05 - ククログ
  • 1