早くしっかりユーザに価値を届けるためのチケットの書き方 - SmartHR Tech Blog
こんにちは。PM（プロダクトマネージャー）のhiroki_Mです。 年末調整を担当しています。趣味はお絵描きと虚無になることです。 2年前に私が公開した記事「スクラムをうまく回すために受け入れ基準をきちんと書く」が、現在も思ったより多くの方にご覧いただいていることがわかりました。 スクラムやアジャイルについては様々な記事が出ているものの、現場目線での実体験に基づく情報を得たい人は多いのかも、と思い、前回書いたものをアップデートした記事を書くことにしました。 この記事では、「早くしっかりユーザに価値を届けるための、チケットの書き方のポイント」をテーマに、スクラムをうまく回す※ために気をつけるべきチケットの書き方のポイントについて書こうと思います。 やりたいことと開発者をつなぐのがチケットです。開発プロセスをカイゼンしても、チケットがきちんとしていないと、その効果は表れづらいです。逆に、やりた
なぜかエンジニアをイラっとさせてしまう人の質問 - Qiita
はじめに 先日、新入社員の方から次のような相談を受けました。 「エンジニアの方に質問をすると、いつもイライラされてしまって辛いです」 ・・・・・・・・・ 確かに、エンジニアに限らず、質問をすることは非常に難しい… 質問の仕方を間違えたために相手を怒らせてしまった、なんてこともしばしばあることでしょう。 彼らは「教えるプロ」ではなく、ただの技術者です。 そのため、問題の解決には、質問力(コミュニケーション能力)が欠かせません。 そこで、新入社員の子には質問の仕方を教えようと思ったのですが… 僕「質問の内容・構成は悪くないぞ」 ※ここでは、あえて「良い質問」、「悪い質問」の違いには触れないようにします。 ※その手の話題はみんなすでに飽き飽きしているからです。 そう、質問の仕方は問題なかったのです。 しかし… 要所に気になる文言がいくつかありました。 -- 本記事ではうちの新入社員に限らず、プロ
19歳で転職した私が気づいた、すれ違わないチーム開発をするために必要なこと - SMARTCAMP Engineer Blog
こんにちは！！！スマートキャンプ、エンジニアの吉永です。 私は8月にスマートキャンプに中途入社し、今月で3ヶ月目となります。 前職では受託開発を主にした小さな企業に未経験で入社し、そこで一年間フロントエンド、バックエンド問わず開発したり、テックリードのような業務も行ったりしていました。 小さな会社なので部署というような区切りはほぼ無く、社長含め全てのメンバーがエンジニアといったようなエンジニア集団の環境で、日々開発タスクをこなしていました。 しかしある時期をきっかけに、外部の方と協力する機会が増え、エンジニアだけがいる環境から様々な人間が関わる環境へと変わっていき、とあるプロジェクトを進めている最中、私達エンジニアサイドと、企画サイド、デザイナーサイドでうまく噛み合わず、スケジュールが大幅に遅れてしまいました。 そして、このことをきっかけに私自身がエンジニア以外の人間に対して苦手意識を持っ
自分の書いたコードが他者によって書き換えられることにショックを受けてしまうひともいるって話「まずこういう感情を理解する必要がある」
irof @irof 自分の書いたコードが書き換えられることにショックを受ける人ってのはたくさんいて(もしかしたら多数派かも)、コードというかなんでもなんだろけど、「訂正」された、誤っていたと捉える。そもそも誤りでもないんだけど、仮に誤りだったとして、だからどうしたと、、、まだ掘らなきゃか。 2020-09-06 10:52:42
🔦「お気持ち会」で暗闇を払う - 弥生開発者ブログ
こんにちは、@mugi_uno です。気付いたら弥生社員になってました！！ プロジェクトの立ち上げはむずかしい Misocaチームで何かしらの課題に取り組む場合、基本的にはプロジェクト化して進めていきます。 その際、まずはインセプションデッキを作成して「目的やゴールは何か」「何をして、何をしないか」といったことを明文化し、メンバーで認識を揃える作業をします。 ですが、現実的にはそれ自体が難しいケースが存在します。 何から手を付ければいいのかわかりません！ たとえば 多種多様な立場の人が参加するプロジェクトを始めるが、メンバー個々人が何を重要視しているかを互いに知らない ○○について効率化したいけど、具体的に何が課題で次に何をすべきかが誰もハッキリとは見えていない 膨大なタスクが存在していて、どういった判断軸で優先順位をつけていけばいいのかがわからない みたいな経験はないでしょうか。 このよ
コードレビューで「違和感」という言葉を使わない - okuzawatsの日記
雑感です。カップ麺ができるまでに書き散らします。 コードレビューをする時、「違和感がある」というような言葉を使わないようにしています。「違和感がある」という言い方は便利なのですが、何がどうダメなのかを言っていないため、それをレビュイーに考えさせ、余計なコミュニケーションを取ることになる気がしているためです。 そのため、「違和感がある」というようなレビューをしそうになったときには、何についてどのような違和感があるのかを言語化して、具体的なコメントをするようにした方が良いと思います。 雑な例（適当に考えました）： before この処理をこのクラス内で行うのは違和感があります after このクラスの責務はhogefugaなので、この処理は新たにFooClassを作ってそちらで行うようにした方が良いと思います そろそろカップ麺ができるので、この辺で失礼します。
心理的安全性って結局何なんだろう
Event for Diverse Game Engineers #5 (https://edge.connpass.com/event/161663/)での登壇資料（からもろもろの画像などを取り除いたもの）です。
要件定義～システム設計ができる人材になれる記事 - Qiita
はじめに 株式会社デジサク がお送りするプログラミング記事、 今回は要件定義・システム設計について扱っていこうと思います。 プログラミングを勉強していて、こんな事を感じた経験はないでしょうか。 「勉強してもプロダクトが作れない」 「そもそも開発ってどうやるの？」 「要件定義ってなに？」 その悩みを解決するために、まずは開発の全体感を理解しましょう。 下図『ソフトウェア開発プロセス』をご覧ください いつも勉強しているプログラミングは 『実装』 の部分に該当します。 つまり、プログラミングの実力を発揮する前に４つも壁が存在するのです。 そのため、本記事では実装（プログラミング）を開始する前に必要となる、 『企画～設計』 について順を追って説明して行きます。 特に、エンジニアが理解しておくべき 『要件定義』『設計』 にフォーカスします。 なお、開発全体において実装（プログラミング）に使用する時間
コードの健全性: 礼儀正しいレビュー == 役立つレビュー
.app 1 .dev 1 #11WeeksOfAndroid 13 #11WeeksOfAndroid Android TV 1 #Android11 3 #DevFest16 1 #DevFest17 1 #DevFest18 1 #DevFest19 1 #DevFest20 1 #DevFest21 1 #DevFest22 1 #DevFest23 1 #hack4jp 3 11 weeks of Android 2 A MESSAGE FROM OUR CEO 1 A/B Testing 1 A4A 4 Accelerator 6 Accessibility 1 accuracy 1 Actions on Google 16 Activation Atlas 1 address validation API 1 Addy Osmani 1 ADK 2 AdMob 32 Ads
教えるという技術 | DevelopersIO
渡辺です。 自分は「教える」ことにやり甲斐を感じます。 大学時代を思い返すと、家庭教師やサポートセンターのバイトをやってました。 ボードゲームをする時は、ルール説明などを行っていました。 ゲームのインストの一環としてインストカードやサマリを作ることもあり、プレゼン資料作りも得意になりました。 IT業界に入ってからは、勉強会の講師や資料作成・ハンズオンのチューターなどを行うようになりました。 技術書の執筆やIT系専門学校講師も経験しています。 最近では趣味のスノーボードで、インストラクターの資格をとり、スノーボードスクールで教えています。 「教える」ことが好きなんでしょう。 これまで、様々な分野で技術を教えてきました。 畑はまったく違ったとしても、解りやすく「教える」ための技術は大きく変わりません。 今回はそんな「教える」技術をまとめてみました。 なお、本エントリーの対象は、その分野に初めて
1on1.md
1on1.md これは私が支援先に提供した、1 on 1 に関するノウハウや、思いを述べたドキュメントを元にしています。企業の枠を超えて共有したいことが多いので、ここに貼ります。 概要 世の中には 1 on 1 の本があるようですが、とりあえずは『1 on 1 で 何を話すのか？ マネージャ/ソフトウェアエンジニアの立場から - サンフランシスコではたらくソフトウェアエンジニア』を読んでもらえればよいと思います (higepon さんに感謝!)。 1 on 1 は 1 対 1 で話すミーティングで、基本定期的にやります。上長とメンバーとの間で行うのが基本です。 グループ/チームでのミーティングを補完するためのものです。 みんなの前では話しづらい、込み入った内容を話します。 チームとして行っているタスクの進捗確認に 1 on 1 を使うのは避けましょう。それは 1 on 1 の目的に沿ってい
バグについて謝るのはやめよう | Yakst
ハニー、見てくれよ。俺はテクノロジーを使ってるんだから 謝ってる時間なんてなかったよ THE STOOGES, SEARCH AND DESTROY この数年というもの、私が作ったもののバグについて謝るのを意識的にやめようとしてきました。 バグについて謝ろうという誘惑は強いものがあります。昔は自分も謝っていました。私の書いたコードのせいで、同僚の1日が台無しになってしまったり、ユーザに対する影響が出てしまった時には、「おっと、ごめんよ！そんなこと考えもしなかった」と言っていたものです。 この謝罪の動機はもっともなものです。あなたはチームのためにベストなことをしたいわけです。つまり、ほんのちょっと違ったやり方をしていれば、問題は防げたはずなのです。そう考えると、バグについて謝るのは害がないように見えます。しかし、次のような文化的なアンチパターンの原因になります。 ある人またはコードの一部を、
内向的な人でも実践できるデザインの伝え方
外向的な方が多い仕事現場 デザイナー以外の方たちへデザインを伝えるには、あやふやな表現の言語化がスタートになりますが、「ハキハキと前へ出て話をしましょう」という意味ではありません。一歩前に出て意見を述べることができる外向的な性格であれば良いですが、誰もがそうではありません。内向的な人が無理な行動をしてもかえって負担になるだけでなく、伝えるべきコトが伝わらない場合があります。 声が大きい人が多い場所、明らかに立場が上な人たちと意見交換をするのは至難の業。リモートでの情報共有はさらに難易度が上がります。ニュアンスをはじめとした非言語コミュニケーションが共有されていないと、どんどん取り残されてしまいます。内向的な方にガンガン攻めていきましょうというのは酷ですが、内向的であることを言い訳にして伝えることをしないのも良くありません。 思ったことをドンドン口にする人との会話は難しい。 自分のペースを設
このままでいいんだっけ？エンジニア面接官のレベル - dskst's diary
エンジニア採用が 重要!重要!! と言われる昨今、どの会社も採用活動に励んでいるかと思います。 私自身も面接官として日々面接をしているのですが、ふと思いました。 あれ？自分は面接官としてちゃんとできているのかな？ 最高のメンバーと働くために、企業の顔になる面接官はとても大事。 そして、合否も出しているというから面接官はめちゃくちゃ大事。 応募者が全力を出せるかどうかも面接官次第。 自分はしっかり向き合えているのだろうか。 エンジニア面接官という重要なものが、軽視されているのではないか？ エンジニア面接官のスキルを体得する機会は、少ないのではないか？ 面接官のレベルアップはどうやってしていけばいいのだろうか？ このままでいいんだっけ？自分よ。エンジニア面接官たちよ。 私が面接官になって今に至るまで 悩んだら誰とディスカッションするのか ということで「エンジニア面接官」コミュニティを作った 想
仕事で「技術的には可能です」と言うと「可能ならやってください」と言われてしまうので誰にでも分かる表現を考えたい
uni1000yama1000 @uni1000yama1000 「技術的には可能です」というのは、「普通はやらないし、やろうとしたら非常に困難を伴うので諦めてください」という意味なのだが、「技術的に可能ならやってください。保証もしてください」となってしまう。もっと誰にでもわかる表現を考えないといけない。 2018-08-11 12:56:50 きゃたつ @kyatatsu これ、ほんまそうなんよなー 技術者的には「できるのにできませんって言うのは技術面で無能に思われるので悔しい」って感情があるから、「技術的には可能」って言い方するのに、ユーザーは「あ、できるんだったらお願いします」だもんなあ…この溝を埋めるの難しいよなあ twitter.com/uni1000yama100… 2018-08-12 11:15:08
エンジニアから非エンジニアに歩み寄る方が捗る - Konifar's WIP
非エンジニアのメンバーと話していると、 なんだかもどかしい気持ちになることがあります。 なんか話が噛み合わないというか、すごく他責な言い方をすると 「もっと開発のこと理解してほしいなぁ」と感じてしまう時があるんですよね。例えば、難易度の高い修正をさらっとできそうな感じで話されたりとか、逆に超簡単なのに難しいと思って遠慮されてたとか。そういう認識の違いから来るもどかしさです。 最近、このもどかしさを解消するには エンジニアから非エンジニアに歩み寄る方がいいなぁと思い始めたので、考えをまとめてみます。 相手の立場に立って考え直す このもどかしさ何とかならないかなぁと考えていた時に、 SHIROBAKO 17話『私どこにいるんでしょうか…』を見ました。 anicobin.ldblog.jp この回では、新人制作の佐藤さんがアニメーターの遠藤さんにちょっとキツいスケジュールの仕事をお願いし行くシー
コードレビューを会話しながら行う取り組み - Hatena Developer Blog
こんにちは。アプリケーションエンジニアの id:itchynyです。 今回は、コードレビューを会話しながら行う取り組みについて紹介します。 コードレビューは大事なコミュニケーションの場です。 コードレビューの効用としては、単純なミスがあるコードをリリースしない・プロダクトのコードの品質をよりよくしていく、あるいはその方策を模索するといったことが挙げられます。 こういったことは当然のことですが、なによりもまず、レビューというのは一緒にプロダクトを作っている仲間とのコミュニケーションの場だと思います。 多くの人は、プロダクトのコードをよくしていきたい、読みやすいコードを書きたい、分かりやすいコードで目的の機能を作りたいといった共通の思いを持っていることでしょう。 コードを書いた人の思いを汲み取りながら、共感したり、譲歩したりしながら、よりよい方法を提示していきます。 それでも時には、どういうコ
「工数一日」は「明日できる」じゃない！エンジニアと非エンジニアのギャップとは - paiza times
Picture by ITエンジニアを目指す女子高生たちの学園ライフ4コマ漫画『ぱいじょ！』 こんにちは、谷口です。 ディレクターやプロジェクトマネージャーといった非エンジニア職の方々は、エンジニアとコミュニケーションをとることに難しさを感じたり、考え方にギャップを感じたりしたことがある方もいらっしゃるかと思います。 「エンジニアとわかりあえない…」「エンジニアが何を考えてるのかわからない…」という方のために、エンジニアとのトラブルのもととなるやりとりや、気を付けるとよいことを考えていきますので、非エンジニアの方々の参考になればと思います。 ■「どれくらいでできる？」はその場で決められるものではない 非エンジニアとエンジニアのもめごとの原因で多いのが、スケジュールに関することです。 非エンジニア「この機能どれくらいでできる？」 エンジニア「一日でできます」 非エンジニア「じゃあ明日リリース
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
お前たちの仕様の伝え方は間違っている！
自分の経験を言語化すると、周りの人に良い影響を与える 松本亮介様〜（Forkwell Portfolio スペシャルインタビュー） - Forkwell Press