私は昔から ADHD で昔から発想力や問題解決力はあるのだが、自分自身が何かのスキルを上達することが非常に苦手だ。コンサルとか、エバンジェリストみたいな「人にやってもらう仕事」は得意だが、プログラマとか、ヴォーカリストとか、自分が本当になりたかった職業には何回もチャレンジして何回も失敗してきた。 遠くから見ていると私は何かが出来てるように見えるかもしれないが、冗談抜きで人の３倍ぐらい時間をかけないと成果が出ない。しかも、中途半端にしか完成しない。だから、土日も常に何か努力していないと不安になる。 多分私と同じようなADHDの人は、自分的に努力しても何も達成出来ない辛さを感じているかもしれない。過去にも色々試してみたのだが、４７年生きてやっと自分でも実施できる対策が見つかったので、同じ様なことで苦しんでいる人のヒントになればと思い久々にこのブログを書いてみた。 「自分で何かを作れる人」が長年

TOPコラムキャリアを創る思考法伊藤淳一氏が「一番下手くそエンジニア」から脱出した4つの方法。2023年版ITエンジニアの生存戦略【後編】 伊藤淳一 1977年生まれ、大阪府豊中市出身。株式会社ソニックガーデンのRailsプログラマ、およびプログラミングスクール「フィヨルドブートキャンプ」のメンター。ブログやQiitaなどでプログラミング関連の記事を多数公開している。将来の夢はプログラマーをみんなの憧れの職業にすること。主な著書に「プロを目指す人のためのRuby入門 改訂2版 言語仕様からテスト駆動開発・デバッグ技法まで」（技術評論社）などがある。 前回では、筆者がプログラマとして入社したSIer時代のエピソードと、そのあとに入社した外資系企業での社内プログラマとしてのエピソードを書いてみました。IT業界に入って間もないエンジニアさんや、これからの自分のキャリアを考え始めたエンジニアさんに

プロジェクトマネジメントといえば「進捗確認」と思っている人も沢山いると思いますが、私は進捗確認という行為そのものに否定的です。 このエントリでは、進捗確認という行為がいかに無意味であるかという話および、進捗管理として行うべきことを書いていきます。 誰かのプロジェクトマネジメントの参考になればと思います。 ※ 進捗管理が不要という話ではありません 進捗確認の定義このエントリでの進捗確認は下記の定義とします。 複数人が関わるプロジェクト等において、プロジェクト等をマネジメントするべき立場にある人間が、プロジェクトの所属メンバーに対してタスクの進捗状況を口頭・テキスト等で直接確認する行為 少し難しい言葉で書きましたが「進捗どう？」といった質問およびその回答からなる一連の流れだと思ってください。 なぜ進捗を確認したくなるのかプロジェクトマネージャー（PM）の仕事のひとつに納期の管理というものがあり

今日はチームメンバーのオンボーディング時の作法、チームでの仲間の受け入れまたは受け入れられについて書きたいと思います。 ここ最近、ぼくは自分で会社をやりつつ、色々なスタートアップや事業会社にも入らせていただいて一緒に事業をやったりプロダクトを頑張ったりマーケティングをアレコレしたりしているのですが、その関係もありチームメンバーを沢山迎え入れることもあれば、新しいチームに迎え入れてもらう側ということもあります。一般的な人よりも両方のオンボーディング機会が多い人生を歩んできました。 そこで気づいたことというか、経験してみて考えたことを書いていこうと思います。 つよつよ人材が有名企業から来てくれたけど特に活躍しないで消えていくあるある GAFAや有名な企業・スタートアップで働いていたとか、いわゆる「つよつよ」とされる人。当然「つよつよ」と言われるのだから優秀であると認識されていると思います。 で

この疑問はもう俺の中で何十年もくすぶっているんだが、未だにその答えは見つかっていない。 そもそも俺はコンピュータサイエンスというものをよくわかっていないというのもあるんだが、プログラマーをやっていてコンピュータ・サイエンスの素養がなくて困ったことがない。 学生が言うところのコンピュータ・サイエンスが社会に出て何の役に立つんだよっていう話がしたいんじゃない。 ここに吐き出しつつ自分なりに問題を噛み砕いてみたい。 フラフラ思いつくままに書いているから頭悪い文章になることだけは先に宣言しておく。 仕事をしているうえでなんで困らないのかまずコレが最も重要なポイントだと思うんだが、仕事でプログラム書いていて、コンピュータ・サイエンスの素養がなくて困ったことがない、例えばコンピュータ・サイエンスのボキャブラリがないと会話すらままならないなんて言うことは起きたことがない。 更に言うならば要件定義をコード

