エンジニアのための最小コミュニケーション術 - Qiita
はじめに こんにちは。元ガチプログラマーのプレイングマネージャです。 できれば、プログラムをカタカタ打ってPC画面に向かって「いい感じのコードを書いちゃったなぁー」と独り言だけを言っていたい人間だったのですが、それだと仕事にならないなあと。 ということで最小限のコミュニケーションで仕事をする方法について考えたことをまとめておきたいと思います。 最小コミュニケーション術 『プロジェクトのゴールに対する』自分や相手の課題を解決できるようにコミュニケーションをとることが、コミュニケーションを最小にする方法と考えます。 相手の課題を解決するために自分となんらかの調整が必要なケースでは、相手の課題が解決するまではコミュニケーションが継続されますし、自分の課題についてもまたしかりです。 相手の質問の裏には、相手のプロジェクト上の課題が必ず存在します。相手の質問にそのまま答えても相手の課題が解決しなけれ
「戦わずして勝つ」というより、むしろ「戦ったら負け」なのだと気づいた。
職場で妙にうまく自分の意見を通す人がいる。最近この人から本当に大切な事を学んだので、今日はそれについて書こうかと思う。 人間というのは面白いもので、同じことをやっても好かれる人と嫌われる人がいる。 貴方も「言ってることは正しいかもしれないけど、それにしてもコイツ、酷い言い方するなぁ」と思った事が一度や二度はあるだろう。 俗に言うところの「口のきき方に気をつけろ」というこの現象の正体が自分は本当に長い間よくわからなかった。そもそも「口のきき方」って単語自体が、なんか曖昧で要領を得ない。 そういう事もあって、冒頭に出した自分の意見を上手に通し続ける人が不思議で仕方がなかった。 ぶっちゃけた事をいうと、彼はそこまで人間的に魅力があるようにはみえなかったし、何かカリスマがあるような人でもない。 決して口ベタではないが、上手くも無い。 しかし気がつくと周囲とは軋轢を作らずに事を推し進めるのである。い
スタートアップの仲間に入れてはいけない“ヤバい人”の特徴 どこにいっても活躍できる人の「結果」と「プロセス」の考え方
良い仲間作りでは「自分が人を助ける機会を多く持つ」こと 澤円氏（以下、澤）：では最初にいただいた質問の中で、一応これに答えておこうかな。 「仲間が大事というお話の流れで良い仲間作りで重要なのは、頼ること以外ではやはり自分自身がスキルや志を高くすることが必須ということでしょうか？ 私もできないことを伝えることは、プライドもあったり周囲の期待に応えたくてなかなかできないです」ということなんですが、このへん、どうでしょうか。 助松裕一氏（以下、助松）：助松、答えていいですか？ 澤：もちろん、もちろん（笑）。 助松：今ふと思いましたけど、その時必ず向こうも私の何かを期待している。要はお互いの強みを意識しながらシェアし合ってたんでしょうね、今、気づきました（笑）。 澤：シェアし合うことによってお互いが補完したり補強し合ったりできると思えるから、組む選択肢になるんですよね。 助松：そうです、たぶん無意
理想のリーダー像を言語化してみました。 - Qiita
チームで仕事をすると、リーダーが必ずいます。経験や実力のある人が担うことが多いように思います。今回は、いろんな書籍や記事などをもとにして、どんなリーダーが理想的か考えてみました。 リーダーについて思うこと ①【前提】チームはリーダーで決まる リーダーって、チーム内のミーティングで発言回数が一番多く、影響力が大きい存在です。だからこそ、チームメンバーに良くも悪くも影響を与えるものです。例えば、リーダーのコミュニケーションの取り方は、メンバーの相談しやすさを左右します。 また、スケジュール管理/進捗管理もリーダーが行うので、タスクの品質やスピード感もリーダーの個性や能力が反映されます。例えば、どんな観点でどれだけ細かくチェックするのかはリーダーの考え方で変わります。結果として、（要件は最低限守れたとして）成果物の品質が高いか、低いかの分岐点になるような気がします。 故に、チームはリーダーで決ま
エンジニアとして機械学習に携わった際にやっててよかった3つのこと - Lean Baseball
現職のコンサルっぽい仕事・インフラアーキなエンジニアな仕事も大好きですが, やっぱデータを見ると興奮するぐらいにデータ好きな人です. startpython.connpass.com 本日（2023/1/19）, ありがたいご縁がありまして, 「機械学習エンジニアが目指すキャリアパスとその実話」というお話をさせていただきました. 参加者の方々, ご清聴ありがとうございました&参加されていない方も気になるポイントあればぜひ御覧ください. 1/19の #stapy で「機械学習エンジニアが目指すキャリアパスとその実話」なるトークをすることになりました, 自画自賛ですが思ったよりいい内容に仕上がった気がします, 機械学習とかデータサイエンティストとかのキャリアでお悩みの方に届くと嬉しいです, 来てねhttps://t.co/KHxAXYY5mr pic.twitter.com/eguUyEnfb
チーム定例を改善するために行った3つのこと - NTT Communications Engineers' Blog
この記事は、 NTT Communications Advent Calendar 2022 13日目の記事です。 はじめに こんにちは。SDPFクラウド/サーバー 仮想サーバーチームの宮岸(@daiking1756)です。 普段はOpenStackを使ってIaaSを裏側からお世話する仕事をしています。 この記事では 先日開催された第6回 NTT Agile MeetupのLightning Talkで話した「チーム定例の議事録を工夫した話」を元に、 当日は時間の関係で話せなかったチーム定例を改善するために行った3つのことを紹介していきます。 3行まとめ 最初に3行まとめです。 チームの定例のBefore Afterを書いておきます。 Before After 全ての議題を話し切るまで時間を定例を後ろに延長していた 後ろに予定を入れることで時間厳守 定例開始後に議題を決めることもあった 開
振り返り時間の雑談っていらなくないですか？ - Qiita
はじめに 筆者は初めてアジャイルの開発でスクラムを経験。3ヶ月が経つ。 今回チーム内で出た意見を元に、良い気づきを得ることができたので記事にまとめました。 ★フルリモート環境 ★バックエンドとフロントエンドでチームが分かれている ★私を含む新規参画者はスクラム初心者 ★バック、フロントそれぞれスプリントの振り返りが終わった後、 スクラムチーム全員で共通の振り返りという名の雑談タイムがある。（30m～） 雑談の時間っていらなくないですか？ この議題があがり、スクラムチームの意見をいただきました・・・ 最終的な投票結果では、現状のままで良いという結論に至りましたが 雑談のメリット 改善案 新しい手法の提案 色んな気づきを得ることができたので記していきたいと思います。 この議題が生まれた背景 そもそも、開発状況が芳しくない。という所に 新規参画者の方が目をつけてくださいました。 『進捗率があまり
入社してすぐにマネージャーたちと組織のテーマいっしょにつくったらみんないきいきしはじめたよー - Commune Engineer Blog
はじめに このブログで伝えたいこと 僕が入社する前にあった組織の課題感 マネージャーたちが感じていた課題のリスト 課題感を要約 本当の課題 見えてきた本当の課題とどう向き合うのか マネージャー陣を統括して計画立案から実行をリードできる人が物理的に存在しない 複数チーム全体を俯瞰したマネジメント経験がないのでどうしていいかわからない よし、組織のテーマをいっしょに考えてみよう！ 組織が今年取り組むべきテーマを考えるワークショップ ワークショップの進め方 まずは道しるべとしての大目標 2022年のテーマ of コミューン開発 もともとあった課題をポジティブに言い換えると目標っぽくない？ これからのチャレンジ 自分たちで決めたテーマなら自分たちでアレンジもできる 組織がいきいきしだしたから起きているうれしいこと まとめ 最後に エンジニア職種全方面募集中です！！ 宮本とのカジュアル面談はこちら
中年IT人材おじさんの平穏 - megamouthの葬列
IT人材が不足してるんだって。零細Web制作会社で言えば、退職者が残したubuntu12サーバーに眠るRails5アプリをすぐにDDDでマイクロサービスに再構成して、jQuery満載のコードを全て読み下したうえで、フロントエンドをReactかなんかのSPAに全部書き換えて、E2Eを含めた自動回帰テストを整備して、ついでにCIも整備して、k8sにデプロイできるようにして、ドキュメントは小まめに残し、職場の心理的安全性を落とさず、飲み会にはかかさず参加、役員との関係も良好で、定期的な勉強会も開いてくれて、それでも残ったプライベートの時間を最新の技術動向やセキュリティ情報の収集に全量突っ込んでくれる、そんなごく当たり前のエンジニアが不足している。ついでに言うと、人類の原罪を一身に贖ってくれるスキルの持ち主も不足しているらしい。多分、我々はもっと求人サイトに金を払うべきなんだろうね。 同業者から、
コラム「職場での低い生産性や怠業行動は好きでもないタスクが割り振られた労働者に多く現れる」
好きでもない仕事を割り振られたことから職場に不満を持ったり、それにより働く意欲が減退し、ソーシャルメディアを見たりメールチェックなど仕事以外のことに時間を費やした経験はないだろうか？労働環境で労働者の働く意欲を保ちモラル・ハザード行動（いわゆる“さぼり”）を抑制することは企業組織の生産性を高めるために不可欠である。雇用者は労働者の職場での労働行動を完全には観測できないため、個人の報酬等対価の決定にチームや部門での業績が考慮されるケースが多い。しかしながら、Alchian and Demsetz (1972)やHolmstrom (1982)で議論されたように、このようなレべニュー・シェアの下では、労働者は同僚の貢献にただ乗り（フリーライド）して自分は楽をしたい誘惑に駆られるものである。本コラムでは、ただ乗り等のモラル・ハザード行動や労働者の生産性は、『望まざるタスク』（自分が選んだのではな
ソフトウェア開発の見積もり入門
見積もりとは？ Wikipediaによると見積もりとは、以下のようにあります。 見積（みつもり。見積り、見積もりとも書く）とは、金額・量・期間・行動を前もって概算すること。見積もること。あらましの計算をすること。また、その計算。目算。「所要時間を見積る」、「一日の来客者数をざっと見積もった」など、おおよその感覚で数字の見当をつける場合の口語体表現でも使われる。 Wikipedia このように見積もりとは、なにかを行う前に事前にその結果を予想しておくことを言います。 見積もりを使うケースは、ソフトウェア開発に限った話ではありませんが、製造業であるソフトウェア開発においては『見積もり』というタスクは様々なケースで登場します。 見積もりが苦手な人は多い ソフトウェア開発では、「この機能を開発するときにどのくらいで完成できますか？」といったケースが見積もりのシチュエーションとしては多いかと思います
人は「楽と感じる方法」しか選ばないことを前提に、仕組みを作らなければならない。
少し以前のことだが、あるベンチャー企業のドキュメンタリーをみていた時のことだ。 その会社では、社運を賭け画期的な生活家電の製造・販売に乗り出し、デパートの催事場で展示即売会を仕掛けるという。 出陣式のようなものまで開き、やる気みなぎるように見えるシーンには熱気を感じる。 しかしいざフタを開けてみれば、販売目標50台に対して売れたのはたったの10台。 営業部長以下、社員全員が意気消沈してしまい、社に戻るとさっそく反省会を始めることにした。 そしてその際、社員たちから出てきた反省の言葉は要旨、以下のようなものだった。 「お客様から質問をして頂いても、ほとんど答えることができなかった」 「新機能をどのように使うのかなど、生活に即したアドバイスができなかった」 表現はそれぞれだが、社員たちの言葉は製品を理解していないために売れなかった、という趣旨のものだった。 それらの言葉を受け、営業部長は居合わ
エンジニアの"有害な振る舞い"への対処法 - Qiita
本記事の続編として、自分が有害な振る舞いをしないようにする改善の取り組みを扱った記事も書いてます。 エンジニアや上司が"有害な振る舞い"を改善する方法 ※「難しい人」は概念として用い説明するのに便利な言葉でしたが、誤解を生じたり、本記事のポリシーに沿わない使用（難しい人というラベリングを特定個人に適用する使い方）が容易にされてしまいそうだと分かりました。そのような誤用を防ぐことを最優先とするため、代わりに「有害な振る舞い」という表現を使用し、人ではなく振る舞いに着目するタイトル及び文章に変更致しました。 はじめに 以下の記事を読んだ際に「難しい人」という表現が何となく面白い響きで印象に残ったので、これを機に自分の考えを今までの経験をもとに書きたいと思います。 “難しい人”が1人入ると、チームの生産性は30〜40％低下する 対抗せずに、場の「安心感」を作るための3つの条件 - ログミーBiz
「休むことは難しい」を読んだ感想と、自分が実践しているエンジニアの健康管理メモ
記事の内容をまとめると、 若い頃は過集中しても大丈夫だった。 今は疲労が慢性的に貯まり辛くなった。 疲労改善の為に5つの事をおこなった。 何もしない休みの日を数日作る。 ネットやパソコンから離れる時間を設ける。 ストレッチする（これが一番効果あったらしい）。 写真撮影などのリラックスできる別の趣味を持つ。 他人と健康を比べない。 感想: 自分も全く同じ状態だった。そして違う方法で生活改善して、現在は毎日健康的にエンジニアライフを送れている。 この記事には自分が行なってきて、かつ老後まで実践し続けるであろう生活改善方法を、備忘録もかねてまとめます。 前提: 「老後までプログラミングしたい」、「コード書くのが大好きなので、これからもずっとフルパフォーマンスで書き続けていたい」という自分みたいな方には絶対効果あると思う。 目次 大事な順にこうなります。 1日8時間深く寝るための睡眠薬 低脂肪高タ
エンジニアの幸せを奪いがちな７つのこと
はじめに 2021年初、優秀なエンジニアはまだまだ引っ張りだこです。コロナ禍で世の中のデジタル化が進む傾向があり、従来のようなIT企業のみならず、その他の業種や官公庁においてもエンジニアの需要は増えていそうです。 そんな中、このコロナ禍だからこそ気を付けたい、エンジニアの幸せを奪いがちな7つのことを、自戒を込めて俯瞰したいと思います。 （注意） １）自分の社での肩書はデータサイエンティストなので厳密にはエンジニアではないのですが、この記事においては便宜上、エンジニアという言葉を「業務でコード書く人、あるいはそれに関連する業務を担当する人」とざっくり定義して使用します。 2）自分の所感がほとんどです。本気にしないでください。 目の疲れ 概略 現代においてエンジニアに限ったことではないかもしれませんが、1日24時間あるうち、睡眠以外のほとんどの時間をディスプレイの前で過ごしている方が多いと思い
「新入社員に教えておきたいこと」チャンネルを作ったら社員みんなの業務効率が改善した件 - ゆとりずむ
こんにちは、らくからちゃです。 未だにコロナ感染者数は増えたり減ったりしていますが、10月よりたまには出社せえとのお達しが発令されました。 モバイルワークを続ける中で、「心を病むひとが出てきた」とか「何気ないコミュニケーションを復活させたい」とか、色んなお題目が並んでいましたが、毎日出社してる偉い人たちが、オフィスで自分たちだけで過ごすのは寂しくなっちゃったのかもしれません。 それはさておき「新入社員が、誰に何を相談したら良いのか分からない」という話は、確かにそうかもなあと思いましたね。広く言われていることですが、テレワークって「いままで作り上げてきた人間関係」に支えられている側面はかなり強い。 弊部にやってきた中途採用のオジサマも「みんなの人間関係が分からなくて、誰に何を聞けばよいか分からない」なんてことを言ってたけど、マニュアルやトレーニングじゃなくて、立ち振舞から学ぶ機会が減っている
ブロガー界隈の有名フリーランスエンジニアを見てプログラミングを始めないでくれ - 渡るネットは嘘ばかり
なんかマナブやばいな、ついでに色々見てたんですが、最近技術ではない方向で前に出てきてるエンジニアが増えてるようですね。 技術ブログは一般の人は見ないからわからないかもですが、技術ブログ系はエンジニアが見るだけで、基本的にそこで収益を得てるものも少ない印象があります。技術者の業界というのは業界の発展のために、無償で貢献(楽しみとしての人が多い)する人がすごく多く、それによってライブラリの充実の恩恵として再利用性や車輪の再発明を避けたりできてたりします。なので、この人達は金儲け系のブロガー界隈では話題にならないですね。 一般向けに言葉を発信する人が少なめだったというのもあるのかも知れませんが。というか、よく見たら取り上げようと思った人全員文系エンジニアですか…。文系エンジニアは技術よりお金に向かい、理系はお金より技術に向かう傾向でもあるんですかね。 今回はやまもとりゅうけん、マナブ、勝又健太さ
権限移譲する技術 - 宮田昇始のブログ
SmartHRの社長の宮田です。 この記事は SmartHR Advent Calendar 2019 3日目の記事です。 ソフトウェア開発にも役立つであろう「権限移譲」について書こうと思います。 胸を張って「これが得意です」と言えるものってそんなに無いのですが、CTOの芹澤さんから権限移譲だけはホメてもらえます。最近では「もしかしたら得意なのかも？」と思えるようになりました。そんな私が気をつけているポイントをまとめています。 権限移譲について学んだことはなく、独学です。そのため、すごーく当たり前のことしか書いてないかもしれませんし、逆に一般論からかけ離れている可能性があります。 あくまで、私が気をつけているポイントとして読んでいただければ。 いかに権限移譲してきたか？ はじめに、私の権限移譲について紹介します。 半年でプロダクトにノータッチに 起業する前、私はWebディレクターとして仕事
Google 辞めました - アスペ日記
Google辞めました。 最終出社日は 5月11日。 5月31日まで有給消化。 その後は無職。 転職先が決まっていて有給消化している「なんちゃって無職」ではなく、ガチ無職。 とりあえずハロワでも行こうと思う。 まず初めに。 この記事は、Twitter で @takeda25 をフォローしてくれている人たちが想定読者だ。 また、これは相当長くなると思う。さらに、中ではたとえ話を使うので、読んでもさっぱりピンと来ないかもしれない。 だから、長い文章を読んで「読んで時間を無駄にした」と思うタイプの人は、ここで読むのをやめてほしい。 もう一つ。 この記事を書いた人間（真鍋宏史）は無名の一社員で、ろくに業績もない。 そういう人間が何かを言っても聞く価値はないと思うなら、やはり読むのをやめてほしい。 この記事では、自分のいた場所に対してネガティブなことも書くと思う。 そのため、なぜそういう行動を取るか
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
IT業界の日常を図にしてみたら「地獄絵図」「ウチの会社の悪口はそこまでだ！」になった→これから業界に入る人は身震い
