Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 近頃の世の中の流れは恐ろしい。全業種ソフトウェア企業にならないと競争力が維持できない。 “寝たときは製造業、朝起きたらソフトウェア企業” by Werner Vogels（CTO, Amazon.com）at AWS re:Invent 2017 Key Note という恐ろしい話は管理職に落ちてくるので、「寝たときは製造業のマネージャ、朝起きたらソフトウェア企業のマネージャ」になれるのか？を考え始めるべきです。 元銀行員で非エンジニアで、いつのまにか開発ツールベンダーにどっぷりの私の経験からのTips を共有します。 エンジニアの方は

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 弊社に５年間在籍していたロシアの天才ハッカーが先日退職しました。 ハッキング世界大会優勝の経歴を持ち、テレビ出演の経験もある彼ですが、正直こんなに長く活躍してくれるとは思っていませんでした。彼のようなタレントが入社した場合、得てして日本の大企業にありがちな官僚主義に辟易してすぐに退職するか、もしくはマスコットキャラとして落ち着くかのどちらかのケースがほとんどなのですが、彼は最後まで現場の第一線で活躍してくれました。 そんな彼が最後に残していった退職メールがなかなか印象的だったので、その拙訳をここに掲載します（転載について本人同意済み。弊

テスト計画をどう立てていくか、ふつうのシステムエンジニアにとって分かりやすく考えてみたいと思います。 テスト工程は、一番ざっくりした分類で単体テスト、結合テスト、システムテストに別れるのが一般的です。 この工程は、あくまでもV字モデルに対応したインプットがどの前工程で作られたものを検証するかの基準であって、実際にどういう観点をどういう手順でテストするか、はそれぞれのプロジェクトで計画します。それがテスト計画になっていきます。 しかし、ただの工程の話と、実際におこなうテストの内容の違いが分かっていないと、テスト計画何するものぞ状態になって、ろくなテストが実施されないことになりますし、そのようなプロジェクトも多く存在します。 テストの世界標準には、ISO/IEC/IEEE 29119があり、これを見るとテスト工程(Test Level/Phase)とテスト種別(Test Types)の組で、テ

この半年間、久しぶりに開発チームのマネージャ的な立場もやることになったので、「ふつうの受託開発チームのつくりかた」以来、工夫したことをまとめておきます。「ふつうの受託開発チームのつくりかた」未見のかたはぜひそちらも見てみてください! チームに名前を付ける 私の受け持つチームは伝統的に「ラスカル」の名を付けるようにし、チームのアイデンティティを保つようにしています。チームメンバも本当は出来るだけ長く担当してもらいたいのですが、大きなSIerだとそれが難しいこともあります。 通常のプロジェクトチームだと、サブシステム名くらいで呼ばれることでしょう。これは、そのプロジェクトが終わったらチームも終わり、で帰る場所も無くなることを意味しますし、愛着をもって働くことは難しくなります。 メンバが多少入れ替わっても、チームは継続する"モーニング娘。方式"であれば、またいつか戻ってくることもできるし、OBと

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 前置き 私のキャリアは少し変わっています。 この業界に新卒で入ってから十数年は、大手ゼネコン的SIerにて、ほぼ一貫してプロジェクトマネジメントをやってきました。最終的には100人月程度の案件を回していたので、中堅クラスではあったと思います。それなりに経験も積んだとは思いますが、あれ、そもそも私って人の管理をやるためにIT業界に入ったんだっけ。。というレーゾンテートル的な理由で、プログラマーに転身しました。 そんなわけで、おそらく日本のIT業界におけるプログラマーから管理職に至るという一般的なキャリアパスを逆行している形になります。 そ

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 私は昨年７月からサンフランシスコにあるAsanaという会社でエンジニアをしています。アメリカの大学でComputer Scienceを専攻し、昨年卒業しました。 エンジニアを指導する立場の人こそ読んでほしい、新卒エンジニアが1年間で上司に感じた５つのことの著者と私は新卒エンジニアで１年経ったところという境遇が似ている一方で、私は上述の記事に書かれているような不満を一度たりとも感じたことがありません。 この記事では、H_Craneさんの５つの上司に対する不満点と対比して、私がこの１年間で感じたAsanaの良い点を５つ列挙することで、どうい

