【サイボウズ式編集部より】「ブロガーズ・コラム」は、著名ブロガーをサイボウズ外部から招いて、チームワークに関するコラムを執筆いただいています。今回は「My Favorite, Addict and Rhetoric Lovers Only」のファーレンハイトさんが考える「チームで相談される人、相談されない人の違い」についてです。 "仕事ができる人"には2種類のタイプがいる。相談をされる人間と、相談をされない人間だ。 逆に言えば、きちんと相談ができる人、できない人という観点もあるが、今回は相談を受ける側について書いてみたいと思う。 まわりに人が集まる"できる人間"、集まらない"できない人間" 仕事ができると思われている人は何かと相談を受けている。「知っていますか?」という知識レベルの話であったり、キーパーソンとの仲介を頼まれたり、「どうすればいいのか?」という現状打破へのアドバイスであったり
就職王が贈る、新入社員が覚えておくべき10の事柄 たいていの人は、仕事でさしたる成果を上げられない。本気で頑張ってないから、というのは気慰めで、実際には一生懸命に頑張っても特別に素晴らしい結果は得られない。そのあたりは学校のお勉強と同じ。 じゃあ学校はつまらない場所だったか。楽しかったのは休み時間と放課後だけか。そうでもない、と思うんだよね。いや、そうだった、という人もずいぶん多いだろうとは思うけど。たぶん会社もそうで、さしたる成果を上げられなくても、コツを押さえれば、それなりに生き抜いていけるようになっているのだと思う。 リンク先の記事の中の「たしかにそうだ」と思う部分と、いろいろな人から親切に教えてもらったことなどを交えて、自戒を込めて私なりに整理しておきたい。 結果が伴わないとき、過程が重要になる。「まじめに頑張っているけど結果は並以下(といっても最低ランクではない)」という人は、よ
ネタ元: 「エンジニアをつくる」という理念掲げていたら、エンジニアが社内からいなくなった件 | 新田章太の「エンジニアをつくる」ブログ 話の発端は、 俺がDMTCについて知ってること,またそれに対する所感 - 職質アンチパターン がFacebookで話題になっていて、やばいなぁと思っていたら主催者もやばかったみたいな話。 内容自体ただヤバイんだけど、その中でも明確にツッコミを入れておきたい部分があった。 僕らの強みはDMTCを通じて、沢山のお客様とのつながりがあること このつながりを活かして、 国内外のIT企業で働くエンジニアのスキルを定量化しよう というひとつのテーマにいきつきました。 http://maximum80.me/archives/821 この部分についてFacebookで俺はエンジニアをバカにしてるって書いたけど、もうちょっと具体的に落としこもうと思った次第です。 ものさし
HeartRails Tech Blog ハートレイルズのエンジニア、デザイナーによるブログです。 ウェブサービス、スマホアプリ、IoT デバイスの開発に関連する技術的な情報を発信していきます。 ハートレイルズは 2006 年の創業以来、徹底してリモートワークに拘っています。 ハートレイルズはパートナーを含めてまだ 15 名程度の小さな組織ですが、この規模でも原則全員が異なる場所で働いている組織は、日本ではかなり珍しいのではないでしょうか。 ハートレイルズには海外を転々としながら働いている人や関東近郊以外の地方から働いている人、マジシャンを副業にしながらエンジニアとして働いている人など、様々な場所から、様々な関わり方で働いている人がいます。性格も体育会系な人や草食系な人、リア充な人から非コミュな人、オタクな人まで様々です。ハートレイルズはエンジニアやデザイナーを主体としている企業ですから、
KAIZEN platform Inc. は、新しい働き方をいろいろ試してみようという会社でそのひとつにリモートワークがある。リモートワークの良さあるいは良くないところについては、以前に Rebuild.fm の ep.32 でも話した。 ちかごろは、オンラインミーティングのための道具、情報共有のための道具もクラウドサービスがたくさんあるので、その辺を使って工夫すれば一昔前に比べてだいぶリモートワークも現実的になってきている。実際、KAIZEN には大阪からリモートワークしている人とか、最近リモートワークを前提に都内から鎌倉に引っ越したメンバーなんかもいる。 リモートワークとアジャイル開発 HipChat、Google Hangout や Qiita Team なんかを使うことで、日常の会話、ミーティングや情報共有についてはもともと特に困ったこともあまりなかった。特に Qiita Team
俺日記のしんじです。一人称は僕です。 コマンドラインが苦手なGit初心者でも比較的容易にバージョン管理ができる、GitのローカルクライアントSourceTreeの使い方を説明する。 前回の: 個人開発編に続き、今回はチームで利用する場合。 Gitの仕組みを直感的に理解することができるので、誰かに指導する場合などに導入を検討してみてもいいと思う。 ■前提 ・Mac版を利用 ・testProject1というプロジェクトを用意 ・リモートリポジトリ管理にGitLabを利用 ■目次 メンバー間で共通のブランチモデルを構築、git-flowの導入 リモートリポジトリの情報を取得する。 たまにはコマンドラインで利用したい。 ■内容 メンバー間で共通のブランチモデルを構築、git-flowの導入。 git-flowとは…Vincent Driessen氏によるgitのブランチモデル。チームで開発するとき
CTO募集とかフルスタックエンジニア募集とか都合の良いこと言っちゃだめ - UNIX的なアレ 先日のCTOエントリが結構反響あったので続きを書いてみます。いろいろな方のリアクションみていると、CTOとか役員とかそのあたりをもう少し理解してもらいたいなと思ったのが理由です。 役員って何? これ結構勘違いされていますが、会社法における役員というのは取締役のことです。そのため、CTOだから会社法上の役員というわけではありません。 またそれと同様に、執行役員も会社法上の役員ではありません。取締役と執行役員を兼任しているケースは多いですが、これは社内におけるそれぞれの役割を分けているためです。 それでは取締役の役目は? まず、重要なのは以下の点です。 取締役は単独で職務執行権限を持たず、取締役会の一員に過ぎなくなった 取締役 - Wikipedia 取締役という立場自体はそれだけで職務上の何らかの権
酔っ払いながら書くけど 1人脳内出血で植物人間状態、奥さん逃げて要介護のそいつの両親どーしたんだろ。。。 1人心筋梗塞、1人クモ膜下出血(子供生まれたばかりなのに) 5人鬱でまともな生活送れていない 1人自殺失敗で車椅子生活、2人自殺成功で病院からあの世 この全てが始業時間~終電帰宅生活、デスマやらの経験者 SEだけじゃなく仕事のストレス溜めまくってる人間ほど病気になってる 月600時間残業で自殺したアニメーターの話題があったり残業代なくそう法案出てたり 経団連の代表 労政審で暴言“過労死原因は加齢や生活習慣” http://www.jcp.or.jp/akahata/aik14/2014-04-23/2014042301_02_1.html こんな奴らいるけど若いやつは早めに逃げろよ、40過ぎるといきなり体にがたが来るぞ 誰かが何とかしてくれるとか考えても駄目だぞ、日本人は誰も労働環境改
http://ejohn.org/blog/write-code-every-day/ 1 comment | 0 points | by doublemarket ■ comment by Jshiike | 約1時間前 URL投稿ありがとうございます。 Khan AcademyのJohn Resigが、プライベートの時間でサイドプロジェクトを進めるにあたって、毎日継続してコードを書くことの効用を紹介しています。 従来は、週末の一定時間 + たまに平日にコードを書いていたのが、作業を思い出してキャッチアップする非効率があるので、180日で180サイトをつくったJennifer Dewalt(すごいな。)に感化され、20週間、毎日コードを書いてみたという話。 彼のGitHubレポジトリの更新状況はこちら。 「継続は力なり。」というのは金言で、自分も新しい & 大事なものを覚えるときは、極
自分がプログラマから起業して沢山失敗したので、同じミスをプログラマ、エンジニアの方にして欲しくないという想いから、よくある失敗をまとめました。(常に追加中) プログラマでなくても、フリーランスや起業する方に役立つでしょう。 特に技術分野の経験だけしかない人は、気をつけましょう。 技術以外の大量の会社関連の知識、実行能力、実行する時間、経験が必要になります。 従業員との最も大きな違いはリスクかと思います。 従業員は金銭的なマイナスリスクは非常に少ないですが、フリーランスや取締役は数百万円以上のリスク負うことが非常に多いので、リスクヘッジをするための知識と経験が(嫌でも)多く必要になります。 技術も持っているのでプロダクトを作りたい方も多いと思いますが、会社の場合プロダクトを作るだけではなく、市場で勝てるプロダクトを作る会社組織も同時に作らなくてはなりません。どのような人材をどの順番でどのよう
2014-04-04 年収が100万上がるが条件がなかなかハードな件 日常劇場 新年度ですが皆様いかがお過ごしでしょうか?新年度早々、会社から年収100万上げてやると言われた。ありがたい話だ。このことは嫁には内緒にしてこっそりカメラとか買おう。そう思った。しかし、条件がやはり100万となるとなかなかハードだった。正確には一日3000円手当つけるから以下の事をしろと言われた。 24時間365日電話に出て対応。出社する必要があるトラブル時は出社。1時間以内にトラブル時は駆けつける。今までは泊まりの保守がいたが人件費削減と退職による人材不足が原因でそうなった。新しい人材がくる予定はない。とりあえず、受けないと会社も自分も多分潰れる。まさに壊れかけのジェンガしかし、ジェンガは上に積み重ねてバランスをとることが出来るが新人が来ないウチは上に積み重ねてバランスをとることができない。出来ることは祈ること
ゼネラリストを目指すのか、スペシャリストを目指すのか。 もちろん、組織の中でより大きな権限を持つのはゼネラリストだ。しかし、組織の全員がゼネラリストを目指しても、椅子は限られている。だから、僕らの時代には、よくこんな風に言われていた。 「これからはスペシャリストの時代だ。それぞれスペシャリストを目指して専門性を磨くような会社にしよう。そして、一級のスペシャリストには、一級のゼネラリストと同等の待遇を与えよう」 しかし、どうもその言説が実現したとは言いがたい。 世の中の進歩の速度が早く、ある分野のスペシャリストになっても、様々な分野で、その専門能力が長期にわたって価値を生む保証がなくなってきた。 そして、もともと優れたマネージメント、確立した大組織のなかでのマネージメント・ノウハウは、ゼネラリスト的な視野と思考能力の独壇場であって、やはり、原理的にスペシャリストはゼネラリストにはかなわなかっ
私たちソニックガーデンでは、リモートワーク(在宅勤務)が出来る働きかたを実現しています。むしろ、これからはリモートワークを推奨しようと考えて、経営施策を進めているところです。先日は、ソニックガーデンでリモートワークをしているメンバーへのインタビューも行いました。 お昼寝もアリ!?成果がすべての楽しくシビアなリモートワーク さて、私の書くこの記事では、私たちソニックガーデンの働きかたを参考に、会社やチームにおいてリモートワークを導入していくためのポイントや課題について、実践を通じた経営からの視点もあわせて書いてみました。 いつ働いても、どこで働いてもよい働きかた 私たちの会社ではソフトウェア開発を仕事にしていますが、ソフトウェア開発とは非常にクリエイティブな仕事です。決められたものを、ただ黙々と手を動かせば出来るような仕事ではありません。特に、私たちはソフトウェアの企画をするところから、プロ
ドワンゴ現在、ドワンゴでは「女子マネ弁当」という企画が復活している。 過去の女子マネ弁当の様子については、すでに社外にも相当の情報が出回っているので、例えば以下のような情報を参考にしてもらいたい。 【第1回】ドワンゴ大改革の鍵は、インフラと女子マネージャー。|川上量生の胸のうち|川上量生|cakes(ケイクス) ドワンゴ「助けて! エンジニアが朝出社しないの!」→ 女子マネージャーが弁当を手渡してくれる「女子マネ弁当」システム導入で生活習慣改善へ - ねとらぼ 今回は、その女子マネ弁当の実情に迫る、社内からのレポートをお届けする。 女子マネ弁当の概要とは以下の通りである。 3月17日から、4月25日までの一ヶ月間、午前10時30分までに出社すると、以下の特典がある 午前10時30分から、エンジ色のジャージを来た女子マネ人員(なぜか若い女性のみで構成されている男女比率の偏った集団)が、エンジ
厚生労働省呼び出し事件の真相 ──首都圏の新卒者がドワンゴの採用試験を受験するとき、受験料2525円を払うことになりましたね。 これは今の就活のあり方に、僕なりに思うことがあるから。2525円なら大きな負担にならないだろうときめました。受験料は全額、日本学生支援機構に寄付します。 他の方法も考えましたが、「お金を取る」ことは、今の就活が、いかに問題が多いかを世に知らしめる、いちばんいい方法だなと思いました。「お金を取る」のは単純には理解されないだろうから、様々な意見が出ると思いました。それが狙いでした。 ──特に今の就活のどこに問題を感じますか。 「リクナビ」はひどいと思います。学生をたくさんの会社にエントリーさせようと煽っている。会員登録すると人気ランキング上位の会社に全部エントリーしてみましょう、と勧められる。「まとめてエントリー」ボタンを押すと上位50社とかにいきなりエントリーされる
以下のエントリがきっかけになり、「最初の3年」について様々なエントリが書かれている。先ほど見たらはてなブログの旬のトピックが「最初の3年」になっていた。 最初の3年で仕事人生の大半が決まる説 - sudoken Blog この「最初の3年で仕事人生の大半が決まる説」に、僕は当然ながら賛成することができない。反例はいくらでも見つかるだろうし、そもそも、この説を唱える人の多くがまだ仕事人生の途上にあり、それなのに「決まる」と断言できてしまっているのはなかなか滑稽でもある(自分はもう「決まった」ということだろうか?)。言えたとしても「最初の3年で仕事の基本を身につけると、そこから先の仕事人生がラク」ぐらいが妥当なのではないだろうか。 とはいえ、元記事にもあるように、巷ではこの説を唱える人も結構多い。僕も前職の時に似たような話をする人に会ったことがあるし、入社式の時にエライ人からこの説を理由に「だ
前回のエントリで、プログラマの業界が労働集約的なものと知識集約的なものにわかれてきているという話を書きました。 プログラマ業界の二分化 - きしだのはてな 前のエントリでは労働集約的なものと知識集約的なものに完全にわかれているように書きましたが、もちろん完全に労働集約的であったり完全に知識集約的であったりすることは少なく、どのような組織でもある程度は両方の性質をもっています。知識集約的な性質の強いSI会社というのもあります。 ただ、SIに労働集約的な、サービスに知識集約的な性質が強くなる傾向はあると思います。 また、知識集約的であればよくて労働集約的であればダメということもありません。労働集約的なSIでありながら良い会社というのもあります。 という断りをいれておかないと、SIで労働集約だからといって全部ひとからげにするなという、労働集約的なSIでありながら良い会社方面から鋭利なマサカリが飛
詳細設計書という名のゴミ | Gm7add9 この手の話題が定期的に上がるわけですけど、毎度同じだよねで終わってしまっては人間進歩しないので、何が問題でどうすればよいのか少し考えてみたく。 詳細設計書は「プログラム説明書」として欲しい。 まあ、元記事も多分業務システムの受託の話の模様なのでSIをターゲットに。 往々にしてSI、特にウォーターフォール開発のプロジェクトの中では、設計書などのドキュメントを多数作成いたします。*1 V字モデル的には、設計から開発に至るまでの間 要件定義書 基本設計書・外部設計書 基本設計書・内部設計書 詳細設計書 プログラム みたいな成果物を作成いたします。 個別の詳細は別のサイトに任せるとして、それぞれ記載する内容を一言で表すと、要件定義書は「スタートとゴール」、外部設計書は「業務とサービスの仕様」、内部設計書は「サービスの構造と機能の分割」となります。 ※た
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く