そういえば、さくらインターネットには2日以上連続の有給休暇を事前申請すると、有給休暇手当が1日あたり5千円出る制度あるんです。 もともと、直前の有給休暇申請を減らして、計画的に休みとって欲しいなって事だったんですが、効果てきめんでした。 ペナルティよりベネフィットだなと思います。 — 田中邦裕＠さくらインターネット社長🐈‍⬛🐕 (@kunihirotanaka) 2022年9月12日 このツイートに対するリアクションを見ると、どうやら多くの人は、「ベネフィット」という言葉に惹かれたらしい。 会社がはっきりと「連休取得推奨」を表明していれば、従業員は気兼ねなく連休を申請できるし、さらにカネももらえるのだから、確かに魅力的だ。 でも実は、本当に大事なポイントは、別のところにあるんじゃないかと思う。 それは、「計画的に休みをとる」というところだ。 なぜなら、長期休暇取得のためには、「仕事に合

この記事で書きたいことは、以下のような内容です。 ・マネジメントをする上では、「出来てない」「進んでない」という情報は最重要であって、早く言ってもらえば言ってもらえる程傷が浅くて済む ・機械的に進捗を把握出来るのが一番だが、なかなかそうもいかない場合もある ・だが、「出来てません」「進んでません」というのは物凄く言いにくいことで、ベテランでもギリギリまで言えない人は多い ・「出来てません」と可能な限り言ってもらいやすい環境を作るのは上司の仕事 ・個人差もあるが、ある程度「言いやすい」条件を整えることで、「言えない」人でも言えるようになってくれる場合もある よろしくお願いします。 さて、書きたいことは最初に全部書いてしまったので、後はざっくばらんにいきましょう。 皆さん、「進捗ダメです」って言えてますか？ 「全然できてません」って言えてますか？ これはどんな仕事、どんな分野、どんな業界でも同

導きのはじまり おぉ、貴方は…褪せ人ですね。 そして、エルデンリングを求め、この狭間の地にやってきた。 この先、プログラミング学習の攻略に繋がる貴重なアイテム が、7つあるぞ すごいなにかだと思うだろう？ 以下の記事を、ご照覧あれい！ 1. 強い敵はスルーして先に進む プログラミングを勉強していると、序盤にツリーガードのような強敵が現れることがありますが、 スルーして先に進むことが大事です。 序盤から強敵と戦うと、ボコボコにされて心が折れます #include <stdio.h>は、こういうもんだと「おまじない」としてスルーする。 var body: some Viewや、fn longest<'a>など、 見慣れない表記を見ても、いったん気にしない。前に進む。 強敵は、力を付けてレベルが上ってから再戦しましょう。 目の前に現れたすべての敵と戦う必要はありません。 ボスまでのルートを開通す

これまで何人も強いエンジニアと出会って、 「なんで自分はあの人と比べて何もできないんだ・・・。」と何度落ち込んだことか。 ただ、最近強いエンジニアの仕組みを理解してから落ち込むことは無くなった。 それについて書いていく。 （強いエンジニア達本人に聞いたわけではなく、観察してえられた個人の見解です） 気づき：強いエンジニアを見て落ち込む要因は2つありそう 1つは今の知識や技術力の差。 書くコードの違いだったり、成果物ができるまでの時間に差がありすぎたり、PRレビューで自分が思いもしなかったウルトラ解決策を何度も提示されて、自分の実力の無さを感じて落ち込む。 もう1つは新しいことを学ぶときの時間の差。 お互い知らない技術だったはずが、いつの間にか強いエンジニアはその技術に習熟(しているように見える)して、自分は理解不足で取り残されているという状況が発生しがち。 この時、自分には才能がないのかと

私は、あらゆる組織・個人の中に、「依頼された仕事をやらない人」を見てきた。 例えば、コンサルティングに訪問した会社のプロジェクトチーム内に。 あるいは、執筆を依頼したライターさんに。 またあるいは、会社の同僚・部下に。 彼らは確かに、「依頼された事柄」に対して、「はい、引き受けます」という。 しかし、遂行される気配がない。 心配になって、「あれはどうなりましたか」と聞く。 すると「あ、すいませんやります」と返ってくる。 しばらく待つ。 それでも何も遂行される気配はない。 もう一度「この仕事、やりますか」と聞く。 「やります」と返信がある。 それでも、何も遂行される気配はない。 結局、こちらから連絡するのをやめ、処理はこちらでやることになる。 こういう人々には、「引き受けたじゃないですか！」と怒ったところで無駄であるし、代わりの人を探したり、時には自分でやったりしたほうが早いからだ。 でも、