#はじめに 「会議だけで一日終わっちゃったよ・・・」と言うワードを聞く頻度が増えました。 前々から、会議なんとかしたいなぁと思いつつも、どうやればいいのかな？ってのをいまいち理解できていなかった＆良い機会なので、ちょっと力入れて調べ/考えてみました。 #結論 まず結論を述べておきます。たった2点です。 1.「適切な振り返り」を行うこと 適切な振り返りとは、「基準を明確にし、測定し、データに基づいた振り返りを行うこと」。 そして、この「適切な振り返り」は、会議だけに留まらせず、基本的な仕事のスタンスにさせていくこと。 2.日頃からチーム力を上げておくこと 人間心理として、会議に対する心理的負荷は大きい。心理的負荷を下げ、効果的な会議を行うには、日頃からチーム力を上げておくことが効果的である。 チーム力を上げるには、「心理的安全性（チームのメンバー一人ひとりがそのチームに対して、気兼ねなく発言

「呆れるほど儲かっている会社」って世の中にはありますよね。 そんな会社で働いてる課長さんてどんなタイプか興味ありませんか？ 会社が恐ろしいほど儲けるためには様々なファクターが考えられますが、やはり一番のキーは「ヒト」それもマネージャー（管理職）の存在ではないでしょうか？ 以前私はこの記事で「こんなマネージャーが会社を潰す」というまとめをやりました。 ↓↓↓ hikarujinzai.hatenablog.com この記事を公開した当時も多くの方にブックマークしていただき、いまだに私の記事の中でPV数が常にベスト10に入っている人気記事です。 マネージャー像に対してみなさんの関心がいかに高いかがよくわかります。 当時の「会社を潰すマネージャーのタイプ」を振り返ると... プレーヤーから脱皮できず手柄を上げることに腐心する 自分に都合の良い部下だけを信頼し重用し集中して仕事を任せる 自分の考え

Inc.：長年にわたり、Googleは数え切れないほどの研究に取り組み、膨大なデータを集め、何百万ドルもをつぎ込んで自社の従業員をより良く理解しようと努めてきました。Googleの最も興味深い取り組みの1つであるプロジェクト・アリストテレス（Project Aristotle）は、社内で最高の業績をあげているチームに焦点を当て、チームの生産性を高める秘訣を探ろうというものでした。 なかでも、生産性の高いチームと低いチームの違いは何なのか？ を解明することに主眼が置かれました。 この調査をはじめる前、Googleの経営陣は、ほかの多くの組織と同じように、最高のチームをつくるということは、最高の人材を集めることであると信じていました。それは理にかなった考えです。最高のエンジニアに、MBA、博士を集めれば、最高のチームのでき上がり。そうですよね？ しかし、Googleの人事分析マネージャ、Jul

＼閉鎖予定のサイトも売れるかも？／ アクセスがないサイトもコンテンツ価値で売れる場合も… ドメインの有効期限を更新してサイト売却にトライしてみましょう

「お前は向いていないんじゃない、やってないだけだ」 この一文を読んでほんの少しでもなにかを感じた人は是非とも↓の本を今すぐに読むべきだ。 エラスティックリーダーシップ ―自己組織化チームの育て方 作者: Roy Osherove,島田浩二出版社/メーカー: オライリージャパン発売日: 2017/05/13メディア: 単行本（ソフトカバー）この商品を含むブログ (1件) を見る 本著はみんなが考え、感じているリーダーシップという曖昧模糊な概念に対して具体性をもたらせてくれる。 それは「チームリーダーの役割は優れた人材が育つのを助けること」と定義付けていることだ。 このシンプルである意味で本質をついている定義付けが本著を名書たらしめているとぼくは思う。 この本の構成は1部〜4部(おおよそ本書の半分ほどを占めている)までが著者によるリーダーシップとはなにか？3つのフェーズの分類とそのときに期待さ

オープンセミナー2017@岡山での発表スライドです

タスク管理が終わってますね はい。僕もそうでしたし、そもそも「タスク管理」あるいは「スケジュール管理」というのは「定めた通りきちんと実行する」というところまでワンセットになった概念ですから、完璧にやれているということは人生がほぼほぼ予定通りに運んでいるということになります。おそらく、そういう人はほとんどいないでしょう。「やるぞー」と決めてクソデカい手帳を買ったり、スマホにモリモリアプリをインストールしたりは誰もがしたでしょうが、それが実になったことがある人はかなり少ないと思います。 ツールを購入したり、あるいは「やるぞ」と決めた日から数日くらいはどんどんタスクを入力していくでしょうが、次第に未消化タスクが積みあがっていき、しかも新規タスクの書き込みは徐々に行われなくなっていったのではないでしょうか。 こうして考えると、タスク管理というものには実に様々な要素が求められることがわかります。すぐ

