はじめに 昨今「開発生産性」についての話題をよく目にします。 生産性が向上することで悪いことは無いので、様々な組織の事例が公開されて業界全体に知見が共有されていくことはとても素晴らしいことだと感じています。 話題のこちらの本 「世界一流エンジニアの思考法」にもとても大切なことが書かれておりますし こちらの記事も参考になりました。 それらを踏まえて個人的に生産性向上のベースになる大切なことだと思っている 「即レスの大切さ」 について書きたいと思います。 これまでやってきたお仕事 ツールアプリの新規事業責任者(3年ほど) 全体3名の少人数チームでスタート 私(責任者+PdMの役割)、エンジニア1名、デザイナー1名 最終的には30人前後の組織の事業部長 ゲームアプリのマーケティングマネージャー(5年ほど) 組織全体としてはビジネスサイド20名、エンジニア5名、デザイナー5名ほど 会社経営(4年ほ
新人が1on1に来ない。その原因を考察する。 ここで出てくる新人の情報は以下である。 年齢: 30代前半 エンジニア歴: 5年 入社して半年 1on1を行うに至った経緯: 1年前、私と同じ時期に入社した同期Aが退職した。 詳細はよく分からないが、どうやらチームの先輩の1人と相性が悪いとの事だった。 尚、Aが退職したのは上記の理由だが、退職したいからこれを名目上の理由にしているのであって、原因は他にある可能性はあるが、この際それは考慮しない。 会社の人員構成: ほとんどがエンジニア歴10 ~ 20年のベテラン。平均年齢は30代後半。 Aは30代前半。 周囲の反応: Aが退職を告げた時、周囲はうろたえた。事前に相談は無かったし、特に問題はないように思われていた。 何より30過ぎた社会人は、問題があれば自分から話して来るという思い込みが、既存社員にあったもしれない。 年齢は関係あるか: ないと考
私は決して世界レベルで優秀なエンジニアではない。ただ、幸いなことにグローバルに活躍するエンジニアの方々と一緒に仕事をする機会には恵まれてきた。 エンジニアとしてだけでなくビジネスマンとしても、彼らからたくさんのことを学ばせてもらってた。 今日は彼らから学んだ成長するための立ち回りについて紹介しようと思う。 質問力が高い彼らと働いていて驚かされたことがある。 それは「これほど優秀な人がこんな基本的なことを質問するのか?」という場面に何度も出くわしたことだ。 知らないことが罪のように感じていたグローバル人材と働く前はゴリゴリの日系Webベンチャーで働いていた。その際は、簡単なことを質問することに対する抵抗感が大きかった。 「基本的なことを聞いてしまって申し訳ないのですが。。。」といった言葉を頻繁に聞いたことはないだろうか? これは私だけかもしれないが、日本コミュニティにいると基本的なことを知ら
お力になりたいです。回答を得るチャンスを広げるには、以下のヒントを参照してください。 検索して 調べる ...そしてわかったことの記録を付けます。このサイトの他の場所で役に立つ回答が見つからなくても、役に立たなかった関連するシステムのリンクを含めることで、あなたの質問が他のものとどう違うのかを他の人が理解するのに役立ちます。 具体的な問題をまとめたタイトルを書く タイトルは、回答者になるかもしれない人が最初に目にするもので、タイトルが興味深くなければその続きは読みません。だから、有効なものにしてください: 忙しい同僚に話しかけているつもりになって、質問全体を 1 つの文にまとめなければならないと想像してください。他の人が問題を特定して解決するためにどのような情報を含めたらいいでしょうか。エラー メッセージ、重要な API、またはあなたの質問がすでにサイトにある同様の質問と異なることを示す、
背景 開発チームが抱えるよくある課題として システムが変化する一方でドキュメントは更新されず腐る メンバーの流入出によって口伝でかろうじて継承された知見も失われる 検索性が良くないと過去のドキュメントが気づかれず、同じような内容のドキュメントが新規量産される 後から参加したメンバーはどちらが正のドキュメントか分からず混乱する といったことが良くあります。 解決方法としては以下のように、GitHub&ルールベースで管理するといった例があります。 future-architect.github.io また組織・システムが大きくなってくると認知負荷を低減するためにドメインで区切るような形でチームの分割が始まりますが、 異なるチームによってシステムが管理され、システムの依存関係を全て知っている人がいなくなる CxOレイヤが大規模イベント前に現状を把握したいときに都度時間がかかってしまう チームごと
前書き プログラミングで一番難しいところの一つは、「見積もり」だと私は思う。人から頼まれてプログラミングをする時、必ず最初に聞かれるのが「だいたいどれくらいで終わるか?」だ。厳しいところだと「何日に納品してくれるのか?」を問われる(むしろこれが普通かもしれない)。まっさらな状況から過去の経験を総動員してかかる時間を予想したり、可能な限りタスクに分解して時間を見積ったりするが、いつも不安に駆られる。多くの人も、見積もりに対して困難と不安を感じているのではないかと思われる。見積もりに対する自分の知識と経験を話して他の人にも参考にしてもらいたいと思って記事を書いた。 見積もりという言葉には色々な意味を含むが、今回の記事では「プロダクトをリリースするまでの期間の見積もり」から「頼まれた一つの機能の完成させるための期間の見積もり」までのスコープで話をしたい。 なぜ見積もりをしないといけないのか? 見
「コードレビュー・・・うっ頭が」となっているそこのアナタへ。 先週弊社キカガクで人生初の実務コードレビュー体験をしました。 控えめに言って最高すぎました。 お互いが「気持ちよく・効率的に」学びを深められるように組まれた一級品のレビュー構成。 細部に渡る心遣いとテクニックの為せる技だと思いました。 そこで私は考えた ー。 真逆のことをしたらどうなるんだろう? 想像してみたらなかなかブラックな開発環境が脳内で出来上がりました (大学時代のコードレビュー現場そっくりだなと思ったのは内緒)。 自分がコードレビューに参加する時こうはなるまいぞいう戒めを込めて紹介していこうと思います。 具体的な改善案も5選紹介しています。 共に愛され系コードレビュアー & レビューイを目指しましょう! 想定している対象読者 「もうすぐ初めてコードレビューを受ける予定で不安・・・」 「コードレビューを行うことになったけ
正直に話してくれたが、日本の時給の決め方は「どんぶり勘定」「その時の経営者の気分」「人を見て決める」「周りに合わせる」が横行してきたのは事実だろう。厳正な人事考課とは名ばかりでそれこそ「さじ加減」「お気持ち」で決めてしまう。人事評価の不満要因が「基準の不明確さ」であることは多くの労働者アンケートでも上位だが、この国の永遠の課題(というか多くは直す気がない)のままではないかと思わされる。 群馬ではないが、筆者の元教え子でアルバイトをしている男子大学生にコストコの話を振る。 「コストコ、近くにあったら土日だけでも入りたいですね。時給が高くて透明性がある、それが一番じゃないですか。働きやすさとかはわかりませんが、どっちにしろ、日本は時給が安くて仕事環境も悪いバイトばかりですから」 この国のアルバイト不足は深刻だ。とくに飲食業と小売業は重症で、コロナ禍も明けたかに思われた矢先、人手不足による時短や
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く