生産性とチームと技術的負債
poem.md 生産性とチームと技術的負債 当然だけど正しいとは限らない。 普段思っている事を書きなぐった。 生産性 理想的には一人が最高。 コミュニケーションコストは人によってはコードを書くよりも遥かにコストが高い。 自分はコミュ障なのでコミュニケーションコストがとても大きい。 たとえ git を使っていてもクソコードを製造する働き者がいるとコンフリクトが怖くて全体的な改善に手を付けられない。 生産性 x0.1 と x10.0 の人間を同居させると、二人の生産性は高々 x0.1 で固定される。 無能な働き者は排除するしかない。 本人の志向もあるとはおもうが、基本的には得意なことがあるなら得意な事に専念するべき。 ゼネラリストに転向させるよりは、そちらの方が結局は全体の効率化につながる。 （この辺は次のチームの話にもつながる） チームへの貢献 あるメンバーが抜けても大丈夫なように他のメンバ
【一人でできた！】アジャイル開発手法「次世代ペアプログラミング」 – NSFW | Develog.VR
ペアプログラミングとは、我々プログラマの誰しもが通る最初の試練の門。 このときのメンターによって今後、毎日が色鮮やかで楽しいプログラマー生活を送れるか、サラリーマンプログラマーとして一生色あせた生活を送るかが決定します。 ※wikipedia http://ja.wikipedia.org/wiki/%E3%83%9A%E3%82%A2%E3%83%97%E3%83%AD%E3%82%B0%E3%83%A9%E3%83%9F%E3%83%B3%E3%82%B0 一人でもできる。ペアプロ誕生の瞬間 @yuujii 夢のシチュですか！？ えーとえーと、やっぱりタイピングで胸が揺れる女子高生が隣にいるシチュですかね…！？ — 此ノ木よしる@SE1巻発売中！ (@y_konogi) February 26, 2014 ヤングアニマルで「SE」を連載中の此ノ木よしる先生は、 旦那さんからペアプロとい
チーム開発とクソコード - tototoshi の日記
今までパッケージソフトとかWebサービスの開発をしてきた中で、ビジネス上の納期や要求を満たすためにひどいコードを書くっていうのは自分の経験ではあまりなかった気がします。なにかひどいバグがあって、とりあえずのパッチを当てて間に合わす、ということはたまにあるけれど。SIの世界は知りませんよ。 そもそもコードを汚くかけば納期に間に合うということもないし、ビジネス上の近道になるということもない。コードをきれいに書こうが汚く書こうが無理なものは無理。第一汚いコードを意図的に書くというのも意外に難しいということは、普段まあまあきれいなコードを書いている人ならわかってくれるんじゃないかと思います。 仕様変更に設計がついていけてなくておかしいとかならともかく、関数が1000行あるとか、newした瞬間全てが終わるとか、変数のスコープがびっくりするくらい広い、みたいなコードについてははビジネス上の要求ではなく
憤怒と侮蔑の話 - 神社
技術的負債云々の話から、自分の失敗を思い出したので。 ある行動から人に悪意をぶつけるとき、もしくは吐き出してしまった後、ちょっと冷静になると、いつも憤怒と侮蔑を思い出すように心がけている。 つまるところ僕はその人に憤怒しているのか、それともその人を侮蔑しているのか、ということ。とにかく憤怒と侮蔑は明確に分けておかないといけない。大げさな言葉にしているのは、極端にしないと『どっちもかもしれない』なんていう曖昧な考えになるからで、ちゃんと分別するために大げさな言葉を使わないといけない。 憤怒しているというのはつまり怒っているので、それはもう腹を立てている。『こんなクソコード書きやがってちくしょう！あの野郎！』みたいな感じ。僕はよくこういう状態になる。自分にもなる。それはもうよく怒る。大体僕は短気なので、すぐに怒ってしまう。でも、元のコードを書いた人を侮蔑してはいけないので、怒っても怒っても、出
これからはプログラマも社内アウトプットしていくべきだ。ミツバチワークス富田明徳氏 - Qiita Blog
こんにちは、ミキです。 みなさんはチーム内で情報共有するときどうやって共有していますか？ 今日は、Qiita:Teamをご利用いただき円滑に情報共有・開発している ミツバチワークス株式会社さんの事例を皆さんにご紹介します:) Qiita:Teamは30日間の無料トライアルが可能ですので、この機会にお試しください:) #ミツバチワークスさん ##サマリー ###ポイントをまとめると – Hipchat連携によりリアルタイムで情報共有ができる – 問題を見つけ、自分から仕事を見つけ出すことができるツール ###目次 – インタビューサマリー – ミツバチワークス株式会社 – 他サービスからQiita:Teamに移行した理由 – 何人で利用されていますか？ – 今までのチーム内コミュニケーション（ツール）の課題 – Qiita:Teamを選んだ理由 – チームで開発しているのですか？ – 他には
コードレビューを円滑に行いたい (#cross2014 のお話) - $shibayu36->blog;
id:antipopさんやid:studio3104さんに機会をもらえて、CROSS 2021に参加させてもらい、はてなでのレビューの話を軽くさせてもらった。はてなからは僕とid:hakobe932さんとで参加した。 http://blog.kentarok.org/entry/2014/01/18/204552 2014/1/17 #cross2014 コードレビューCROSS 〜ぶつかり稽古 2014初場所〜 - Togetter それで、今回参加して他の会社の人のレビューの話も聞いて、あーそれはあるあるとか、そういう問題解決するためにこういうことしてますとか、他の会社ではこういう時どうしているんだろとか、幾つかおもうところがあったので、もう少しレビューのことについて書いてみる。 レビューと関係性問題 レビュアーとレビュイーの関係に関して - 職質アンチパターン コードレビューと関係性
レビュアーとレビュイーの関係に関して - 職質アンチパターン
感じていた違和感の正体がわかった． レビューにおいて，レビュアーとレビュイーの関係には上も下もない． レビューという場では，両者の立場は対等でなければならない．さもなければ，「このレビューおかしい気がするけれど，あの人は立場が上だから指摘しにくい」だとか，「相手は格下だから適当にレビューしても良い」だとか，そういう良くない雰囲気が形成されてしまう． 確かに，レビュアーというポジションはチームの技術力が高い人やそれに伴ってパワーのある人が担うケースが多いと思う．レビュイーはそれに萎縮してしまいがちというか，僕もその1人なんだけれど，そういうのは実際のところ保身でしかなくて，下手に意見言うとレビュアーとの関係悪くなりそう，みたいな卑屈な理屈に基づく駄目な萎縮な感じがする．こういう良くないところはちゃんと直して，健全化していかなければまずい． あとレビューされた内容は素直に受け入れるべきだと思う
ペアリング対コードレビュー: 開発者文化の比較
前職 と 現職 で、ペアプログラミング文化からコードレビュー文化への移行を経験した。文化の差に適合するのは興味深い経験だった。ちょっと気づいたことを書いてみよう。 (ペアプログラミング|コードレビュー)の(メリット|危険性)みたいな題名の記事はもう山ほどある。著者はどっちかの信奉者なわけだ。私は明確トレードオフがちょっとあるにせよ、どっちの戦略も有効であると認識している。このトレードオフについて、もうちょっとバランスのとれた議論をしてみようと思う。 用語の定義 まず、舞台を整えよう。”ペアプログラミング” とか”コードレビュー”という言葉は、人によってとらえ方が大きく異なることがある。 ペアプログラミング文化 といったとき、作業のほぼ100%をペア作業で行っているチームを指す。一つのタスクに二人の開発者が割り当てられ、同じ画面を共有して作業をする。開発者は両方コード構築のプロセスに関わって
Team Geek読んだ - はこべにっき ♨
Team Geek ―Googleのギークたちはいかにしてチームを作るのか 作者: Brian W. Fitzpatrick,Ben Collins-Sussman,及川卓也,角征典出版社/メーカー: オライリージャパン発売日: 2013/07/20メディア: 単行本（ソフトカバー）この商品を含むブログ (20件) を見る Team Geekを読んだ。チームの生産性を上げるために、どうやって人間関係やコミュニケーションの問題に取り組めばよいかという、実践的なテクニックがいろいろ詰まっていておもしろい。謙虚・尊敬・信頼という信条を中心に、個人、チーム、組織そしてユーザ、それぞれとどのように付き合えばいいか、いろいろな例を使って教えてくれる。おもしろい感想エントリもたくさんあるので、内容が気になる人は読むと良さそう。 L'eclat des jours(2013-07-21) Jun Muka
Square: 普段仕事してる雰囲気でインタビューに臨んでもらう - ワザノバ | wazanova
http://corner.squareup.com/2013/11/culture-fit.htmlSquareが一連のブログでエンジニアのインタビュープロセス、採用基準などについて公開しています。昨日発表されたViewfinderの買収も報道によると、サービスを取り込むというよりはNYに拠点を広げるタレントバイ（talent-buy: 優秀な人材の確保）のようです。買収金額は発表されてませんが、買収先のサービスが不要で人材だけを確保する目的の場合は、人数 x $1M（約1億円）が相場と言われてるので、数億円〜10億円程度の規模でしょうか。 さてインタビューに話しを戻すと、ベイエリアの企業のエンジニアのインタビューは丸1日かかるので、現在勤めてる会社を休まないと面接にいけないという話しはよく聞きますが、Squareも例にもれず、かなり時間をかけているようです。 インタビューは計５時間 「
本当にあったプログラマとデザイナの怖くない話 in Fukuoka.php Vol.11 · けんごのお屋敷
Fukuoka.php Vol.11 に参加してきました。 リンク先にもあるように今回は NO PHP DAY ということで Fukuoka.php という名前を冠しながらも、誰一人として PHP の話をしなかったという珍しい勉強会でした。残念ながらUstreamの中継はなかったためオープンにはなりませんでしたが、いろいろと勉強になってたくさんインプットができたイベントでした。素晴らしい発表の数々は、後々各発表者の方より資料やブログが公開されると思います。Twitter では #fukuokaphp ハッシュタグで流れを追えると思います。 そんな NO PHP DAY な Fukuoka.php で僕も LT 枠をもらっていたので、ひとつアウトプットをしてきました。 プログラマとデザイナのコラボレーション Web 業界では、プログラマとデザイナが一緒に仕事をすることは多いと思います。一般的
チャットワークAPIを限定プレビュー公開します！
技術者の皆さま、お待たせしました！ 以前より多くの要望があったチャットワークAPIの公開について詳細が決定しました。 まずは限定プレビュー公開としてAPIを提供します。 正式公開のスケジュールについては、ソーシャルメディアやブログなどで改めて告知させていただきますので、よろしくお願いします。 プレビュー公開の目的 一般公開する前に、まずは利用できるユーザーを絞ってプレビュー公開します。 そしてフィードバックを元に、正式公開へ向けての改善を実施していきます。 (プレビュー公開の期間中は、いただいたフィードバックを元にAPI設計の仕様変更をおこなう場合がありますので、あらかじめご了承ください) 技術者の皆さまに快適に利用していただけるよう、ご理解・ご協力をよろしくお願いいたします。 API機能一覧 今回のプレビュー公開では、APIを通じて下記の機能が使えるようになります。 今後も随時拡張してい
プログラミング上達したいならチャットサービスLingrをつかおう（つかおう） - かなりすごいブログ
みなさんチャットしてますか？私はしてます（すごく）。 今日はチャット普段なんてしてないという人のためにLingr（りんぐる）というチャットサービスをご紹介します。既に普段からIRCとかしてる人は特に読まなくてもいいかもです。 http://lingr.com/ 【Lingrのここがすごい１】画像やGist・YouTube動画などのインライン表示ができるLingrのウェブクライアントでは、画像URLやGistのURL、YouTubeのURLが貼られた際、自動でインライン表示をしてくれます。 後述するbot作成用APIと組み合わせることで、ユーザーの発言に対して任意の画像を表示するようなbotを簡単に作成することができます。 画像urlを返すbot例#image 検索ワードと発言すると、Google画像検索結果の画面のスクリーンショットURLを返すbotがありますので、例としてお見せしましょう
ディレクターがプログラマーとうまくやる方法を全部教えます : LINE Corporation ディレクターブログ
こんにちは、櫛井です。 プロジェクトマネージャーやディレクターの仕事というのは多岐に渡りますが、特にプログラマーと上手にコミュニケーションを取り一定の目的を果たすというのはわりと大変なことだったりするらしいです。私は比較的プログラマーとうまくやれているタイプのようなのであまり苦労した覚えが無いのですが、過去10数年で培ったプログラマーと上手くやる方法を紹介していきたいと思います。おまけで「プログラマーに嫌われる６つのこと」も紹介します。 ※うまくやれてるイメージ図 プログラマーと上手くやる方法をざっくり言うと 役割分担として求められていることをやる お互いのTODOを把握し区切りをつける スケジュール管理をしっかりする といったカンジです。ではそれぞれ説明していきます。 役割分担として求められていることをやる そもそもディレクターが求められる役割とはなんでしょうか。Web開発案件におけるデ
ScaleOut | Supership
2024年4月1日より、Supership株式会社は親会社であるSupershipホールディングス株式会社に吸収合併されました。 合併に伴い、存続会社であるSupershipホールディングスは社名をSupershipに変更し、新たな経営体制を発足しました。本件に関する詳細は、プレスリリースをご確認ください。 2024年4月1日より、Supership株式会社は親会社であるSupershipホールディングス株式会社に吸収合併されました。 合併に伴い、存続会社であるSupershipホールディングスは社名をSupershipに変更し、新たな経営体制を発足しました。 本件に関する詳細は、プレスリリースをご確認ください。
プログラマーは皆、常に秘密や嘘を抱えている - totopon114689の日記
プログラマーは皆、常に秘密や嘘を抱えている。 これは間違いない。 基本的には誰にも話さないが、 （家族や友人などプログラムを知っていない人間に話しても分からない、という事もある） プログラマー同士の飲みの席などで、過去の笑い話として酒の肴になる事はある。 秘密や嘘の傾向には幾つかのパターンがある。 1) 仕様があいまいな場合の適当なコーディング 仕様があいまいな機能を実装する場合、想定していたものよりもプログラム量が膨大になる事はよくある。 また、細かいパターンや想定外のケースに対し、どのようにプログラム的対処を行うべきか？ 洗い出しているとキリがない場合もある。 仮に事前に洗い出していたとしても、 「ケース自体は洗い出せているが、具体的にどのようなエラーメッセージを表示すべきか？」 などといった、その先がまたあいまいになっている場合もある。 このような場合、本来であれば決裁権のある人間に
全てのコードに懺悔せよ
ソースコードは資産か、負債か？この問いに自信を持って資産であると断言する方は、残念ながらこの記事とは縁が無かったので回れ右をして帰っていただきたい。今回は思うところが有ったので技術的な話題ではなく、その思うところについて書いてみようと思う。 「ソースコードは負債である」 流行り言葉そのままで申し訳無いが、「ソースコードは資産である一方で負債でしかない側面が有る」と、僕個人としては思う。ソースコードが生み出す価値は資産足り得るがソースコードそのものは紛れもなく負債だ。ソースコードは収穫が約束されない代わりに無限に広げられる畑に例えることが出来ると思う。ソースコードは恵みをもたらすかも知れない。故に、その恵みを最大化するために畑を広げたいと考える。しかし、無闇に畑を広げることは害獣に襲われる土地を増やすことでもあるし、耕し、監視し、水やりをしなければならない範囲が広げるということでもある。つま
ペアプロの成功体験と失敗体験 - $shibayu36->blog;
ペアプロって難しい。今のところ、基本的にうまくいかないことが多い。 その中でもたまに成功体験みたいなのがあったので、それを書いてみる。今回の話はあくまでも主観で感じたことである。断定的な書き方をしているのは単に書きやすいからであって、他意はない。あと失敗体験も書いておく。 今回の話に初心者と上級者という言葉が出てくる。これはペアプロ対象に対する初心者・上級者というものとする。なので初心者は「ペアプロ対象に対してあまり知識を持っていない」人であり、上級者は「ペアプロ対象に対して知識をある程度持っている」人とする。 ペアプロ対象の定義は難しくて、Perlで書かれたものであれば、Perlの知識は必要だけど、Perlで作られたある機能の知識や、もしかしたらMySQLの知識みたいなものも対象になりうるかもしれない。そのようなものを漠然とまとめて、ペアプロ対象と言っておく。 成功体験 ペアプロ対象に対
離れた場所で働くチームのつくり方〜１年間のアイルランドでの実践で学んだこと | Social Change!
『国境なきプログラマ』を目指す～ノマドワークの究極のかたち ちょうど１年ほど前に、こんなブログを書きました。ソニックガーデンのプログラマが単身、アイルランドのダブリンに１年間滞在しつつ、日本の仕事をしながらも、現地で生活をおくるという内容です。 こちらの記事で紹介した、ダブリン生活にチャレンジしてきたプログラマの maedana がつい先日、無事に日本に帰ってきました。 日本との時差9時間の中で、1年間1度も日本に帰ることなく、リモートで働いてもらったのですが、結果としては、大きな問題はなく、概ねうまくいったと言ってもいいでしょう。 この記事では、そのアイルランドのプログラマと日本のプログラマやお客様と、どうやって離れた場所だけど、ひとつのチームとして一緒に働くことができたのか、ふりかえってみたいと思います。 1年間のリモートワークの前提や環境について 彼がアイルランドに行く前に想定してい
いまだに知らないなんてありえない病 : 小野和俊のブログ
いまだに知らないなんてありえない病とは、プログラマー同士の会話の場で、 「いまだに○○という本さえ読んでいないなんてありえない」 「いまだに○○というフレームワークさえ使っていないなんてありえない」 「いまだに○○という言語を触ったことさえないなんてありえない」 「いまだに○○というパターンさえ知らないなんてありえない」 というように、自分が知っていて相手が知らないものについて、 「いまだに知らないなんてありえない」 と発言してしまう病の総称である。 発症例として、例えば次のようなものがある。 「いまだにマシン語が書けないなんてありえない」 「いまだにRubyを1行も書いたことないなんてありえない」 「いまだにVisitorパターンさえ知らないなんてありえない」 「いまだに高校レベルの数学も押さえていないなんてありえない」 「いまだに個人で開発したアプリが1つもないなんてありえない」 「い
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
