Googleが発見した、最も成功しているチームに共通する5つの特性 | ライフハッカー・ジャパン
Inc.：長年にわたり、Googleは数え切れないほどの研究に取り組み、膨大なデータを集め、何百万ドルもをつぎ込んで自社の従業員をより良く理解しようと努めてきました。Googleの最も興味深い取り組みの1つであるプロジェクト・アリストテレス（Project Aristotle）は、社内で最高の業績をあげているチームに焦点を当て、チームの生産性を高める秘訣を探ろうというものでした。 なかでも、生産性の高いチームと低いチームの違いは何なのか？ を解明することに主眼が置かれました。 この調査をはじめる前、Googleの経営陣は、ほかの多くの組織と同じように、最高のチームをつくるということは、最高の人材を集めることであると信じていました。それは理にかなった考えです。最高のエンジニアに、MBA、博士を集めれば、最高のチームのでき上がり。そうですよね？ しかし、Googleの人事分析マネージャ、Jul
KAIZEN platform Inc. の開発マネジメント
フロントエンドのパラダイムを参考にバックエンド開発を再考する / TypeScript による GraphQL バックエンド開発
プログラムにコメント書かない文化もあるよって話｜NZ MoyaSystem
以下の記事を読んで。 530000micro.hatenablog.com 僕が勤めている会社では、原則、プログラムにコメントを書かないのがルールです。 人生で初めてプログラムに触れてからこのかた、プログラムには必ずコメントを書けと指導されて来ましたし、自分自身も、後輩たちにちゃんとコメント書けよと言い聞かせてきました。そんなわけで、最初に全然コメントのないソースコードの山を見たときは、正直「ゲッ、なんじゃこりゃ……」と面食らったのは確かです。 ところが、「なぜうちのプログラムにはコメントがないのか？」と同僚に尋ねてみると、実に納得の行く回答が返ってきたのでした。 なぜコメントが必要なプログラムを書くのか？ 同僚いわく、「コメントが無くても読めるようなプログラムを書け」という思想が根底にあるのだそう。 適切に関数や変数が命名され、スコープがきちんと管理され、ロジックの流れが整理されているコ
UIデザイナー募集で困ってること | F's Garage
トレタCOOのkengochi氏がUIデザイナーについての記事を書いてた。 UIデザインの価値 | Parallelminds BASEでも、ずっとこの辺の職種も募集していて、来月１人入るんだけど、実はUIデザイナーの募集はすごく困っている。 というのも、今、BASEでほしいUIデザイナーとは、 ・いわゆるWebデザイナーではないし、 ・いわゆるフロントエンドエンジニア（JavaScript実装特化型）の人でもない。 というところ。まさしくkengochi氏が書いてる「のりしろ」重要 じゃぁコアスキルって何？ってのを、経験者採用の理想を言えば、 １．D.A.ノーマンの本ぐらいは読んだことがあって、ユーザインターフェースを意識しながらユーザビリティの高い設計ができて ２．ビジュアルデザインのスキルもあって、カッコいサイト、サービスが作れて、 ３．ちゃんとユーザーさんのことを意識できて（つまり
ソフトウェア開発プロジェクトをとりまく６つの誤解〜プログラミングを経験しないとわからないこと | Social Change!
続きを書きました → 伝えなければ伝わらないという当たり前の話 ソフトウェア開発に関する相談を受ける中で、どうもソフトウェアというものの特性について誤解をされているな、という思いを持つことがあります。 そうした場合、聞いてみるとプログラミングの経験が無かったり、殆どプログラミングには携わったことがないという方が多いです。 ソフトウェアを開発しようとするならば、ソフトウェアという特性をよく知った上で、プロジェクトは運営した方が良いし、うまくいくはずです。そしてソフトウェアならではの特徴を知るのに、プログラミングの経験はとても重要です。 この記事では、プログラミング経験の無い方が陥ってしまいがちな、ソフトウェア開発にまつわる誤解について考えてみました。 Harry Potter is Ready for Divination / weekbeforenext 誤解：既にあるソフトウェアを流用し
CNET Japan
人気の記事 1グーグル「Pixel Slate」を使ってみて--長所と短所、「iPad Pro」との比較など 2018年12月10日 2サムスン、穴開き画面の「Galaxy A8s」を発表--「Infinity-O」初搭載 2018年12月11日 3ヤマハ発動機、約113億円規模の自社ファンド設立--モビリティや自動化技術など 2018年12月11日 4NTTデータ、国内外の各種コード決済を端末1台で完結できる小売向けソリューション 2018年12月11日 5ドローン空撮的な映像が作れる「Google Earth Studio」--宇宙まで続くイームズ風CGも 2018年12月11日 6カプコン、大型拡張コンテンツ「モンスターハンターワールド：アイスボーン」を発表 2018年12月11日 7「Google+」に新たなバグ、5250万人に影響--一般向け終了を2019年4月に繰り上げ 201
より良いユーザーストーリーを書くための10個のヒント
みなさんこんにちは。@ryuzeeです。 Roman Pichler氏によるユーザーストーリーの書き方の資料が分かりやすいので紹介します。 https://www.romanpichler.com/wp-content/uploads/2013/06/WritingGreatUserStories.pdf より良いユーザーストーリーを書くための10個のヒントシステムの利用者に焦点をあてるストーリーの記述ではユーザーロールを意識するユーザーストーリーをもとに議論するユーザーストーリーはチームとステークホルダー間の議論を活性化させるための道具ユーザーストーリーは仕様ではなく、機能に関する議論のエッセンスであるユーザーストーリーを書くのはチーム全体の仕事ユーザーストーリーを書くのに全員が協力するユーザーストーリーをより良くするために定期的にバックログリファインメントを行うシンプルに保つあいまいな
ハインリッヒの法則 - Wikipedia
災害とは，物体，物質，人間または放射線の作用または反作用によって，人間の傷害またはその可能性を生ずるような、予想外の，しかも抑制されない事象である。 --H. W. ハインリッヒ、D. ピーターセン、N. ルース（著）井上威恭（監修）、（財）総合安全工学研究所（訳） 『ハインリッヒ産業災害防止論 海文堂出版（株） 1987年（昭和62年）9月 2版 ISBN 430358052X p21』 である。 上記の法則から、 教訓1 災害を防げば傷害はなくなる[3]。 教訓2 不安全行動と不安全状態をなくせば、災害も傷害もなくなる[3]。（職場の環境面の安全点検整備、特に、労働者の適正な採用、研修、監督、それらの経営者の責任をも言及している）[4][5]。 という教訓を導き出した。 この法則は、日本の国鉄（現・JRグループ）にも影響を与え、「330運動」（要素の合計が330であることから）と称する
起業から30人の会社になるまでに学んだ3つのこと | 近江商人JINBLOG
マイネット・ジャパンを起業して4年半が経ちました。本当にたくさんの方々のおかげでようやく当初マイルストーンに置いていた「30人の黒字会社」というラインまでやってくることができました。ちなみにそのラインは私が起業を決めた時点のイーマーキュリー（現ミクシィ）をベンチマークしたものです。今はもう次の段階に向けて動き出しています。 まだ起業の第一段階から第二段階に進むくらいのところなので振り返っている場合ではないのですが、最近よく起業を志す方や起業したばかりの若い方とお話する機会があって、その際自分の経験を踏まえていつもお話する内容が３つあるので一度書きとめておこうと思います。 起業から30人の会社になるまでに守っておきたい3つのこと １．共に「給料を払う側」に立つパートナーを持つこと 共に経営側に立って逃げ場のない戦場に立ってくれる同志を持つことです。←これは私の場合の表現で起業時のスタンスや覚
スタートアップ企業で8年間Webの開発をしてみての反省点いろいろ - Masatomo Nakano Blog
2002年、当時設立したばかりの会社に入り、何もない状態から、コンテンツとシステムを作り続け8年が経った。日々、試行錯誤しながら、それなりに会社も大きくなり、まだ、大成功とは言えないけど、それなりにうまくやってきたつもりだ。 しかしながら、その8年という短くはない時間の中で、色々な課題や問題が発生し、その時々正しい選択をしてきたつもりだったけど、反省点も多い。もう一度スタートアップに参加するとしたら、やり直したいところや、もっと早くこうしていれば良かったというところがたくさんある。 そんなわけで、次の挑戦のときに忘れないように、また、もしかして誰かの参考くらいになればと思い、メモっておくことにした。1 まず、反省点の前に、何をやっているのかというのを簡単に。 ビジネスとしては、英語e-learningのWebサービス(ネットを使った英語のお勉強)をASPな形で、企業や大学などに提供している
人人月の寓話：プログラマで、生きている：エンジニアライフ
わたしがまだ新人プログラマだった頃、キックオフミーティングで渡された仕事の割り振り表のメンバーの欄に「X」と書かれていたことがありました。 「Xって誰ですか？」と尋ねると「そのうち現れるであろう誰か」という答えが返ってきました。要するにエンジニアを確保するつもりはあるんだけど見つかっていないということです。「ホントに現れるのか？」とわたしは疑っていましたが「X」は現れました。 ていうか、わたしでした。 リーダーから「X」と命名（？）された先輩とわたしは2人でその担当分を片づけることに（もちろん本来の担当分も片づけた）。 「結局見つからないんだったら、最初っからXなんて書かなければいいのに」とグチったら、一緒に担当分を増やされた先輩に「上の人間もぎりぎりまでがんばって探してたんだよ。いないものはいないんだから仕方ない。いる人間でがんばって片づけよう」と諭されました。 その後、さまざまなプロジ
失敗ができる国、日本 : けんすう日記
解雇規制で失敗できない？ 失敗できない日本 - Zopeジャンキー日記 こんな日記がありました。 すごくざっくりというと - 日本では解雇規制があるから、いったん正社員を採用すれば、会社側から解雇することはほぼできない - よって、採用に失敗できない会社は人をとるのに慎重になる - お荷物社員がいるから新しく採用できない - それが日本の様々な問題生んでいる - 新卒で失敗できない、という新卒史上主義の原因もそれ という感じです。たぶん。 割となるほどなあ、という気はする論調です。たしかに採用に関するリスクが高すぎるので、僕の会社でもなかなかその意思決定はできません。 一方で、この仕組によって「失敗しやすくなる」面もあるのではないかなーと思うこの頃です。 （追記：「論点が違う」という人がいますが、そもそも、別に反論でもなんでもないので、論点あわせていないです、念のため） 実は失敗できる仕組
“めげない開発チーム”を作るのに必要なこと
世界同時不況の影響で開発コストが大幅に削減され、閉塞感が漂う開発現場は多い。そのようなとき、どうやってモチベーションを維持し、上げていけばよいのか。デバッグ工学研究所代表の松尾谷徹氏に話を聞いた。 リーマンショックを契機に世界同時不況に突入し、ITシステムの開発コストは大幅に削減されている。開発案件自体が減少しているほか、既存の開発案件においても“コスト削減”や“生産性の向上”が叫ばれている現場がほとんどだろう。このような状況下、システム開発の現場では閉塞感を感じている担当者も多い。 では、このような状況下においても、システムやソフトウェア開発チームのモチベーションを維持するためにはどうすればよいのだろうか。多くのプロジェクト案件を手掛け、現在ではチームモチベーションやテスト管理などを研究しているデバッグ工学研究所代表の松尾谷徹氏に話を聞いた。 仲間意識の薄い開発チーム 松尾谷氏はまず、現
社内で認定スクラムマスター研修のレポートをしてきた - ヲトナ.backtrace
先月受けた CSM 研修の内容を本社でレポートする事になった。 けれど、2 日間の内容を 1 時間で話すのは無理なので、自分が感じている Scrum の特徴や利点について(変化球気味に?)発表してきました。 How to eliminate the waste of software development v0.1View more documents from nawoto. 自分でもまだ上手く咀嚼できてなく gdgd な感じだったのですが、「問題を明確にしやすくし、問題に向き合う方に力が働きやすい」という自分が興味を持った Scrum の特徴は何とか伝えれたかな?? このネタはもう少しちゃんと説明できるようにしたいなぁ〜
Twitterを全社導入して気づいたこと - EC studio 社長ブログ
——————————————————————————— ■書籍紹介：「iPhoneとツイッターで会社は儲かる」 iPhoneとツイッター、そしてGoogle Appsに組み合わせた クラウド上で起こるコミュニケーション革命について詳細に解説しています。 最終章ではGoogle 代表取締役の辻野氏との対談も収録しています。 ※アマゾンで購入いただいた方にはGoogle辻野社長とのインタビュー 音声ファイルをプレゼント！書籍には収録されていないGoogleの未来についての 話がたっぷり詰まっています。詳しくはコチラ ——————————————————————————— EC studio ではTwitterを全社導入して1ヶ月が経過しました。 そこでTwitter導入を検討している企業やTwitterに関心のある方向けに 実際全社導入してどうだったか気づいたことを書きたいと思います。 約1ヶ
プロジェクトリーダーに求められるIA視点――プロジェクトアーキテクトという役割 | [コラム]IA視点のWebプロジェクト
前回はIA（情報アーキテクチャとインフォメーションアーキテクト）の言葉の定義と、プロジェクトのタイプごとにインフォメーションアーキテクトのアサインを変える必要があることを記しました。今回は、どうしてそうなっているのかを説明します。 情報アーキテクチャ設計の影響範囲情報アーキテクチャとは、前回の記事で取り上げたように、サイト内での情報の分類や、情報のつながりを定義することです。定義するということは、その情報の優先順位を明確にして、意志を持ってルールを作ることだとも言えます。 一般的な企業サイトの構築において、この「情報を収集し」「整理し」「優先順位をつける」ことは、単にデータや情報を対象とするより、もっと広い意味で捉える必要があります。情報自体の複雑さや扱い方のパターンを精査するよりも、さまざまなレベルの意志決定をすることの方が重要だからです。たとえば、広報や製品担当者、デザイナなどのサイト
![プロジェクトリーダーに求められるIA視点――プロジェクトアーキテクトという役割 | [コラム]IA視点のWebプロジェクト](https://cdn-ak-scissors.b.st-hatena.com/image/square/6ab17de853b8c29cab6194a39392ba38d04eb0dd/height=288;version=1;width=512/https%3A%2F%2Fwebtan.impress.co.jp%2Fsites%2Fdefault%2Ffiles%2Fstyles%2F1200x630%2Fpublic%2Fimages%2Fweb_project%2Fweb_project_icon.jpg%3Fitok%3DqL-1gvO5){kind=icon}
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
開発組織マネジメントのコツ - Speaker Deck
Amazon.co.jp
戦略(Strategy)、作戦(Operation)、戦術(Tactics)、そして兵站(Logistics) - UEI/ARC shi3zの日記.
「Railsで定時近くに帰れるようになったけど...」 - ヲトナ.backtrace