大前提 この記事読まずに仕事して下さい。 整理系 作業机の整理 PC/ディスプレイの清掃 キーボードなどの周辺機器の清掃 PC内の不要ファイル削除 ドキュメント整理 雑務系 メール確認 スキルシート更新 日報/月報 社内アンケート 有給申請 その他各種申請 業務効率化系 ブラウザのブックマーク整理 キーボード設定見直し マウス設定見直し 使用ツールのショートカット調査 「ツール名 おすすめ設定」でググってより良い使い心地を目指す ブラウザ エディタ SQLクライアント メール管理 勤怠管理 PC起動時 ターミナル などなど 勉強会系 connpass等で勉強会を調べる IT勉強会を探すために捗るサイトまとめ【9選】 勉強会に参加する 勉強会の発表ネタを探す 勉強会に関する読み物 IT系エンジニアのためのプレゼンテーション入門 ライトニングトーク(LT)準備の参考資料まとめ 交流系 社内のS

ここ1年ぐらい感じていた「学びに関する格差」の話を書く。 最初にまとめ・勝手に学ぶ人は、自分の周囲にある「学びに使えそうな仕事」を探して自分の仕事にすることを繰り返す ・期待されて学ぶ人は、上司とかの期待に応えて新しいことを学ぶ ・「勝手に学ぶ人のスピード」＞「期待されて学ぶ人のスピード」なので、格差が開いていく ・「早く行きたければ一人で行け、遠くへ行きたければみんなで行け」が実現できない ・勝手に学ぶ人を止める理由も見つからない ・困ったなあ（解決策わからない） では詳細を書いていく。 勝手に学ぶ人：自分の周辺にある「誰も手をつけてない仕事」を発見し、自分の学びに利用するそれぞれが自分の担当範囲の仕事をしているとする。 それぞれが自分の担当範囲の仕事をしている勝手に学ぶ人は、「誰も手をつけてない」かつ「自分の学びになりそうな」仕事を自ら発見して、自分の仕事として取り組む。 勝手に学ぶ人

僕はいま、40代最後の数日を過ごしていて、このエントリが公開されているときには（急病や事故などで世を去っていなければ）50歳を迎えているはずです。 僕の両親はともに50代で人生を終えているので、ああ、もうここまで来てしまったか、終活とかも考えなければならないのかな、という感慨とともに、こんな悟りには程遠い年齢、成熟度で命が尽きるとき、両親はどう考えていたのだろう、納得できなかったんじゃないか、と想像もするのです。 命というのは、本人が納得するしないにかかわらず、終わるときには終わる。 最近、周囲の人の若くしての思いがけない訃報が続いて、僕自身混乱もしているのだけれど、その一方で、「まだ自分の番ではなかった」ことに、少し安堵もしてきました。 それでも、いつかは順番がまわって来る。 今の世の中の全体像としては、50代くらいは、まだ「現役世代」であり、そこまで老け込むことはないのかもしれませんが

本記事の続編として、自分が有害な振る舞いをしないようにする改善の取り組みを扱った記事も書いてます。 エンジニアや上司が"有害な振る舞い"を改善する方法 ※「難しい人」は概念として用い説明するのに便利な言葉でしたが、誤解を生じたり、本記事のポリシーに沿わない使用（難しい人というラベリングを特定個人に適用する使い方）が容易にされてしまいそうだと分かりました。そのような誤用を防ぐことを最優先とするため、代わりに「有害な振る舞い」という表現を使用し、人ではなく振る舞いに着目するタイトル及び文章に変更致しました。 はじめに 以下の記事を読んだ際に「難しい人」という表現が何となく面白い響きで印象に残ったので、これを機に自分の考えを今までの経験をもとに書きたいと思います。 “難しい人”が1人入ると、チームの生産性は30〜40％低下する 対抗せずに、場の「安心感」を作るための3つの条件 - ログミーBiz

新卒で社会人になって以来、ソフトウェアのエンジニアをかれこれ10年近くやっています。そんな私が、新卒で入った会社の最初の配属先で、上司の上司に教えられた報告の書き方について紹介します。 報告には意味を書くその人は「報告には意味を書くこと。」と常々言っていました。「ただ単にやったこと、起こったことを書いたものは"日記"。その意味を書かないとダメ。日記が許されるのは新人のうちだけ」だと。 ダメな例：「○○の設計はxx日に完了。現在は実装中。」 こういう週報を書くと、「これは日記だよ」と指摘されます。設計がxx日に完了したことが、チームやプロジェクトにとってどういう意味をもつのかが書かれていないからです。この報告は、例えば以下の様に改善できます。 改善した例：「○○の設計は、予定通りにxx日に完了。・・・」 これならば、「設計がxx日に完了 → これは予定通りである。順調である。」という意味が盛

