新人エンジニアに読ませたくない技術書・ビジネス書
繰り返すかは、新人エンジニア次第。
- 作者: 戸部良一,寺本義也,鎌田伸一,杉之尾孝生,村井友秀,野中郁次郎
- 出版社/メーカー: ダイヤモンド社
- 発売日: 1984/05/01
- メディア: 単行本
- 購入: 2人 クリック: 64回
- この商品を含むブログ (15件) を見る
これを読んだだけではプロジェクトマネジメントできない。
プロジェクトマネジメント知識体系ガイド PMBOKガイド 第6版(日本語)
- 作者: Project Management Institute
- 出版社/メーカー: Project Management Inst
- 発売日: 2018/01/01
- メディア: ペーパーバック
- この商品を含むブログを見る
なんちゃってウォーターやっているから失敗する。
システム設計のセオリー --ユーザー要求を正しく実装へつなぐ
- 作者: 赤俊哉
- 出版社/メーカー: リックテレコム
- 発売日: 2016/02/26
- メディア: 単行本(ソフトカバー)
- この商品を含むブログ (1件) を見る
少し前は、アジャイルサムライ−達人開発者への道−だったが。
カイゼン・ジャーニー たった1人からはじめて、「越境」するチームをつくるまで
- 作者: 市谷聡啓,新井剛
- 出版社/メーカー: 翔泳社
- 発売日: 2018/02/07
- メディア: 単行本(ソフトカバー)
- この商品を含むブログ (2件) を見る
当たり前のことをできないチームの年中行事である。
デスマーチ 第2版 ソフトウエア開発プロジェクトはなぜ混乱するのか
- 作者: エドワード・ヨードン,松原友夫,山浦恒央
- 出版社/メーカー: 日経BP社
- 発売日: 2006/05/03
- メディア: 単行本
- 購入: 9人 クリック: 355回
- この商品を含むブログ (119件) を見る
当たり前のことをチームでやらないから。
アプリ開発チームのためのプロジェクトマネジメント チーム駆動開発でいこう!
- 作者: 稲山文孝
- 出版社/メーカー: マイナビ出版
- 発売日: 2015/04/28
- メディア: Kindle版
- この商品を含むブログを見る
テストする計画立てないからデスマになる。
契約なんてまだ早いと思ったら勝てない。
SEC BOOKS 共通フレーム2013(電子版): ?経営者、業務部門とともに取組む「使える」システムの実現?
- 出版社/メーカー: 独立行政法人情報処理推進機構
- 発売日: 2014/09/11
- メディア: Kindle版
- この商品を含むブログを見る
お金を稼ぐのが仕事。数字からは逃げられない。
経営の大局をつかむ会計 健全な”ドンブリ勘定”のすすめ (光文社新書)
- 作者: 山根節
- 出版社/メーカー: 光文社
- 発売日: 2005/03/17
- メディア: 新書
- 購入: 8人 クリック: 51回
- この商品を含むブログ (54件) を見る
法律云々の前に日本人、標準的な日本語が、とツイートされる。
組織文化は管理職になって自分の裁量の範囲でしか変えられない。
- 作者: リチャード・シェリダン,原田騎郎,安井力,吉羽龍太郎,永瀬美穂,川口恭伸
- 出版社/メーカー: 翔泳社
- 発売日: 2016/12/20
- メディア: 単行本(ソフトカバー)
- この商品を含むブログ (3件) を見る
こんなことを尋ねたくなったチームは息していない。異動しよう。
上司や先輩への対応としては一見どうかともうが、実は正しい。
メンタルの本を読まなければやっていけない職場なら組織から躊躇なく去ろう。
自衛隊メンタル教官が教える 心の疲れをとる技術 (朝日新書)
- 作者: 下園壮太
- 出版社/メーカー: 朝日新聞出版
- 発売日: 2013/02/13
- メディア: 新書
- この商品を含むブログ (13件) を見る
職場にいるときに災害にあうことは3.11で体験している。自分の身は自分で守る。
- 作者: 東京都総務局総合防災部防災管理課,東京都,かわぐちかいじ
- 出版社/メーカー: 東京都総務局総合防災部防災管理課
- 発売日: 2015
- メディア: 単行本(ソフトカバー)
- この商品を含むブログ (8件) を見る
手遅れ感あるが。
20歳のときに知っておきたかったこと スタンフォード大学集中講義
- 作者: ティナ・シーリグ,Tina Seelig,高遠裕子
- 出版社/メーカー: CCCメディアハウス
- 発売日: 2010/03/10
- メディア: ハードカバー
- 購入: 475人 クリック: 17,353回
- この商品を含むブログ (395件) を見る
自分で作るものだから、だよ。
さらば、技術的モラトリアム
自分は、20代で頑張ろうとは思っていなかった(実際、頑張っていなかったし技術的な意味合いでは専門をどうスカ先延ばししていたモラトリアムだった)し、今更言われても時間は巻き戻せないし、タイムリープするわけにも時間軸を飛び越えるわけにもいかない。長門有希と同じこたつに入っているのであれば別な話だが。
35才定年説なんて、ああそうなんですねくらいの感じだし、それよりは、30代前半までに興味を持つ幅を広げておかないと、40代に入った途端、技術力がピタリと止まってしまうエンジニアになりかねない方を心配する。
何十人ものメンバを見てきて、継続的に技術を追うエンジニアは一握りだ。調査レポートにもあったが、ほんと一握り。継続という限定的なキーワードを外し、技術を維持するエンジニアとしても片手の半分を超えるくらいでしかない。
自分の経験から言えば、残りともう片方の片手は30代前半までに自分の専門を決めて来なかったのだろう。専門を決めないから、自分で調査も研究もする必要がないのである。
つまり、30代前半は残りの人生を左右する最後のチャンスだということだ。何度かエントリに書いてきたとおり、自分はたまたま、偶然にも最終便前くらいに搭乗できたらしく、そこから15年も経てば事業の一部に責任を持つまでに残れた。
指示されてデスマを転々とすることもなく(役員から請われて立て直しは何度かしたが)、選んだ専門を自分のペースでつまみ食いしたり、教え、教え合う環境を作っている。担当する事業は上役が決めることだが、自分の専門性を知っているのでそれを踏まえて、になるからミスマッチは起きないし、起きたら断固断る。はっきりと適性見てないだろう、と言えるからだ。
それは、専門を決めているから言えることだ。
その専門を決めるのが30代前半までにすると成功したエビデンスが自分である。エビデンスは再検証しないと確からしさは証明されないから、あなた自身がするかどうかである。
そこは任せる。
まあ、Matzも言っているのでそこそこ間違いな感じでないだろう。
確かに前みたTEDで35歳までの出来事で人生の80%が決まると聞いて頑張ろうと思ったのを思い出した。
20代の人は絶対見た方がいい。
- 作者: まつもとゆきひろ,David Flanagan,卜部昌平(監訳),長尾高弘
- 出版社/メーカー: オライリージャパン
- 発売日: 2009/01/26
- メディア: 大型本
- 購入: 21人 クリック: 356回
- この商品を含むブログ (129件) を見る
- アーティスト: 爆風スランプ
- 出版社/メーカー: Sony Music Direct(Japan)Inc.
- 発売日: 2014/04/01
- メディア: MP3 ダウンロード
- この商品を含むブログを見る
半年後に崩壊するかもしれないチームを立て直すとしたら
片手くらいの小さなチームがある。担当している業務を分類すると定常業務とプロジェクト業務がある。定常業務は定常という名をつけているが、計画的に行える業務もあれば、可変的に流量が変わる業務がある。後者は、他部門からのリクエストの有無に依存し、コントロールできない。
数週間観察していると、どうも覇気がない。覇気があればいいってものでもないが何か足らない。
週初めにプランニングミーティングと称してその週にやることをチーム内で決め、週末まではデイリースタンドアップミーティングをしている。週末の金曜日にはふりかえりだ。
作業は付箋紙に書き、ホワイトボードに貼り、進捗を可視化している。
このチームはレポートライン的に役員に近く、担うミッションも組織としては重要度合いが高い。その意味ではプレッシャーも高い。ただ、読めない定常業務が荒ぶるとプロジェクト業務はストップし、スケジュールオーバーランすると役員からのチェックが入る。
多分、このままでは半年くらいで崩壊するかもしれない。
何がおかしくて崩壊するのか。
- 業務設計が甘く差し込みのリクエストに対応できない
- チケットのタスクの切り出しの粒度が大きすぎ、完了までに割り込みが入りやすい
- 経験は人に蓄積し、メンバでカバーできない
- 全体の活動プランを描けていない
- 仕事が楽しくない
今このチームでやらないといけないのは何か。
- 業務量に閾値、キャップをかける。上限は7割にしておく
- タスクの単位を半日程度を1として揃える
- 記録を取る時間を計画に折り込む
- 全体の活動プランを時間軸を入れて描く
- 楽しみを作る
差し込みが入ってもいいように業務は定常、プロジェクト合わせて6時間くらいにしておく。会議は6時間に含める。
1つの付箋紙は、3−4時間程度に分解する。
チケットをDoneさせる前に記録する。redomineでもなんでもいい。とにかく、記録する。
レベル1程度で良いので、スケジュールを作る。月、マイルストーン、大項目のタスク。この程度でいい。これをホワイトボードに貼っておく。
厄介なのは楽しみ、である。仕事だからと割り切れるならいいが、成果が出ていないのに(いや、出ているがチームが自身で期待しているよりは高くない)楽しいわけがない。
やるとコミットして、やって、期待通りに成果を得る。そのために、タスクを小さくする。小さくなるから終わる。差し込みがあっても7掛けだからそこで吸収できる。できなければ、週単位でまとめたバッファを使う。もしくは、メンバのバッファを合わせて片付ける。
どうだろう、やらないといけないことをやったときの情景を思い描けるだろうか。描けたら、それは多分、楽しく思える。
それでいけるだろう。
転職で面接を受けるときの対策
転職するためには、転職する先を確保しなければそもそもの転職ができない。会社を辞めたいだけなら、退職願なり、所定の書式に記載の、守秘義務を守れとか、転職先に行ってから職場の社員を引き抜くなとかの記載事項を承諾して終わりである。ただ、辞めてから収入もなくなる(失業保険そのうち出るだろうが)ので、移る先を確保してから、となる。
どこの転職の候補先でも、
- 今欲しい技術を持っている『手が動く』エンジニア
- 組織を引っ張る専門知識を持つマネージャ
を欲しいと考え、採用活動に投資している。今、リソースがパンパンか、この先もっと逼迫することが予測されているからか、現行メンバの退職予定があるから、などの理由で猫の手を欲しがっている。
転職活動では、だいたい、3回くらいの面接をすることが多い。最初に出てくるのは、採用活動のリーダ的な役割のことが多い。1回目でポートフォリオでは判断できないスキルやスキルレベルを確かめる。合わせて、採用側の文化に合うかを見ている。2回目はチームの他のメンバが出てくる。3回目は役員面接である。
1回目の面接では志望動機やマジノの中身を聞かれる。聞かれている最中にコミュニケーション能力や組織のカルチャーに合うかも見ている。コミュニケーション能力と表現したが、見ているのは採用活動をしている所属予定でやっていけるかとか、組織の価値観に合うか、と言う点であることである。
技術の腕だけで勝って欲しいなんて、この複雑で難易度の高い課題の多いご時世では、時代錯誤も甚だしいと思った方がいい。そうでなければ、OKRも心理的安全性も必要ないことになってしまう。
基本的に、想定問答をテキストに書き出して骨子を頭に入れておくこと。間違っても出たところ勝負にしてはいけない。
面接(1回目)
- ゆっくり話す
早口で理論立てて、聞き取りやすく話せるなら別だが、思いつくまま話すとあとで『しまった、余計なことを話した』となり兼ねない。伝える言葉を思い浮かべながら、伝える。 - 明確な言葉選び
現職ではなく、転職先にやりたいことを見つけられたから移りたいと考えているはずである、と思っている。シンプルに『◯◯をやりたい』などと表現する。あれこれ長く説明をするのは思考力やまとめるスキルがないと見られかねない。 - 実現可能性
◯◯をやりたいという◯◯は、ビジネスであれば転職候補の組織のページを見ておく。実現可能性のある◯◯でなければ志望しないのだから嘘にならないようにしておく。 - 軸をブラさない
転職理由、実現したいこと、自分の念持など、軸を変えない。 - 転職先で想定している仕事、役職
SI、SESなどは断固拒否するのであれば、明確に伝える。 - ポジティブに表現する
◯◯ができなかったからではなく、前職で△△をやってきて、先の、向こう側の、と未経験の領域を経験したい、などと表現するとよい。 - 年収
最初からお金を会話できる方が良い。いくら欲しいかを明確にしておくこと。希望は、現職の年収から考えないこと。市場でどのくらいか、自分の実力を最大限に現金化すること。その上で、ここまでならと下限を決めておくこと。
福利厚生が違うので一概に比較できない。総合的に判断する。年収が上がっても残業込みの時間が多ければ、トータルでダウン、なんてなりかねない。
1回目の壁は高い。次に進めたらラッキーくらいの心持ちがいい。
エージェントを使うのはオススメしない。エージェントのフィルタが入るので転職先の候補とのタイムラグがあり、とてもストレスになる。
1社しかコンタクトがないからといって、そこに執着しない。すると自分から条件を下げかねない。それでは誰も幸せになれない。
全員PO
従来、エンジニアは如何に早く、上手に作れる方法を知ろうとして、身に付けようとしてきた。なぜなら、目の前の契約を決められた予算と期間でこなさなければならないからだ。
だから、ものづくりで必要な道具の作り方や道具を使えるエンジニアを導く方法を知りたいと思うし、マネージャはそれを習得する機会を作る。
そして今は、作るものは何かを捻り出すやり方を学んでいる。ここでも同じようにやり方を学ぶ。マネージャは道具の使い方、そちらへ予算をシフトする。
予算のシフトの流れが起きているのは、結局、道具は同じで作り方はお家のごとで良いことに気づいたである。だったら、作るものはどんなものかを形で見えるようにする方法を知るためにバジェットを使うことにしただけである。
ただ、これも肝心の『もの』を手に入れる方法は含まれていない。
そこにないものは『これを作りたい』のこれを想像する方法である。
与えられた素材や制約では、斜め上の『これ』にはならない。よくて、ヘンテコな組みわせの類である。
一方、エンジニアに限ることではないが、『これ』はご自身で作られている。そして、日々変化させている。無意識に生存するための必然性としてエンジニアはPOをやっているのである。
その根底にあるものは、革新ではなく必然性なのではないか。そうするとまた、『これ』の可視化は有用なのだろうか、という疑問はある。『これ』を言語化して作ってという指示に使うのはわかる。
PO研修の前に、ご自身はなぜご自身であるかをを訊ねると『これ』を作る必然性を言語化できれのではないだろうか。
目で見てアウトプット量を予測する
あるグループリーダが自分の担当が進まないと愚痴なのか、俺忙しーアピールなのか、訴えてくる。実際、忙しく見える。
チームで何か予定を入れようとすると壊滅的に難しい。なぜなら、そのグループリーグの日程が埋まっているからだ。その余波で、あるメンバは日中に共同作業ができず、朝活と称して定時前に共同作業をしている。
何もこのグループリーダが悪いのではない。どこでも同じようなものだ。色々原因はあるが、グループリーダの管理スパンが適切ではないとか、デレゲート問題とか、情報共有の運用の問題だとか、まあ、色々潜在的にあるし、なんとかしようと思えばどうにでもなるし、対処1つすれば効果は得られやすい。それなのにそうならないのは、グループリーダの持って生まれた性質がかなり影響している。つまり、意思決定の根幹を変えなければ現状を変えることは難しいのである。そこを変えるのも1つのスキルである。
こんなことが続くと、周りはコミュニケーションが取りづらくなるし、進まなくなり、チーム全体のパフォーマンス、アウトプットは出なくなる。日本の組織の意思決定が遅いと言われるが、その原因の1つはこれである。裁量を持つリーダが忙しく、自分のアウトプットを全く出せていないからだ。
こうしたリーダやチームのパフォーマンスは、実は目で見て予測できる。ちょっと考えてみてほしい。
:
:
:
:
:
:
:
どうだろう。何か思いついただろか。
答えは、スケジューラの予定の埋まり具合である。なんだよ、と思ったら、ずっと自分で気づくことはできない。
アウトプットできていないリーダは同じ時間帯に予定がブッキングしている。1週間前でもう翌週の予定が完売直前である。
イメージ的には、スケジューラで8割埋まっていたら、ほとんどアウトプットは出ない。遅れに遅れひと月は遅延している。それもいくつものタスクで。
埋まり具合 アウトプット量の予測
30% エンジニアはこのくらいでないと予定しているタスクはスケジュールどおりに完了しない。
50% 先のことを考えたり、難易度の高いテーマを解決するための時間を取れなくなってくる。さらにリーダはメンバのタスクのリスクに目が届きにくくなってくる。
80% 予定はブッキングし、席にいつもいない。複数のタスクで遅延が常態化している。直前の納期に合わせるような仕事の片付け方になる。
スケジュールを埋める予定も会議ばかりで、その会議の立場がオブザーバ的なものであれば時間の無駄遣い感は大きすぎる。どうしても出席が必要であれば、メンバに代理出席させておくくらいの割り切りが必要だ。どうせオブザーバなのだから質問されても持ち帰ればいい。
上述したとおり、原因はその状態を受け入れているリーダにあるが、組織の文化も影響する。カルチャー的な意味合いがあると、そういう状況であると認識できる観点、point of viewのスキルを持っていないと気づかないでじわじわと時間と人的リソースを食い潰す。
これから新しいことを始めたいエンジニアが最初に読んでおくこと
やりたいとまでは思っても新しいことに手をつけられないエンジニアは多い。ある調査によれば(職業はエンジニアのみではなく、従業員)、継続的に学習をしている社会人は調査対象の12%ちょっとだという。
継続的の条件を除いても3割で、残りの7割は学習に時間を取り組んでいない。また興味深いことに、50%超は学習をしない『理由はない』と回答している。
あなたが給与を増やしたいなら、どうすればいいかこれで分かったはずだ。
ではどうやって12%ちょっとの方に行くか、である。
シンプルであるが少々難易度の高い話である。
先に、人が始めるまでには4つの段階があることを知っておこう。
- 対象を認知している
- 対象を理解している
- 対象の活動を始める
- 活動が定着している
第1段階は、エンジニアが何かしらの媒体、ネットや書店や口コミで良さそうな、自分の興味を持てるものがあると、知る状態を指す。視界にはいっただけでは認知にならない。興味を持ち、知った後でまた見かけたときに目が止まるまでになっていなければならない。
最近よく見かけるようになったな、聞くようになったなという状態までなっていなければならない。それは、自分になんらかのメリットを得られるように感じるとか、見た目で好みだと感じた、というようなもので良い。
第2段階は、メリットを感じられた対象の情報を集め始めたり、周囲に聞いてみたりする状態である。少し、自分のリソースを割いて、目にかなうかを確かめているステータスだ。ここで続けるか、やめるかを判断する。
第3段階は、実際に幾ばくかの投資、本を買ったり、ソフトウェアを買ったり、環境を作ったり、有償のイベントに参加したり、と対象に費用をかける。もちろん、無料でも構わない。でも、自分という人的リソースを使うので実質無料にはならない。自分の人的リソースを無料と考えるのは愚である。
第4段階は、その活動が定着している状態である。ここまでくると12%ちょっとの仲間入りである。
ところでどこが難しいのだろう。難しいとは、継続的な学習を始める際の壁になると捉えてもいい。
個人的には、第1段階の興味を引くところよりは、第2段階で自分で自分の興味を惹きつけるところではないかと思う。この第1段階から第2段階にステップアップするためには、自分で自分を焚きつける感じでやらないと興味、関心を持てないのではないか。
個人的には、この第2段階にするために、第1段階の認知力を上げておくことが大事なのだと考えている。
だから、気になる=認知し始めたとき、手間を掛けてリンクをクリックしたり、気になったキーワードを選択してgoogle検索したり、ブクマしたりしておく。理解の前の、認知候補を増やすのである。
その認知した中から、給与をあげる効果のあるテーマを選ぶ。給与をあげるのは、ロールをあげることだ。ロールの中に階段があるなら、登らないといけない。できることを増やす。
一つ、覚えていて欲しいのは、仕事で給与をあげるスキルを増やせばいいという考えはあなたの人生に責任を負わない組織やマネージャにスキルを増やす裁量を渡すことになるから、やってはいけない。