タグ

チーム開発に関するmasayoshinymのブックマーク (380)

  • 「君だけの絶対良感を育てよう!」よいコードについて語り合ったエンジニアインターンシップ - Pepabo Tech Portal

    写真共有サービス 30days Album™ の開発チームでサーバサイドエンジニアとして活動している大和田純です。源氏名は @june29 です。 エンジニアインターン~Ruby on Railsで書き初めしよう2016~ - GMOペパボ株式会社のインターンシップ - Wantedly 上記にてお知らせした通り、2016年2月〜3月の約1ヶ月の間に、エンジニア向けのインターンシップを実施しました。今回は私がメインのメンターとして、インターン生の学生2人の支援をさせていただきました。このエントリでは、インターンシップでは具体的にどんなことをしていたのか、グレートメンター大和田(GMO)を目指した私とインターン生の実録1ヶ月間を紹介します。 「いるだけで成長できる環境」を標榜するペパボのインターンシップを任されたわけですから、私自身を含めた関係者全員の成長につながる日々にしたい思い、全力で取

    「君だけの絶対良感を育てよう!」よいコードについて語り合ったエンジニアインターンシップ - Pepabo Tech Portal
  • スタートアップのCTOになって2ヶ月で作った開発サイクル

    Housmartの宮永です! 今回はカウル開発チームの開発サイクルを紹介させていただきます。 好ましい開発サイクルはサービスや企業、組織規模などに応じて 異なるものだと思いますので、このブログでもまずはチーム体制など 開発手法の採用背景となるところから説明いたします。 チーム体制、サービスについて カウル開発には5人のメンバーがいます。 エンジニア:3人 デザイナー:1人 プロダクトオーナー:1人 実作業ベースで5人の役割が決まっていますが、 サービスをどのように良くしていくかは皆で話し合って考えます。 サービス(カウル)はリリースされてからまだ2ヶ月弱で サービスローンチ後に想定外の運用業務が発生したり、ユーザからの改善要望も多く、 開発すべきこと(開発優先度)は日々変化しかなり流動的なものとなってます。 そのため、要件リストの優先度付けをこまめに行う必要があります。 開発サイクル 上記

  • Prottとsketchとzeplinのススメ

    書籍化し、12万部突破しました。 【SlideShare広告回避用】 https://www.docswell.com/s/morishige/K3MXPZ-howtodesignslides ・PDFは無料でダウンロードできます ・自己学習や勉強会などの目的でしたらご自由にお使いいただけます ・授業・研修への利用はフォーム( https://forms.gle/WwgXTT974xFW78mFA )にご報告ください ・記事への参考資料にする際は適切な出典明記をお願いいたします 【使っているフォントについて】 M+フォント「MigMix1P」です。こちらもメイリオ同様おすすめです。 フリーで使えます。 【個人HP】 > https://mocks.jp > 仕事のご依頼はこちらから 【書籍情報】 デザイン入門:https://amzn.asia/d/4WDsTI6 デザイン図鑑:https

    Prottとsketchとzeplinのススメ
  • ちょっとしたペアプログラミングに便利そうな『Code Coach』 | 100SHIKI

    シンプルでいいかも。 Code Coachではちょっとしたペアプログラミングに使えそうなツールを提供している。 使い方は簡単で、URLの後ろに適当な文字列をくっつけてそれを共有すればいい。 ビデオチャットとも連動しているので話ながら指導ができていいのではなかろうか。 なお普通のエディターばりにショートカットが用意されているのも好感がもてる。 実行環境がないのが微妙ではあるが、知っておいてもいいかもですね。

    ちょっとしたペアプログラミングに便利そうな『Code Coach』 | 100SHIKI
  • プロトタイプに発生する溝と対処法

    完成品になれない溝をどう埋める あたかも完成品に見えてしまうデザインカンプには、様々な暗黙の了解が存在します。グラフィックツールで Web ブラウザ上での見た目を再現しようとしても、実際 HTML / CSS で組まれたデザインの見た目と同じになることはありません。どこまで静止画を作り込んでも、実際の完成品には成り得ない大きな溝が存在します。この溝が大きな誤解に繋がることがあります。 例えばレスポンシブ Web デザインの場合、幾つかの大きさで静止画のデザインを用意したとしても、その間(可変状態)でどうなるか想像するのが難しい場合があります。また、レスポンシブ Web サイトにおける表現は多彩になってきています。要素の順番を Flexbox で変えることもできますし、画像の配置の仕方もより柔軟で表現豊かになってきています。知識や経験がある方であれば静止画では表現されていない「実はこうなる」

    プロトタイプに発生する溝と対処法
  • クックパッドにおけるAndroidエンジニアの役割とその変遷

    少人数1チーム体制時代から多事業部多人数体制時代までAndroidエンジニアの役割が変遷していくなかでチームが直面した課題とそれを解決する為に構築してきた開発プロセスや習慣、仕組みをお話します。すぐに導入できそうなものを中心に紹介します。

    クックパッドにおけるAndroidエンジニアの役割とその変遷
  • iodocsで便利なREST APIドキュメントを作成する - Qiita

    wikiとかでドキュメントを書くのが面倒で、良いツールを探していたらiodocsというnode製ツールを見つけた。 これを使うとドキュメント作成が楽になるだけじゃなく、 ドキュメント上のformからAPIリクエストを試せて便利っぽい。 普段APIドキュメントを見つつcurlとかでリクエスト送信して試してたのが、全てドキュメント上で完結して良さげ。 使い方 mashery/iodocsからcloneしてアプリを起動すると、FoursquareやLinkedin APIを叩くサンプルをすぐに試せる。redisが必要なのでserver起動を忘れずに。 ~/ $ git clone http://github.com/mashery/iodocs.git ~/iodocs $ npm install ~/iodocs $ redis-server & ~/iodocs $ npm start {

    iodocsで便利なREST APIドキュメントを作成する - Qiita
  • ソフトウェア開発の生産性を阻害する「気軽に聞けない」ことの考察と対策 - メソッド屋のブログ

    マイクロソフトの DevOps テクニカルエバンジェリストになる前から、ずっと不思議だったことがあります。 それは、「アメリカエンジニアの生産性の高さ」です。素晴らしいサービスは大抵彼らから生まれていますし、彼らを見ているとアウトカムも生産性も非常に高く感じます。 私は個人的にこの秘密を解く旅の途中にいます。私はインターナショナルチームに所属しているのですが、同僚と一緒に働いたり、ハッカソンをしたりして気づいた1つの仮説について共有したいと思います。 気軽に「聞けないこと」が生産性を阻害しているのでは? 以前私は「米国のエンジニアはコンピュータサイエンスを専攻している人が多くすごく優秀で、さらに英語が出来るので、技術収集するのも楽だから相当アドバンテージがある」と思っていました。 英語に関してはそうだと思いますが、彼らの個々の人がそんなに優秀かというとそうでもないことに気づきました。それ

    ソフトウェア開発の生産性を阻害する「気軽に聞けない」ことの考察と対策 - メソッド屋のブログ
    masayoshinym
    masayoshinym 2016/02/11
    同意するけど浸透させるの難しいと思うので、各職場に陽気な外国人一人ずつ配置して欲しい。
  • UIの議論は、必ず画面を見て絵を描きながらしよう! - Tortoise Shell

    先日、何気なくスライドシェアを見ていたら「ほんとこれ!」なスライドを見つけました。 UIの話は会議室でするな from Shingo Katsushima 上記のスライドでは、会議は無駄が多い、UIの話は席でする、問題をみんなの見えるところで話す…など、UIデザインをしていく上で重要な点がまとめられています。 その中でも、身を持って「ほんとこれ!」と常々感じていたことがありますので、今回はそのことについて書きます。 言葉って意外と伝わらないもの わたしは現在、仕事で自社WebサービスUIデザインをやっています。 Webサービスを開発していく上では、特にエンジニアやディレクターなど職種横断的なコミュニケーションが欠かせません。 なので、毎日のようにディレクターやエンジニアの方と議論をする場面があるのですが、プロジェクトが始まった当初はやり取りにとても苦労しました。 例えば、UIについて「

    UIの議論は、必ず画面を見て絵を描きながらしよう! - Tortoise Shell
  • クラウドワークスのエンジニアチーム - クラウドワークス エンジニアブログ

    心はプログラマ、仕事はマネジメントのつもりの安西です。 技術的なお話は他の皆様に任せて、今日はクラウドワークスのエンジニアチームのお話をしてみようと思います。サービス開発(というかソフトウェア開発自体も)は、複雑でしかも100%明確な答えが見えにくい世界です。日々答えの無い中の選択で、苦しくもあれば楽しくもあります(笑)。 そんな中で、どんな環境で進めているかを一部ご紹介してみます。 許可を求めるな謝罪せよ。 推奨している価値観です。どんどんやる。何か課題があればどんどん変える。 学習を推奨する:ポインヨ制度 個人があるいはチームが向上したり、やったことが無いことに挑戦するには、インプットを続ける必要があります。そこで、例えば勉強会開催、参加、講師などを行うことを点数(ポインヨ制度)化して見える化しています。 ところでポインヨって…? チーム開発(スクラム) チームで開発しており、開発プロ

    クラウドワークスのエンジニアチーム - クラウドワークス エンジニアブログ
  • プロダクトオーナーと開発者の兼任は可能なのか?

    こんにちは。@ryuzeeです。スクラムに関してオンライン上でお悩み相談を頂きましたので私見を述べたいと思います。 プロダクトオーナーと開発者の兼任は可能ですか?注意すべき点はなんですか? さて、この手の議論をする際にまず確認すべきは、スクラムガイドです。スクラムガイドには以下の記述があります。 プロダクトオーナープロダクトオーナーは、開発チームの作業とプロダクトの価値の最大化に責任を持つ。その作業は、組織・スクラムチーム・個人によって大きく異なる。 プロダクトオーナーは、プロダクトバックログの管理に責任を持つ1人の人間である。プロダクトバックログの管理には、以下のようなものがある。 プロダクトバックログアイテムを明確に表現する。ゴールとミッションを達成できるようにプロダクトバックログアイテムを並び替える。開発チームが行う作業の価値を最適化する。プロダクトバックログを全員に見える化・透明化

    プロダクトオーナーと開発者の兼任は可能なのか?
  • テキストに可読性、メンテナンスに優れた注釈を·Annotator MOONGIFT

    Annotatorはテキスト文中に注釈を付けられるソフトウェア。 AnnotatorはJavaScript/Python製のオープンソース・ソフトウェア。ブログをはじめとするテキストサイトにおいて、“ここ”にコメントしたいと思うことは多々ある。だが大抵文章の一番最後にしかコメントフォームがなかったりする。これではどこにコメントされたのかも分かりづらい。 説明を表示している所 やり方は幾つかあると思うが、自分の好きな場所にコメントできるとコメントされた側も分かりやすいのではないだろうか。そのようなシステムは論文においても有効だ。それを実現するソフトウェアがAnnotatorだ。 AnnotatorはJavaScriptフロントエンドを、バックエンドをPythonで実装した注釈管理システムだ。一つの文章内において分かりづらいと思える部分があればそこを選択して説明を加えることができる。説明は

  • 議論のフレームワークWowooを試してみた - Tbpgr Blog

    議論のフレームワークWowooを試してみました。 犬、 わうわう という名前みたい。かわいい。 Wowooとは? チームコミュニケーションの無駄を省くようにデザインされたオンライン議論をサポートするツールです。 その特徴をエレベーターピッチのテンプレートで説明してみます。 Wowooというサービスは、 オンラインで議論・ブレーンストーミングをしたい オンライン議論を必要とするもの向けの、 Webミーティングツールです。 ユーザーはオフラインのような議論ができ、 一般的なチャットツールとは違って、 同時発言可能、発言を木構造に管理するなど議論を理解しやすいBoardUIが備わっている事が特徴です。 現在はプロトタイピングフェーズとのことです。 その他詳しい内容は公式ドキュメントに記載されています。 medium.com ユーザー登録 Facebook, GitHub, Google+, Tw

    議論のフレームワークWowooを試してみた - Tbpgr Blog
  • デザインを「作業から仕事」にDMM.comラボが活用するプロトタイピングツール【後編】 | SELECK

    今回のソリューション:【Prott/プロット】 〜長くWebサイトを運営してきたDMMグループが、ネイティブアプリを開発するにあたり「Prott」を使ってデザイン業務を効率化した事例〜 デジタルコンテンツ配信、FX英会話、そして3Dプリントサービスに至るまで、幅広いビジネスを展開するDMM.comグループ。同社のクリエイティブを支えているのは、株式会社DMM.comラボ内にあるデザインチームだ。 もともと石川県からリモートで作業を行い、東京社からの依頼をこなす日々だった同チームを変えたのは、同社で取締役とデザイン統括を務める赤坂 幸雄さんだ。 「デザインはお化粧ではない」という思いを持って3年前に上京し、東京社にデザインチームを立ち上げた。今では上流工程からデザイナーの視点を取り入れる開発体制を作ることに成功したが、そこでまた別の課題にぶつかった。それは、ネイティブアプリのUI/UX

    デザインを「作業から仕事」にDMM.comラボが活用するプロトタイピングツール【後編】 | SELECK
  • 技術がわからないデザイナーやディレクター、プロダクトオーナーとのコミュニケーション - 特別天然記念物

    コミュニケーションのAdvent Calendar 16日目です。 みろなるさんがコミュニケーションのAdventCalendarやるから書いてって言われたので、つらつらと書いてみます。 今年春にSI屋さんをやめて、デザイン事務所のような会社で唯一の常駐エンジニアとして、アプリの技術なんかほとんど知らないWebデザイナーさんやディレクターさんとのコミュニケーションについて思ったことを書きます。 経緯 今年の春に2年務めたSIerをやめました(参考:退職しました)。 SIer時代には、基的にどこの現場に行っても周りはSEかPG。 お客さんもSEかPG。 エンドユーザーがSEなんて仕事も。 多々ストレスは有りましたが、話す方も聞く方もエンジニア。ある程度の共通の認識や知識を持ってコミュニケーションを取れることが多かったです。 そんな会社をやめて、今いる会社はWebデザイナーやディレクターがメ

    技術がわからないデザイナーやディレクター、プロダクトオーナーとのコミュニケーション - 特別天然記念物
    masayoshinym
    masayoshinym 2015/12/18
    何でこう上から目線なんだろ。エンジニアがみんなこうだって思われたら嫌だなぁ。
  • ペアプログラミングのコツ - komagataのブログ

    KRAYの@amachinさんにこう言われたので書きます。 うまいやり方を知りたいです。 ”ペアプロは疲れるけれど、コツが分かってくると、うまいやり方をすればとても有用だと知りました。” https://t.co/Ao7lVvmD8y — amachin (@amachin) 2015, 11月 30 実ペアプロ時間1年未満の僕がコツなんて言うのはおこがましいですが、ペアプロオンリーでやっているMediweb社さんのやり方の受け売りです。 1台のPCを共有しないペアプログラミングは1台のPCを使って交代しながらやるものですが、エディタの違いとか環境の違いをあわせるのはクッソストレスが溜まるのでやりません。EmacserとVimmerは一生わかりあえません。 かわりにラップトップを持ち寄って1台の外部ディスプレイを交代でつなぎます。(Thunderbolt Displayは電源も一緒になって

  • レビューしやすいコミット履歴でバグ削減 - Money Forward Developers Blog

    こんにちは。 アグリゲーション開発担当の中川です。 今回は、みんなが大好きな構成管理ツール「Git」について話したいと思います。 私は Git を使い始めてから、バグの発生数が激減しました。 Git を使ったとある手法によってレビューが充実し、バグの少ないコードを書くようになったと考えています。 では、今回はその手法について紹介したいと思います。 ※ 稿は Git 以外の第三世代構成管理ツール(Hg、Bzr など)にも適用するかと思いますが、Git の用語とコマンドを使って紹介していくため Git の基知識が必要となります。ご了承ください。 レビューしやすいコミット履歴と、開発の流れで自然にできるコミット履歴の乖離 以下のようなコミット履歴があるとします。 1. wip: 仕様変更○○を行い始めた 2. wip: 仕様変更○○の続き 3. wip: ちょっと設計を変更、それと過去のバグ

    レビューしやすいコミット履歴でバグ削減 - Money Forward Developers Blog
    masayoshinym
    masayoshinym 2015/11/30
    こういうの見るたび自分がGitを使いこなせてないのを実感する。。
  • スマフォアプリゲーム開発における問題と対策 その2 - Qiita

    上記のようにすれば、後からメンバーがどのタスクを処理したかは、担当者別でフィルタすれば確認できるので、振り返りにも便利です。 将来やるタスクが忘れ去られてしまう 忘れないために、実行する必要のあるタスクはすべてbacklog上にのせて、さらに将来の適当な日付をうって、backlogガントチャート上にのるようにしております。 これで忘れない!はず。 クライアントからサーバにエラーが起きていると言われるがどのようなリクエストを投げたかわからない よくあるのがクライアントがサーバレスポンスが原因で、アプリが落ちた(500とかがかえってきた)けど調べてくださいというパターンです。 デバッガからの報告などの場合もあり、どうしても時間差があるので、どのリクエストかわからなくなってしまいます。 ユーザIDをもらっても多くのリクエストから探すのは骨がおれます。 そのための対策としては以下が考えられます。

    スマフォアプリゲーム開発における問題と対策 その2 - Qiita
  • スマフォアプリゲーム開発における問題と対策 その1 - Qiita

    自分が関わっているスマフォゲーム開発で起こる様々な問題と、それをどのようなツールで解決しているのかを共有したいと思います。 同僚と話していたときに、他のチームがやっていて便利な事が共有されたらいいよねという話があったので、まず自分のチームのことから共有したいと思います。 pythonで開発していますが、どこでも起きうる一般的な問題が多いかなと思います。サーバのエンジニアをしているので若干サーバ視点です。 環境 クライアントはcocos2d-x サーバは python 2.7 + Django 1.8 クライアントはサーバにAPIで接続 サーバとクライアント開発は別グループ (それぞれ5人くらいずつ) ソースコード管理はgit 問題と対策メニュー 問題 対策

    スマフォアプリゲーム開発における問題と対策 その1 - Qiita
  • リモートワークでのコミュニケーションはGyazoを使いまくって会話している | リモートワーク - anywher

    今回は、スクリーンショットを共有できるソフトウェアGyazo( https://gyazo.com/ )などを開発されているNOTA Inc.代表の洛西氏にリモートワークの取り組みについてインタビューさせていただきました。 名前も住所も性別も知らない人と5年間一緒にリモートワークをしていた Kato: リモートワークをはじめたきっかけはなんですか? Rakusai: 10年以上前に紙copi( http://www.kamilabo.jp/ )というソフトを開発してまして、サポート掲示板を設けてたんだけど、掲示板が荒れたりしてですね。「あのバグどうなってるんや」とかユーザーがどんどんサポート掲示板で勝手にやり取りするなかで、特定の人がずーっとサポートしてくれるようになったんですよ。 Kato: 特定のユーザーがですか? Rakusai: そう。ずっと他のユーザーの質問とかに答えるようになっ

    リモートワークでのコミュニケーションはGyazoを使いまくって会話している | リモートワーク - anywher