はじめに 2021年初、優秀なエンジニアはまだまだ引っ張りだこです。コロナ禍で世の中のデジタル化が進む傾向があり、従来のようなIT企業のみならず、その他の業種や官公庁においてもエンジニアの需要は増えていそうです。 そんな中、このコロナ禍だからこそ気を付けたい、エンジニアの幸せを奪いがちな7つのことを、自戒を込めて俯瞰したいと思います。 （注意） １）自分の社での肩書はデータサイエンティストなので厳密にはエンジニアではないのですが、この記事においては便宜上、エンジニアという言葉を「業務でコード書く人、あるいはそれに関連する業務を担当する人」とざっくり定義して使用します。 2）自分の所感がほとんどです。本気にしないでください。 目の疲れ 概略 現代においてエンジニアに限ったことではないかもしれませんが、1日24時間あるうち、睡眠以外のほとんどの時間をディスプレイの前で過ごしている方が多いと思い

ここ2年くらいの話なのですが、仕事で「フロントエンド会」というチーム内委員会のようなものを立ち上げて運営しています。元々1人の Web フロントエンド職人がプロダクトの Web フロントエンドの面倒を見ていたのですが、その方が異動されることになったので、残った人で面倒を見ていける体制を作りましょう、というモチベーションで発足した会でした。この話については以前イベントで発表したので、詳しくはこのスライドをご覧下さい。 speakerdeck.com Web フロントエンド職人の異動とともに入社した id:mizdra が Web フロントエンドが得意だったので、ペアプロやペアオペ、定例会などを通じてどんどんスキルや知見を配っていく、という戦略で運営していました。実際に 2 年経過してみてメンバーも徐々にキャッチアップしていって、ちょっとしたパフォーマンス改善をやってみたり、最近 Gulp や

会社には専門分野の技術とは別に、組織の中で働くための一般的な技術がたくさんある。学校で体系的に教えてもらうものじゃないから会社に入って身に着けていく。僕自身もう会社に入って8年半になるからずいぶん知見が溜まってきた。後輩や新人がその習得に自分と同じ時間をかけるのはもったいない。一度全体を整理しておきたいと思っていた。 それで書いてみたら長くなって、3分の2に圧縮したけどまだ長いのであらすじだけ先に書いておく↓ 働く上でいろいろな制約が存在していて、その制約に対抗する手段としていろいろな技術がある。この制約-手段のつながりを見ず単に結果としての技術だけを覚えても応用がきかないし身につかない。この技術にはレベルがあって、このレベルがちぐはぐだと上手くいかない。 「能力と時間」、「ルール」、「他人の感情」、「自分の感情」、「人間の生理」という5つの制約について「制約→技術」を展開していく。最後に

会社で係長的なポジションになって3年近くが経った。先日、副係長というか職長的なポジションが新たに設けられ、30歳前後のメンバーが就いた。折を見て彼らに伝える機会があるかもしれないし、3年やってみた知見を自分の中で一度整理しておきたいと思った。（大手メーカーの製造側に近い部門で働いている、という前提がある。） 自分が苦しくならないようにする 究極的には本人が自分でスタイルを確立するしかない。 「こうした方がより良い」と思って行動変容しても、それで自分が苦しくなるなら続けられない。 どうせ正解の型が一意に決まるわけではないし、仮に正解の型があっても自分を完全にはめ込むこともできない。 「自分がやれるようにやるだけ」くらいに思っている方が精神衛生に良い。それで不適格ならしょうがない。 一方で「より良い方法」に寄せる努力も必要で、その間のバランスが必要になる。 例えば自分自身は、人付き合いがすごく

一年半SEとして働いてきた中で、私自身が苦手だと思っており、他人からもそのように評価されていたのが「質問の仕方」でした。 それが先日、他人から「質問の仕方がうまいね」と褒められることがあり、ようやく一人前の質問の仕方ができるようになってきたので、どのようにして克服できたのか紹介したいと思います。 質問の基本形 私が入社したばかりの頃は、わからないことがあればすぐに先輩に質問していました。 そのときにしていた質問の内容はだいたいこんな感じです。 「環境構築を手順書通りにやったんですけど、○○のコマンドでエラーがでてしまいます！なんとかなりませんか？」 このような質問を受け取ったら、先輩は暇ならばエラーメッセージを見てくれ、エラーメッセージに書かれていることに対して調査してくれるかもしれませんが、忙しいときにはそんなことはしてもらえません。 こんな質問を繰り返しているうちに先輩からは「技術系メ