一日8時間、60日間ペアプロしてみて思った日常ペアプロのコツ. 一日だいたい8時間、今日まであわせて60営業日くらい、固定ペアのペアプログラミン… | by Naohiro Oogatta | Medium
一日だいたい8時間、今日まであわせて60営業日くらい、固定ペアのペアプログラミングで新規アプリのクライアントからサーバまで開発してみました。チームにエンジニアがちょうど二人だったので。 もはや日常がペアプロです。ペアプロ以外でやってるのは簡単なバグ修正やちょっとした環境整備で、あとはすべて二人で開発しています。ちなみにまだまだ続いています。狂気です。 いい大人が二人集まって狂気を選ぶことになったわけは、成果も出てないしまだ書けません。でも今って、ペアプロやモブプロがブームだって聞きました。それじゃあアホみたいにやってる人間としては黙ってられないです。基本的なことはおいといて、とりあえずこれだけはってつくづく思ったのとか、ペアプロを有意義に長く続けるコツをまとめてみました。 （ちゃんとした話は ペアプログラミングの5W1HとFAQ / 5W1H and FAQ of Pair Program
「ノーアジェンダ・どうしましょうか会議」の傾向と対策 - UNIX的なアレ
wadap.hatenablog.com 先日、こんなエントリーを書きました。割とエンジニアやデザイナーの方は経験したことがある会議ではないでしょうか。このワードに反応されていたので、少し掘り下げてみたいと思います。 「ノーアジェンダ・どうしましょうか会議」とは もうこの名前に全てが詰まってはいるので、経験したことがある人はすぐにわかるとおもうのですが、以下の点が揃っているとまさにその会議かと思います。 アジェンダが用意されていない とりあえず関係がありそうな人を呼ぶ 会議が始まり次第「どうしましょうか」的な空気が流れる ダラダラ長い 丸投げ感満載 というところでしょうか。会議そのものに主催者側の専門性があるものでは起きづらいのですが、自身が理解できない or 経験の無い領域の話になるとわりとこういう会議になりがちなのかなと思います。 会議の傾向 そしてこの会議が始まり「どうしましょうか」
リモートワークへの努力とは何なのか - axross.io
リモートワークへの努力とは何なのか 僕が去年の11月にKaizen Platformに転職したこともあり、知り合いから「自分たちの会社でリモートワークを始めた/始めたい」関係の話を聞くことが多くなってきた。転職してまだ半年くらいだけど、僕たちの会社の取り組みや、それに対して僕が考えていることを書いてみる。 ここに書いてあることはKaizen Platformの他のメンバーと見解が違う場合がある。かつて弊社の技術顧問だった@naoya_ito氏はこれらの文化の土台を築いたが、彼はそれをルールとして縛ることはせず、ガイドラインとして残した。だから多様な見解があり、僕たちはそれを良しとして仕事をしている。 Kaizen Platform という会社にいる。この会社は文化的にリモートワークが根付いていて、働く場所と時間の制約がない。 時間や場所の制約がないので、同じ時間に同じ場所にみんなが集まるこ
メンバーが増えるので、開発方針をまとめました。 - CureApp開発者ブログ
2016 - 03 - 31 メンバーが増えるので、開発方針をまとめました。 4月から、新たに3名のエンジニアがCureAppに加わります！ 今まで、チームとしてどうあるべきか、というのもあまり考えずに走ってきました。 ということで、ここで一度振り返って、どういうチームでありたいか、ということをまとめてみました。 長くて暑苦しくなってしまうものですね。 これを、初版としてどんどん改良していきます。 CureApp開発チームの目指すもの、それは それぞれが別な得意領域を持ちながら広くシステムを理解し、開発に参加できるチーム 社員は、どのプロジェクトにアサインされても戦力になるようにする。 そのために、 マルチプラットフォーム な言語を選択する (まずは JavaScript ) 皆が思う「良いコード」が同じになるように、 設計思想 を統一。 同期/非同期 コミュニケーション により情報を共有
技術採択のときにやるべきこと - まるまるこふこふ
初めに 新規プロジェクト／既存プロジェクトで、新しく使う ライブラリだったり、フレームワークだったり、ミドルウェアを選定してきた経験を通して、 採択する段階でこれはしておいた方がいいなという知見が溜まったので、 メモ書き程度に記述します。 前提として、技術採択についてある程度メンバーに裁量が任せられている風土があり、 かつミッションクリティカルでないシステムに導入する、また自社で事業を行っており、 顧客＝ユーザーであるというのがあります。 (この辺の前提条件が違う場合、採択に当たってまた別の観点が必要になってくると思います) システム要件を満たしているかどうか なんだかフワっとした言い方になりましたが、例えば Web システムに JavaScript のライブラリを 導入する場合に、Web システムが IE8 に対応するという要件ならば、 そのライブラリが、IE8 でも動くか調査するという
Kaizen Platform, Inc. エンジニア行動指針
Engineering Teamの Akira MAEDA です。 今回はKaizen Platform, Inc.社内にあるエンジニア行動指針を紹介したいと思います。 このエンジニア行動指針は創業間もない頃に技術顧問のNaoya Itoが中心になって作成し、今から2年半ほど前にオフィスに遊びに行った私に、CTOのToshimasa Ishibashi、Naoya Itoの二人がKaizen Platformの実現しようとしている未来とともに熱心に説明してくれ、私のKaizen Platformへの転職のきっかけになったことを今でも思い出します。 以下内容 — - Kaizen Platform, Inc. エンジニア行動指針Message from CEO (Kenji Sudo)・ 我々はクラウドソーシングで新しい働き方を作り出していく集団なんだから、我々自身も新しい組織のあり方に挑戦
Producteevはチームで使える無料タスク管理ツールの決定版！ | jMatsuzaki
やっと見つけたぞ！チームでも使える無料タスク管理ツールの決定版Producteev！ 2015年2月10日投稿 2017年12月4日更新 カテゴリ：タスク・スケジュール管理 著者: jMatsuzaki 私の愛しいアップルパイへ ええ、あなたがお怒りなのもごもっともです。世の中にタスク管理ツールはありふれているのに、チームでも使えるに足るタスク管理ツールがほとんど存在しないことに腹をたてているのでしょう。 私も以前は同じ問題に苦悩し、とぐろを巻こうとして千切れてしまった病んだ蛇のようになったものです。 しかし、いまは違います。なぜなら「Producteev」に出会ったからです。 １つ１つ見ていきましょう。 １．ネットワーク・プロジェクト・タグで柔軟に分類 Producteevではタスクをネットワーク・プロジェクト・タグの３つの概念で分類できます。 ▼ネットワークで１つのチームや組織を分類し
伊藤直也が語る「仕事の流儀」第3回──OSSプロジェクトのように組織をつくる｜CodeIQ MAGAZINE
伊藤直也氏が語る「仕事の流儀」の第3回は、暗黙知を作らない組織の作り方。オープンソースのスタイルで組織を作ればいいという直也氏は、KAIZEN platform Inc.において、どのような行動をとっていたのか。 ある取り組みによって、KAIZEN流の行動哲学が生まれたという事例をもとに語っていただいた。 by 馬場美由紀 （CodeIQ中の人） 暗黙知を作るな、すべてを形式知に変えよ 前回は、Sqwiggleを活用したリモートワークやGitHubを活用した開発について述べました。 開発プロセスは、まあアジャイル開発っぽいですね。アジャイル開発というか、スクラムで求められている他のプラクティスについて、KAIZENのリモートワークではどのようにやっているかをもう少し説明すると、まずデイリースタンドアップ、いわゆる朝会です。リモートでやってるので、スタンドアップといいつつ立ってはいないんです
QiitaやKobitoの開発フローと，それを支えるサービス一覧 - Qiita Blog
こんにちは，yaottiです． 前回はQiitaやKobitoを作る開発チームの文化について書きましたが，今回は具体的にどういうツールを使いながら開発しているのか，また開発の雰囲気などを紹介します． QiitaやKobito開発で利用しているツール，サービス一覧 Trello: 開発以外のタスクや仮説の管理Pivotal Tracker: 開発ストーリー管理GitHub: ソースコードのホスティング，レビュー，ディスカッションCircle CI: CI環境Sentry: エラーの補足&通知New Relic: パフォーマンス改善用の測定Amazon Web Services: インフラ(EC2, RDS, ElastiCache)コミュニケーションSlack: チャットQiita Team (& Kobito): テキスト共有&ディスカッションその他Mixpanel: イベント計測Goog
QiitaやKobitoを作る開発チームの文化 - Qiita Blog
こんにちは，yaottiです． 今日はQiitaやQiita:Team, Kobitoを開発するチームでぼくたちがどういう文化，価値観を大切にしているかをお話したいと思います． HRT, SPOF, LeanIncrements(あまり知られていませんが，Qiitaを作っている会社の社名です)の開発チームが特に大切にしているのは以下の3つです． HRTを大切にしたコミュニケーション属人性を極限まで排除する重要な価値に集中する以降でそれぞれ具体的に見ていきます． HRTを大切にしたコミュニケーションHRTとは HRTとはTeam Geek ―Googleのギークたちはいかにしてチームを作るのかという本にある考え方で(あらゆるチーム開発者に読んでほしい!)，Humility(謙遜), Respect(尊敬), Trust(信頼)の3つを意味しています． 「驕り高ぶらないようにしよう」「相手を尊
チームづくりで重要なキーワード Empathy を理解する - ワザノバ | wazanova
http://www.youtube.com/watch?v=1Evwgu369Jw 1 comment | 1 point | by WazanovaNews ■ comment by Jshiike | 約2時間前 大筋意味はわかるし、表面的な日本語訳もできるし、英語で話すときも使うんだけど、100%ニュアンスの理解ができてない英単語に時々出くわします。ほとんどはわかったふりして日常を過ごしてしまうのですが、その単語が重要なキーワードだと、さすがに腹落ちさせないとまずいと思うのですが、今回は運良く、”empathy” のわかりやすい説明を見つけました。 開発のチームづくりの話題を取り上げると、よくでてくる単語が “empathy”です。辞書だと、「共感」「感情移入」という日本語訳になります。オフィスに集ってチーム一丸となって働くとき、またリモートで働くチームをまとめるとき、いずれも
GiltのエンジニアチームのTrustカルチャーと自主的に動くスタイル - ワザノバ | wazanova
GiltのCo-founder & CTOのMichael Bryzekが、同社のエンジニアチームについてインタビューに答えています。 まずは、Ruby -> Java -> Scalaと開発言語が変わっていった経緯について質問を受けて。（Ruby -> Javaは、昼の12時にAmazon並みの大量のトラフィックが集中する同社のフラッシュセールスというビジネスモデルに対応するシステムにするために決めたということだった思います。） RubyからJavaへの転換はやや大変な作業だったが、どうにかできた。Scalaへの移行のきっかけは採用。ものすごくできるエンジニアを2009年 or 2010年はじめあたりに採用できたとき、彼が「自分はScalaを２年やっていて、すごくいいので是非JavaでなくてScalaで。」と言ってきたので、試しにつくらせたのがはじまり。それから、関数型言語としてできるこ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
