弊社のＦＡＸが混み合っておりまして－社会と茶道の話 - 発達障害就労日誌
ＦＡＸの送信を忘れていました 今日は疲れたのでタラっとした話です。 借金玉さん、今日もお仕事だったんですよ。そりゃもうモリモリと働いていたわけです。それでですね、他社さんから「アレのデータＦＡＸで流してくれや」と言われてですね、「わかり、ダイレクトで流すんでよろ」みたいに返したんですけど、まぁやっぱり残念な人なので綺麗さっぱり忘れて仕事してまして。その後 「すいません、株式会社～の～ですが、借金玉さんご在席ですか？」 という電話が鳴ったわけです。この時点でピキーンですよ。完璧に忘れとった。2時間放置しとった。そんな切迫した案件ってわけでもないので激おこというわけではないだろうけど、やっぱりお願いされてたことを放置してたわけで。「申し訳ございません」の「も」まで口に出たわけですよ。 「大変申し訳ございません。弊社のＦＡＸが大変混み合っておりまして、現在まだデータが受信出来ておりません。お手数
マネジメントの秘伝のタレ - Flicker's Style++
今回は私が今までチームマネジメントやヒューマンマネジメントを通して学んだTIPSを整理してみたいと思います。 マネジメント(≒コミュニケーション)を支える技術について都度メモして、自分への戒めとして利用していたものを箇条書きにまとめました。 ある特定の状況だけでしか適用できないものが多いですが、応用はいろいろ効くと思っています。 マネジメントの立場にこれからチャレンジしていきたい人の一助になればと思ってます。 ※自分向けのメモを整理しただけなので、一般的にこうあるべきという内容ではありません。 会議編 -全員の参加を促そう 全員の発言機会が均等になっているか常に意識しよう 一言でも意見を言うことによって、その議題を決めたという意識を持てる - 自分自身(チーム自身)で決めたという感覚に落としもう 「決められたこと」ではなく、「自分たちで決めたこと」という意識を促そう その決定が実行されなか
SlackをSIerに導入した話。そしてSIerの未来 : 小野和俊のブログ
「Slackを入れるとSIerはどうなるのか？」 しばらくブログを休んでいたので少しだけ自己紹介をしよう。アプレッソというベンチャー企業を立ち上げて、セゾン情報システムズという会社にexitした。そしていまはアプレッソの社長として仕事をする傍ら、セゾン情報システムズのCTOの仕事もしている。どちらかというといまはセゾン情報の仕事の比重が高いから、リアルの世界では「セゾン情報の小野」と思っている人の方が増えてきていると思う。 「このままでは、SIに未来はない。だから変わらなければならない。」 「当社の社員は言われたことしかできない。」 SIerの経営者と会話していると、よくこんな言葉を耳にする。 自分たちの未来を悲観している人たちが、未来を明るくできるのだろうか？ だから私は、喜びと驚きのポジティブスパイラルで、SIerはどんな風に良くなるのか、壮大な実験をしてみようと思った。 その第一弾と
インド出張から得た英会話の学び - ミームの死骸を待ちながら
三週間ほど海外に出張していた．インドである．趣旨としては，僕が持ついくつかの領域における専門知識と経験をあちらのエンジニアに展開する，先生役として呼ばれた形..になるだろうか．単にセミナーとかを聞くだけの出張なら今夏にも行ったところだが，三週間みっちり先生をやるとなるとプレッシャーが違うし，事前にインドのチームと喋ったところ僕に対する期待値が異様に高く，胃の痛い思いをしながら突入することになった． 午前は講義を行い，午後は行列のできる Hash 相談所，夜はホテルに戻って翌日のトレーニング資料を作る... というすたーたっぷ勤務時代を彷彿とさせる社畜業に勤しみ観光どころではなかった (たまたま向こうで働いていた友達に会ったのと，インドチームとビール飲みに繰り出したりはした) ので，費やした時間分は役に立ったことを願う．黒い髭をたくわえた厳ついエンジニアも鋭い眼光の優秀な若者もみんな良い人で
Sqwiggle が良いという話、またはリモートでアジャイル開発をどう進めるか - naoyaのはてなダイアリー
KAIZEN platform Inc. は、新しい働き方をいろいろ試してみようという会社でそのひとつにリモートワークがある。リモートワークの良さあるいは良くないところについては、以前に Rebuild.fm の ep.32 でも話した。 ちかごろは、オンラインミーティングのための道具、情報共有のための道具もクラウドサービスがたくさんあるので、その辺を使って工夫すれば一昔前に比べてだいぶリモートワークも現実的になってきている。実際、KAIZEN には大阪からリモートワークしている人とか、最近リモートワークを前提に都内から鎌倉に引っ越したメンバーなんかもいる。 リモートワークとアジャイル開発 HipChat、Google Hangout や Qiita Team なんかを使うことで、日常の会話、ミーティングや情報共有についてはもともと特に困ったこともあまりなかった。特に Qiita Team
ソフトウェア開発の生産性を阻害する「気軽に聞けない」ことの考察と対策 - メソッド屋のブログ
マイクロソフトの DevOps テクニカルエバンジェリストになる前から、ずっと不思議だったことがあります。 それは、「アメリカのエンジニアの生産性の高さ」です。素晴らしいサービスは大抵彼らから生まれていますし、彼らを見ているとアウトカムも生産性も非常に高く感じます。 私は個人的にこの秘密を解く旅の途中にいます。私はインターナショナルチームに所属しているのですが、同僚と一緒に働いたり、ハッカソンをしたりして気づいた１つの仮説について共有したいと思います。 気軽に「聞けないこと」が生産性を阻害しているのでは？ 以前私は「米国のエンジニアはコンピュータサイエンスを専攻している人が多くすごく優秀で、さらに英語が出来るので、技術収集するのも楽だから相当アドバンテージがある」と思っていました。 英語に関してはそうだと思いますが、彼らの個々の人がそんなに優秀かというとそうでもないことに気づきました。それ
IT勉強会で懇親会をするとき気をつけること - とあるインフラエンジニアの日常
これまで、江戸前セキュリティ勉強会やまっちゃ445勉強会を中心に、IT勉強会で懇親会の担当をする機会に多く恵まれてきました。 その中で、懇親会を企画する際に、気をつけたほうがいいと思ったこと、これまでうまくできなかったことを、 参画から5年（もうすぐ6年）の節目で、一度まとめておきたいと思います。 色々と教えて頂いたid:ripjyr id:vulcainに多謝！ 予約者数 勉強会参加者の6割が入る箱を探す (9/23追記)上記人数は規模に応じて想定割合は変更する。上記の数字は勉強会出席者が100人の場合の想定 (9/23追記)下記は一例（勉強会参加者が多いほど人数が読みづらいけど、多いほど懇親会出席率は低くなる傾向があると思う） 勉強会参加者＜ 70人 → 0.7-0.8 勉強会参加者＞ 100人 → 0.55くらい(少し少なめ） 当日になってキャンセルが出るのは日常。経験則では5-10
エンジニアの「できない」という言葉の裏側 - Konifar's WIP
「ここ、こんな感じにできませんかね？」と言われたエンジニアが、「うーん、それはちょっと厳しいですね。できないです」と返すみたいなやりとりは結構見かけます。 この「できますか？」⇒「できない」というやりとりなんですが、「できない」という言葉にはいくつか裏が考えられます。言葉足らずだっただけでちょっとした調整をすればできるよね、というケースもあるので、「できない」という言葉の裏側をまとめておこうと思います。 先に補足しておくと、「エンジニアの人の言葉が足りなすぎるでしょ」という意見ももちろんあると思います。こういうコミュニケーションは、お互いの信頼度によっても変わってくるので難しいところです。お互いが相手に伝わるように意識すべきだと思うんですが、 エンジニアから「できない」と言われた時にどういう意味で言ってるのか想像しやすくなればいいなという思いで書いておきます。 ちなみに、「（できるけどやり
ソーシャルで、特定の人への批判をそれとなく書くのはやめておいたほうがいい : けんすう日記
よくソーシャルで見るんですが、それとなく当人にもわかるように批判を書く人っていますよね。 たとえば、自分のFacebook上にいる知り合いが、遅刻したときに、そのときには言わないで 約束の時間を守らないというにはビジネス上ではしてはいけないと思う。簡単に人の信頼を失うからだ。 みたいにFacebookに書くような人です。 で、これってやっぱりあまりよくないと思うんですよね。 ここでのポイントは、その人がいないところでの陰口だったり、単に感情を吐き出したいための愚痴だったりするわけではなく、「当人に伝えたいけど、直接いうのは嫌だから、誰のことをいっているかどうかわからないように言う」という点です。 まず、シンプルに直接いえばいい注意を、公の場で、その人だけわかるように言うっていうのは、卑怯かなあ、と思うわけです。自分のリスクを減らしつつ、相手に伝えようとするのは、なんかカッコ悪いなあ、と。関
YesとNoのゲーム － コミュニケーションを教えるということ | タイム・コンサルタントの日誌から
最初に、『Yes/No』ゲームについて説明しよう。Q&A（質疑応答）ゲーム、ともいう。４、５人ずつのグループでやるゲームだ。大人でも、子供でも、むろん学生でもできる。 ルールはとても簡単である。出題者は、何か具体的で、目に見えて手で触れる、形のあるもの（人でもいい）の名前を紙に書いて、隠しておく。回答者はグループに分かれて、順番に、出題者に対して１つずつ質問をしていく。このとき、質問についてのルールが２つある。一つ目は、質問は必ず、相手が「Yes」か「No」か、または「どちらでもありうる」の三種類のどれかで答えられるような質問であること。二つ目のルールは、誰かが既にした質問を繰り返してはいけないこと。基本はこれだけだ。 たとえば、出題者が「ビーチボール」という答えを用意していたとしよう。質問する側の最初のグループが、 「それは食べられるものですか？」とたずねる。答えは「No」だ。 二番目の
マネージャとのつきあいかた - サンフランシスコではたらくソフトウェアエンジニア - higepon blog
今の会社で 7 人のマネージャと仕事させてもらい、自分もマネージャになったこともある。その経験をふまえてマネージャとのつきあいかたを書いてみる。マネージャは日本的な「上司」と若干ニュアンスが違うので注意。上司というよりは役割の異なる同僚。 目的 マネージャとうまくつきあうことで以下を得るのが目的。 困ったときに助けてもらえる。マネージャ自身のマネージャのちから、マネージャの人脈を借りる プロジェクトの進め方、デザイン等。基本的に好きにやりたい。細かく口を出されない。 キャリアプランゴールを共有し助けてもらう 大きな 2 つの方針 初期の段階で信頼関係を築き、以降のつきあいを楽にする バランスのよい情報共有を目指すが over-communication よりにたおす マネージャの視点 マネージャの視点を意識すると何を伝えるべきかが見えてくる。マネージャがあなたについて知りたいのは プロジェ
朝会のこと - @m_seki の
朝会は毎朝やるミーティングです。一般的には、立ってやるとか、こんな話するとか、スタイルの説明がありますが、それでは私たちの朝会の実態を表している感じがしないんですよね。今日はスタイルだけではわからない、私たちの朝会の実態を説明したいと思います。ちなみに私たちのチームの規模感は 十数年 x 小学校1クラスより少ないくらいのイメージです。チケット数は数万くらい。 朝会の流れ 私たちの朝会では、現在のイテレーションに配置されたチケットを全部さらいます。メンバーが順に話すのではなく、チケットをひとつずつ見ていきます。（その結果、ほとんどのメンバーにパスが回ります。） メンバーの負荷の方に興味があるチームの場合はなにかしら変化の起きる可能性の高い「メンバーが手をつけているチケット」について聞いて回る方が効率もいいかもしれませんね。 私たちは、各メンバーが昨日やったこと／今日やること、ではなく、チーム
TRiCK FiSH blog. - 人気ブロガーになるためには
面白いブログを書いてちょう人気ブロガーになりたいのに、最近スランプで面白いエントリがビタイチ書けません。どうしたら面白いエントリを毎日バンバン書けてちょう人気ブロガーになれますか？他人のブログを読むとか面白いネタが浮かぶまで待つといったブログ論以外で、具体的なソリューションをお願いします。http://q.hatena.ne.jp/1144077840 この質問はネタか釣りかという気もしつつ（一部表現がテラヤマアニさん的だとかも思いつつ）、けっこうそう思っているひとは多いのかもな、と思う。というのも、先日yakalikeでチャットしたときに（id:TRiCKFiSH:20060120:p1）、あるひとが「ブログって人気が出ないと続ける気力がわきませんよ」みたいなことを言っていて、そうなのかぁと思った。 僕なんかはこのブログを始める前は、さるさる日記でコソコソ書いてたんだけど、それは目立ちた
エンジニアを一人にさせない - futoase
エンジニアを一人にしない これは、決して一人プロダクトが悪ということじゃない。 孤独、孤立させることが問題ということ。 エンジニアを一人にさせないために 一人になってるエンジニアの周りができること 飯に誘う チャットルームで飯でいくらか話していた話題から、興味ありそうな部屋に招待する gitの使い方や、Windows 10の話とか、プロダクト外の話であれば共有しても問題ないのでそういうことをガンガン話す 飲み会については、たまにプライベートで安い飲み屋でもいいから誘う。お酒飲めない場合はランチ！ もしエンジニアが体を動かすことに興味があるのであれば、フットサルなど、プロダクトではないけど協調作業を通じて成果がでるようなことをさせる。協力系のボドゲ(パンデミックとか)でも良いかもしれない 一人になってるエンジニア、あなた自身ができること エンジニアのエリアに顔を出して、挨拶する。これだけでも
メールに返信をしないアメリカ人のメンタリティ - Thoughts and Notes from CA
「メールでアメリカ人に問い合わせをしているが返信がこない」、というのは外資系企業に勤めていればよくある話。その内容が難しければ難しい程、返信率は悪くなる。もちろん、日本人でもレスの遅い人、しない人はいるが、度合いの問題。アメリカ人の場合はかなり気合をいれて、しつこくプッシュしないと返事がもらえないことが多い。 一番良いのは電話をすることで、電話をしてみると「おぉ、あの件ね、見た見た」みたいな感じで話が進むことが多い。メールで聞いていることを一々電話しないといけないのはかったるいし、時差や言語の問題があって容易ではないし、そもそも「お前、見てるんなら返信くれよ」という思いもある。 でも、そういうことで頭を痛めている人は、理解しておいたほうが良い彼らのメンタリティがある。それは「何度もプッシュされないということはきっと大事なことではないんだ」という考え方だ。メールを出して返信がしばらくこないも
エンジニアに必要な説明能力 - Konifar's WIP
最近、本業のTaptripで新機能の開発やコードレビューの数が多くなってきた中、 やはりエンジニアに必要なのは説明能力だなぁと感じることが多々あります。 これは受託の場合は全然違うよと言われるかもしれないし、裁量のある環境だけの話なのかもしれないですが、あくまで自分の感じたこととして考えをまとめておこうと思います。 エンジニアは説明することが多い 開発職じゃないとピンと来ないかもしれないですが、何かを説明することって意外と多いです。 例えばバグ修正をする時に、一番理想的な修正をするとテストも含め2日かかるけど、暫定修正なら半日で終わるみたいな場合。 「ユーザーへの影響が大きいので暫定修正で直して、次のリリースで回収できるように調整します」みたいな説明をしたりします。 もっとコードレベルの話で言うと、例えばこんなやりとりをしたりします。 ほとんど伏せているのでわかりにくいかもしれませんが、
雑な発想を活かすチーム作り - クックパッド開発者ブログ
インフラストラクチャー部の成田（@mirakui）です。インフラストラクチャー部は、クックパッドで扱っている全サービスのサーバを設計・構築し、運用しているチームです。2015年3月現在、6人のメンバーで運用をしています。 さて、この運用というのは外から見ていると保守的な仕事に思えるかもしれませんが、その実、とてもクリエイティブな仕事です。クックパッドのサービスは一日平均で10回以上デプロイされており、アクセスも日々増え続け、状況は刻一刻と変化しています。今日動いているサーバ構成が、一年後に通用するとは限らないわけです。そんな変化に追従するためには、サーバを常に改善していかなければなりませんし、チームにも柔軟な発想が求められます。 「さあブレストしよう」→アイデア出ない問題 さあ業務を改善しよう、と意気込んでブレインストーミングを開いても、なかなか十分なアイデアが出きらないのはよくある話です
「真面目」が一番コスパが良い - インターネットの備忘録
交渉とか駆け引きとか、あるじゃないですか。やるの好きな人も多いし、やれるようになりたがる人もけっこう多い。ナントカの交渉術みたいなの。 わたしもセールスやってたとき「無理な交渉を仕掛けられたら、電話をわざと長めに保留することで社内検討している感を演出する」みたいないま思うとよくわかんないノウハウを教わったりしたんですけど、その後そういうスタイルからは手を引いたとはいえ、いろんな人と仕事してると「よくもまあそんな条件出せますね」みたいな、ワ～信じられない！恥知らずってこれかー！みたいな交渉をしてくる人に当たります。 で、まだ20代の新人さん相手とかなら分かんないですけど、こちとらもう十何年も仕事してるわけで、海千山千なわけですよ、だいたいの会社の利益構造とか社外から取得できる情報レベルでもおおよそは判断できるんだから、要件に関して実現可能ラインと不可能ラインだって大きくはずさないレベルでイメ
コードレビュー - hitode909の日記
コードレビュー，慣れるとできるけど，いきなりdiffを渡されて，どうぞ見てくださいと言われてもよくわからないと思う． やりましょうというのはいいけど，ただむやみに読んでもうまくいかない．変更がある程度大きくなるとdiffだけ見てもよくわからないので，いろいろ見ることになる． 僕はいつも以下のようなことを無意識にやってて，うまくいってる気がしてる．GitHubのPull Requestの仕組みを使ってる前提で． Discussionをさらっと眺めてどういう問題を解決したいのか見る Commit Statusを見て，テスト通ってることを確認する Commitsタブで1コミットずつブラウザの新しいタブに開く 全部クリックし終わったら古い順に1コミットずつ読む 気になる点があったらエディタとかにメモしておく．あとで書き直されるかもしれないので，まだコメントしない 全コミット見終わったらFiles
人にたくさん好かれたいなら、人をたくさん好きになったほうがいい - シロクマの屑籠
人を好きになる、技術。 - 犬だって言いたいことがあるのだ。 「人を好きになる技術。」 “技術”という言葉をあてがって良いのかわからないけど、大切なことが書いているように思った。 幸福を追いかけるにあたって、他人に認められたがる・好かれたがること自体は間違っていない。承認欲求を充たして幸福感を感じ取れる主体は、どこまでいっても自分だけだからだ。けれども、その発想だけで幸福になれるかといったら……なかなかそうもいかない。 「他人から承認されたいと思う者は、どこかで他人を承認できていなければならない。」 承認欲求には「承認は天下のまわりもの」みたいなところがある。多く与える者には承認が集まりやすいが、ちっとも与えない者には承認がなかなか集まらない。ためしに、身の周りにいる承認上手な人達――周囲からよく認められ、承認欲求に飢えていなさそうな顔をしている彼／彼女のことだ――を思い出してみて欲しい。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
