初心者エンジニアにおすすめしたい「進捗どうなった？」と言われないための仕事の進め方 - Qiita
はじめに 初心者エンジニアのあなたは、 **先輩エンジニアに「進捗どうなった？」や「なんでこの作業にこんな時間かかってるの？」**といったことを言われたことはありませんか？ また、 作業見積もりやタスク分解をちゃんと行なわないで、いきなりコードを書き始めているということはありませんか？ 勝手にコードを書き始めて、ほとんど手戻りになって1からコードを書き直しになるという経験もあるかと思います。 僕は徹底的に仕事のやり方を叩きこまれましたが、周りの話を聞いていると、こういったことができていない人もいるのかなと思い書こうと思った次第です。 またエンジニア向けには書いていますが、どんな仕事にも普遍的に使える考え方だと思っているので参考になれば幸いです。 アジェンダ 以下のとおりです。どこから読んでもらっても大丈夫ですが、上から読んでいったほうが流れが分かりやすいと思います。 ツールはGithub,
【保存版】スクラム初心者でも5分で総おさらい！スクラムの超重要単語と導入方法
スクラムの導入は、わからない事が多くて知っている人がいないと導入が難しいという意見をよく聞きます。そこで、ステップバイステップで手順に沿って実施していくと、スクラムの導入がある程度完了していることを目指す説明をしたいと思います。 > スクラムとは?スクラムとは? スクラムはアジャイル開発手法の1つで、スクラムは「柔軟かつ全人的なプロダクト開発ストラテジーであり、共通のゴールに到達するため、開発チームが一体となって働くこと」とされています。スクラムはフレームワークであり、スクラムガイドというスクラム標準の定義もあります。 > 大事な用語大事な用語 スクラムを実施するに当って、スクラムの文脈で頻出する用語の定義を説明します。 > 役割に関する用語役割に関する用語 【プロダクトオーナー】 プロダクトオーナーは、そのプロダクトについて何をどの順番で作るのかについて責任を持っています。 【スクラムマ
Slackで簡単に「日報」ならぬ「分報」をチームで実現する3ステップ 〜 Problemが10分で解決するチャットを作ろう
Slackで簡単に「日報」ならぬ「分報」をチームで実現する3ステップ 〜Problemが10分で解決するチャットを作ろう〜 開発プロジェクトを進めていくと、チームは様々な課題に直面する。こうした課題は、週次のミーティングや日報で共有して解決していくことが多い。 課題は大小様々だが、特に数時間で解決できるような小さな課題をいかにリアルタイムで解決していくかで、チームのスピード感が大きく変わってくる。 僕のチームでは、リアルタイムの課題解決の為に、社内チャットSlackを社内Twitterのようにする邪道な使い方「分報」という取り組みを実践している。 > 日報の弱点日報の弱点 日報は一日の業務の報告書で、一般的に「進捗状況」「体験」「学習」「課題」が記載される。これらをチームで共有することで暗黙知を減らし、個人とチームを成長されることが目的だ。報告方法はチームによって様々だが、メールをはじめ、
デザイナーがXcodeを使って 開発効率をUPさせた 5つのエピソード + 現場エンジニアのコメント付き
非エンジニアリング脳なデザイナーが新規アプリ開発の現場でXcodeを使用することがどのような影響を与えたか。について、自身の経験を元にまとめました。
イカしたエンジニアになるためのイカしたコミットメッセージ - mmyoji's diary
2015-10-16 イカしたエンジニアになるためのイカしたコミットメッセージ Git 今お仕事させていただいている会社で、以前 【コミッター登壇】プログラマーのための「Rubyの世界」 - connpass で登壇された @idesaku さんとも一緒に働かせていただいてて、今日ありがたいことにマンツーマン(死語?)でgitのコミットメッセージについて講義をしていただいて、それがめちゃめちゃよかったのでブログに残しておこうと思います😊 commitメッセージに関する記事などを以前色んな人が書いてるのを見た気がしますが、個人的な経験として今日得られたのがインパクト強かったので、多少被ったりはしているかもしれませんが、そこらへんはスルーしてくださいmm 経緯 僕のPull Requestに付くコメントが毎回コード自体というよりは commit に関することばかり 「このコミットメッセージは
超速で開発・リリースするための6つのこと - Cybozu Inside Out | サイボウズエンジニアのブログ
「サイボウズ・アドベントカレンダー」の8日目です。ちょうど真ん中まできました（これまでの記事一覧）。 こんにちは。kintone 開発チームの刈川です。いきなりですが、皆さんはどのくらいの頻度でアプリやサービスをリリースしていますか？ 1週間？ 1ヶ月？ 1年？ 規模によると思いますがクラウドサービスではリリースのスピードが大事です。せっかくいいアイデアを思いついたのに、それを実現するまでに果てしない時間と労力がかかるとしたら…。ユーザの意見を取り入れるまでに半年も一年もかかっていたのでは、ユーザは他サービスに移ってしまうかもしれません。そこで今回は、私たち kintone チームが取り組んでいる「スピーディな開発・リリース」のための手法を簡単に紹介したいと思います。 アイデアを形にする アイデアというのは形にするまでがゴールです。開発現場ではこのことをリリースと呼び、リリースをするまでに
githubの運用戦術 - Qiita
前提 過去のチームといまのチームでどうやっているかの話 master以外なら force push 可能なことが条件 コミットコメント 一行で概要 WhyやHowを書かせる。 WhereやWhatはいらん、diffを見ればわかる。 (必要なら)詳細 なんでここにこういうことをした？ という細かい説明。 時間に追われてdirty hackをせざるを得なかったのならここにも書いて欲しい。 書かずに変なことしたら俺がハリセン issueだのメモだのへのリンクでもいい 諸注意 日本語OK 英語オンリーにするとみんな面倒臭がって little change for debug とか平然と入れる 詳しく書かせたいし読むのに苦労したくないので日本語を許す コミットのタイミングと粒度 粒度はできるだけ細かく。 １コミット単位でレビュワーがお前何がしたかった？をみるため。 レビュー中にレビューが入った部分は
進行中のデザインをクライアントも私もあれこれコメントつけあいながら確認できるサービス
クライアントさんに進行中のデザインを確認してもらうとき、どーしてます？ メールで画像を送る。確認してもらったあと、修正の要望をまたメールで返信してもらう。やっぱりこれが一番多いのかな。で、互いにうまく理解しあえない箇所は電話で詰めるという感じで。 本当は、クライアントさんもデザイナーさんも肩を並べて確認しあえたらベストなんですけどね。横で一緒にデザインを眺めながら、「ここをこういうふうに」「いやここはこういう意図があったもんで」なんて言い合いっこしながら進められれば、意思の疎通に苦しむことは、少なくなるでしょう。同じ箇所に対して、「ちょっとよくわかんないんだけど」とか、なんどもメールやメッセージのやりとりをすることからも解放されます。 でも、そんなに毎度顔を合わせた確認作業ができるわけなくて。クライアントさんも忙しいでしょう。もちろんボクも。そもそもネットと電話の回線だけで案件を進めるとい
朝Lint活動で細かな技術的負債を返済する - クックパッド開発者ブログ
買物情報事業部の八木です。クックパッド特売情報のAndroid部分を担当しています。普段はクックパッドのAndroid版（以後、本体アプリとします）の開発プロセスの中で特売情報の機能を開発しています。 本エントリでは細かな技術的負債を解消する為に本体アプリの開発チームが行っている朝Lint活動を紹介します。 2年近く経つ本体アプリのコードベース 私が買物情報事業部に所属する前は本体アプリを1から書き直すチームで働いていました。書き直し始めたのは2013年10月からなのでそろそろ2年が経とうとしています。2年前に設計された本体アプリは現在ではおよそ17万行を越え、日々どんどん変更が加えられています。 それらの変更の中には残念ながら悪いコードが含まれている場合があります。テストしづらいコードやテストがないコード、レビューに対する場当たりな対応や緊急のbug fixのために追加された汚いコード、
githubの特定ブランチへのgit push --forceをprotectしてエンジニアの精神崩壊を防ぐ( ꒪﹃ ꒪)ﾌﾞｸﾌﾞｸ - Qiita
githubの特定ブランチへのgit push --forceをprotectしてエンジニアの精神崩壊を防ぐ( ꒪﹃ ꒪)ﾌﾞｸﾌﾞｸGitGitHub Protected branches and required status checks もうお済みですか！？ 9月4日のことですがgithubより以下の機能がリリースされています。 特定ブランチへのforce pushを無効する 特定ブランチへのマージ時にステータスチェックを必須にする(CIと連携している場合は、テストが通るまでマージできないようにできる) これを実施することで、ある日新人が謎の空のコミットをmasterブランチにforce pushして来たり、ある日途中からJOINした人がpull reqもせずにdevelopブランチに謎コミットをforce pushして来たり、ある日とあるOSSで間違えて一ヶ月前のローカルレポジト
ノウハウの共有文化がない場所にコードレビューをねじ込んでみた結果とか - タオルケット体操
「コードレビューをキメると品質も上がるし自分のレベルも上がるので最高」みたいな論が巷を賑わせていて、以前はそういうイケてる制度を指をくわえてみるのみだったのだけれど、最近職場と、それと個人的に関わったプロジェクトでコードレビュー制を無理矢理交渉して導入してみた結果、世間のイケてる書籍やエントリから得られる情報とはまた少し違う知見が得られたので書いてみる。 割と泥臭かったり、あまり希望に溢れてたりはしない感じのエントリなのでそういうのは期待しないほうがいいです。 準備 些末なコードレビューを極力避けるために、コードの規約やスタイルについてはlintとフォーマッターを用意した。 他は無策。 結論 結論から言うと、理想的な運用は出来なかったものの、コードレビューについて世間で言われるような成果（作業を共有する意識、レベルの向上）は得られた。良かった。 ぶっちゃけ僕なんかが浅はかな考えで導入しても
Gitコミットメッセージの7大原則 - rochefort's blog
タイトルは大げさです。割と当たり前の話です。 ハードディスクの整理中にRailscastsのメモが出てきまして 懐かしいなぁ、 Ryan Bates(@rbates)さん 元気かなぁと Twitterを覗いてみたところ How to write a Git commit message: http://t.co/D31dVh1lks— Ryan Bates (@rbates) 2015, 7月 28 なかなか興味深い記事をtweetされていました。 Git の commit messageに 規律をもたらそうぜ、ってのは どうやら日本人だけじゃないようです。 元記事( How to Write a Git Commit Message ) Introduction 著者の過去と現在のcommit logを対比しています。 一貫して、この緑と赤の対比が見やすいので、記事も読みやすいです。 ま
オレの理想の組織
2015/08/27 22:00 「 サービスがある程度完成してるクッ○○○○にエンジニアが居ついている理由も興味ある 」 サービスの大まかな形ができあがるとエンジニアは新しい何かを求めて辞めてしまうことがあると思っているので、ふと不思議に思いました。 ※念のため言っておくと今自分が属しているエンジニアチームはサービス立ち上げ前から1人も辞めていません（もっといえばその前の動画共有サービスを旅する元AWSエバンジェリスト？から 押しつけられて もとい、引き継いで以来6年間誰も辞めていません。あくまでも現時点では…だけれども）。 理由も とあるのはもう一つ興味のあることが同時にあって、 「 あれ？D○N○ってフラット組織なの？あの規模でどうなってるのか興味ある 」 上意下達というか、上司がいて部下へ仕事を振っていく組織は、上司がふたになってしまって良くないと思っています。とは言っても、各プレ
プログラミングスタイルガイドのスタイルガイド - Qiita
本文書は、プログラミング言語向けのスタイルガイドに向けたスタイルガイドである。 本文書へのフィードバックはQiita上のコメントにて受け付ける。 構造 対象を明確にする そのスタイルガイドがどのような状況のどのような対象に向けたスタイルガイドであるか規定すること。 状況や対象は広すぎてはならない。 理由: 対象はスタイルガイド記述者には自明かもしれないが、似て非なる言語に誤用されたり、特定分野のアプリケーション向けスタイルガイドが他分野のアプリケーションを理不尽に拘束したりすることがある。これを防ぐべきである。 良い例: 「本文書はRuby on Railsアプリケーション向けのスタイルガイドである」 「本スタイルガイドはX社におけるRubyプロジェクトに適用すべきスタイルを規定する」 悪い例: (何も書かない) 「本文書はX社におけるすべての開発に適用される ... 述語メソッドや述語関
スクリーンショットにコメントをつけてシェアできるツール
2017年11月23日 便利ツール Webサイトに修正指示を出す時、どんなツールで、どのようにシェアしていますか？該当ページのスクリーンショットを撮影し、その画像に指示を入れていく…という方が多いかな、と思います。今回はWebサイトの制作者のみならず、制作者に指示をだす人や、クライアント側も使える、修正指示がグンと楽になりそうなツールをいくつか紹介します！ ↑私が10年以上利用している会計ソフト！ AUN[あうん] AUN[あうん]はふせん紙の感覚でWebサイトや画像にコメントを残し、共有できるツールです。登録不要！無料で気軽に利用できるところが魅力的。対象となるWebサイトのURLを入力するだけでスクリーンショットを撮影でき、指示やコメントを残していけますよ。さっそく試してみましょう。 サイトからURLを入力し、読み込みが終わると、画面をトリミングするかどうかの選択画面が表示されます。読
コードの品質を維持したまま開発スピードを上げる | POSTD
高品質のコードベースは、反復作業やコラボレーション、メンテナンスを簡単にすることで、長期的な開発のスピードを上げてくれます。Quoraではベースコードの品質は重要だと考えます。 高品質のコードを維持することは利点がありますが、その反面かなりのオーバーヘッドが発生し、実際の開発のサイクルに時間が掛かってしまいます。このオーバーヘッドと利点の折り合いを付けるのは難しい問題です。この場合、2つの選択肢しかないように思えます。低品質でコードスピードが速いか、もしくは高品質でスピードが遅いか。スタートアップは素早い開発サイクルに最適化しているので、多くの人は低品質で進めたほうがいいと思っています。 このジレンマは解消できます。ツールやプロセスを工夫することで、コードベースの品質を維持したままスピードを速めることができるのです。この投稿では、コードの品質に関しての私たちの考えや、2つの世界を共存させる
人を使うということのオーバーヘッド | タイム・コンサルタントの日誌から
なんだかひどく忙しい。そう、あなたは感じている。やらなければならない仕事が山のようにたまってしまった。このままでは期限までにアウトプットが出せそうにない状況だ。自分の下に誰かつけてもらって、やるべき仕事量を分担して進めるしかない。 あなたは上司に窮状を訴え、一時的な手助けのために、なんとか若手を一人つけてもらえることになった。この部に入ったばかりの、まだ右も左も分からない新米だ。しかし贅沢を言っていられる状況ではない。周りも皆、忙しいのだ。儲かってもいないのに、ウチはなぜこんなに忙しいんだ？ あなたは独り言をつぶやきつつ、そもかくその新米を席に呼ぶ。頼みたい仕事を説明するためだ。 頼む仕事は、比較的単純だ。あなたが作ったExcelシートに条件の数字をインプットして、何種類かケーススタディをしてほしい。あなたは、ある案件の原価と収支を計算して、売価や条件を関連部門に連絡しなければいけないの
現場改善でハマる罠 | GuildWorks Blog
ギルドワークス 前川です。 ギルドワークスでは、様々な現場に入り込んで現場改善を行っています。もちろん皆さんの現場でも、様々な改善が試行されているのではないかと思います。そんななかでハマりやすい罠について、今日はお話します。 改善をリードする立場とされる立場の間の意識ズレ あなたが現場改善をリードする立場だった時、あなたの頭のなかには、それが最高にうまく行った場合のバラ色の未来が思い浮かんでいることでしょう。 しかし、改善というのは大抵、即効性のある効果があるものではありません。これまで慣れたプロセスを変えてしまったら、どこかで不慣れによる作業効率の低下や、手順が変わったことによるミスなどがでてくるでしょう。 あなたにとっては、それは改善の効果が出るまでの一過性の痛みに過ぎません。しかし、他のメンバーにとってはどうでしょう？ 「いらんことをされて、面倒くさくなった」と思われていませんか？
チームにとってのリーダブルコード - pixiv inside [archive]
株式会社クリアコードさんにご協力いただき「リーダブルコードワークショップ」が行われました。 ピクシブ株式会社からは7名、永和システムマネジメントさんからは1名が参加した合同ワークショップです。 このワークショップを通して、 通常のレビューでは良くない部分ばかり見てるけど、良い部分も共有しよう。 コミットメールを受信して、push式でコードを読む習慣をつけよう。 といった、チームにとって読みやすいコードを書くための方法を実践形式で学びました。 その詳細についてご紹介します。 ワークショップ開催までの経緯 SEゼミにてクリアコード須藤さんから弊社リードエンジニアedvakfにワークショップについてのお話をいただき、人数や構成などが対象として適しているチームが弊社にあったため話が進んでいきました。 そのチーム(BOOTH&pixivFACTORYチーム)では 開発メンバーの入れ替わりによってベテ
![チームにとってのリーダブルコード - pixiv inside [archive]](https://cdn-ak-scissors.b.st-hatena.com/image/square/25ec32188ad8eb3043bc5cb87cb9e23fc5409184/height=288;version=1;width=512/http%3A%2F%2Fcdn-ak.f.st-hatena.com%2Fimages%2Ffotolife%2Fm%2Fmoyashipan%2F20150811%2F20150811174853.png)
あなたと働くエンジニアの人生を最悪なものにしないために – デザイナーのための3つの提言 | POSTD
それとも、”私はデザイナーなので、そんなことを知る必要はありません”と言い張るのか 私の職業はデザイナーです。私はエンジニアが好きです。ちょっと度が過ぎるくらい好きかもしれません。以前、Facebookの グループ に参加した時、かなり前からチームのメンバであるiOSのエンジニアと初めて話して、口から泡を吹いたことを思い出します。私はその時、これまでに自分がObjective-Cでコーディングしたものについて、勢い込んで話し始めました。まるで、高校の新入生が、上流階級の生徒に対して、自分が付き合う価値のあるカッコいい人間だと証明しようとしているみたいだと感じました。 デザイナーの多くが、エンジニアとの話し合い方を実はよく分かっていないと思います。もちろん、デザイナーはエンジニアと話しますが、本当の意味で関わろうとしていません。この記事を書いた理由はそこにあります。ソフトウェアエンジニアの懸
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