何度か書いていますが、しんざきはシステム関係の仕事をしており、今はそんな大きくないチームの責任者です。自分でも色々作業しますが、一応マネジメントもする立場です。 今とはまた違うチームにいた頃、チームの統合・再編成が行われたことが何回かありました。 チームメンバーは増えたり減ったりしますが、大体毎度、新しいメンバーを何人かは見ることになります。 当たり前のことですが、知らないメンバーと一緒にやっていく際には、まずその人にどんなタスクを振るか、どうタスクを振るかを考えないといけません。 何か新しい技術に触れていくならどのようにスキルのキャッチアップをしてもらうか考えないといけませんし、引き継ぎがあるなら引き継ぎの計画を立てなくてはいけません。 だからチームの再編成の時には、本格的に仕事を始める前に、それぞれのメンバー、及びそれぞれのメンバーの以前の上司に必ず面談とヒアリングをします。いや、別に

今日は社内勉強会で「計画する技術」というタイトルで発表をした． 前から少し「計画」のところに課題感があって，そのあたりの知識を組織に広めて欲しいというオーダーもあったため，僕が日々考えていることを言語化して，発表することにした．僕は今までに様々な「計画」の経験があり，実際に今の組織でも難易度の高いプロジェクトを何度も計画し，遂行してきたため，「計画」に対する信頼残高は増えているのではないかと思う． 発表資料 意識したこと 今回，発表資料を作るときに意識したことが2個あった．他にも話したいことはたくさんあったけど，組織マネジメントの話はまた別でしようと思って，あくまで「計画」に特化した話にした． 明日からすぐに使える話をする 開発プロセスに依存しない話をする 1. 明日からすぐに使える話をする 原理原則すぎる話や，難しい法則の話は控えるようにした．そういう話をしてしまうと，その場では「おー，

補足を以下に記載しています: https://www.wantedly.com/companies/ikyu/post_articles/42802

スタートアップの企業文化 (Startup Culture) についてのスライドです。 企業文化やビジョンをスタートアップの初期から気にするべきかどうかは悩ましいところですが、Y Combinator の Jessica Livingston のいうとおり、企業文化はその設立当初から自然と育っていってしまうものだなと 2, 3 人のスタートアップを見てても思います。であれば、初期から考えるためのある程度の情報はあっても良いのかなと思い、今回スライドをまとめました。 企業文化はかなりソフトな概念なので、そもそも把握しづらい上に何が良くて何が悪いのかも分かりにくく、さらに簡単に変えたり作り上げたりできるものではありません。それに加えて、良い（望ましい、心地の良い）企業文化があるからといって、その企業の成功が約束されるわけではありません。 ただ様々な研究を見てみても、良い企業文化は生産性向上や採

▼ [雑] 「第2回 エンジニアリングマネージャー勉強会」に参加してきた 開催前に Twitter か Facebook で見かけて「お？」と思って参加ボタンをポチっとした、「第2回 エンジニアリングマネージャー勉強会」に参加してきた。 いま、会社でのオレのポジションは、無印の「ソフトウェアエンジニア」であって、「エンジニアリングマネージャ（EM）」という立場ではない。でも、開催ページに参加条件として次のように書いてあった。 下記の経験をお持ちの方に制限させていただきます。(アンケートにご回答お願い致します) ・メンバーの育成、新卒のメンター経験がある ・エンジニアリングチームリーダー、プロジェクトリーダー 過去の会社ではそういうこともやっていたので、セーフだろう。 これまで「エンジニアリングマネージャ」を軸とした勉強会には参加したことがなかったのだけど、行ってみたら会場は満員。やっぱりこ

Spring BootによるAPIバックエンド構築実践ガイド 第2版 何千人もの開発者が、InfoQのミニブック「Practical Guide to Building an API Back End with Spring Boot」から、Spring Bootを使ったREST API構築の基礎を学んだ。この本では、出版時に新しくリリースされたバージョンである Spring Boot 2 を使用している。しかし、Spring Boot3が最近リリースされ、重要な変...