「エンジニアリング組織論への招待」はいろんな立場の人に読んで欲しい - $shibayu36->blog;
最近メンタリング制度のことや、技術組織のことについて興味がある。最近「エンジニアリング組織論への招待」という本が出版されて話題になっていたので読んでみた。 エンジニアリング組織論への招待 ~不確実性に向き合う思考と組織のリファクタリング 作者:広木 大地技術評論社Amazon この本は、エンジニアリングで重要なのは「どうしたら効率よく不確実性を減らしていけるのか」ということと述べている。その考え方に従って、思考方法、メンタリング、チーム運営、組織運営といったプログラミング以外でのやるべきことについて、様々な背景も含めて教えてくれる。 全部読んでみたところ本当に良い本であった。メンタリングや組織運営といった、なかなか汎用化や言語化がしにくい分野を、納得のできる形で言語化されていて本当にすごい。僕は最近はメンタリング制度について考えているので、特にChapter2のメンタリングの技術の章が一番
CTOがチームマネージメントじゃない方向に向かう時に何をするべきなのか - トレタにおけるmasuidriveの役割 2017年版 - トレタ開発者ブログ
トレタ CTOの増井です。 トレタは創業して3年半、エンジニアも2名から13名に増え、私の役割も変わってきました。 当初は一人目のエンジニアとしてアプリの設計やサーバサイドのコードを書いたり運用全般を行っていました。 人数も増え、2年を過ぎたあたりからエンジニアリングの中で私が率先してやる必要のあることがほぼなくなってきました。むしろ海外展開で出張が増え、連続した時間がとれずに進捗を遅らせる原因になってしまうこともありました。 最近の論調では、メンバーが増えるとCTOはマネージメントや組織作りに移行して行くみたいですが、私はそっちに興味が全然なく、向いているとも思えませんでした。そもそも私は上司を持ったこともないし、決められた環境の中で働くのがとても苦手なので。 私が「組織を作って管理して行く」のは無理というのはトレタ設立当初から分かっていたことなので、メンバーを増やす時は「自分で目標を作
SREサイトリライアビリティエンジニアリングを読もう - yoshidashingo
セクションナイン の 吉田真吾（@yoshidashingo）です。 SRE本の原書が出てから早1年半が経ちました。原書はすでにオンラインで無料で読めるようになっています。 Google - Site Reliability Engineering 前回このブログでSREについて書いたのが、原書の出る1ヶ月くらい前ですね。 yoshidashingo.hatenablog.com 国内でもSRE部署の設置が急速に進んでますが、運用部門をSREと看板を掛け替えただけの劣化コピーが大量生産されていることも否めなかったりなかったり。 そもそもSREは、従来のシスアドではなくソフトウェアエンジニアです。そして、開発／運用の分断による必然的な対立関係をインセンティブ設計で統合し、サービスの成長と運用コストが比例しないように切り離すための組織設計であり、そのための技術ノウハウです。 今日は今週末発売さ
エンジニアリングや研究開発について思うこと - 人間とウェブの未来
エンジニアリングや研究開発について思うことをこれまで色々とツイートしたりしてきたが、それを改めて短編エッセイ集のようにまとめて整理し、自分の行動原理や思考を言語化して振り返っていた。以下目次。 基礎を学び古典を知る サーベイと評価の重要性 論文という学習と貢献を両立する手法 企業でのスペシャリストに求められるさらなるスキル 技術への深入りの効能 インフラエンジニアのキャリア再び 技術という真にフェアな領域 エンジニアへの動機付けと教育 知識をコードで表現する専門職としてのエンジニア 技術に対する思考 技術力の醸成による先行報酬 エンジニアのアウトプットと個人の実績 アカデミアか企業か家族か 楽しいことと貢献とその評価を重ねる 技術と自由 技術が目的 基礎を学び古典を知る 技術力を高めたい、成長したいという前提において、基礎を学ばずに発想で勝負などと、勉強もせずに過去の天才達とに渡り合うほど
2017年のエンジニアリング振り返り - ゆううきブログ
はてなに入社して4年経った。 入社4年成功https://t.co/p3DaJCO1Tq— ゆううき (@y_uuk1) 2017年12月2日 2017年のエンジニアリング活動を一言でまとめてみよう。 時系列データベースの開発にはじまり、なぜかIPSJ-ONEで登壇し、その後IPSJ-ONEでの構想をベースにはてなシステム構想を考え始め、ウェブサイエンス研究会でストーリーとしてまとめ上げつつ新たな可能性に気づき、それを実践していく場としてウェブシステムアーキテクチャ(WSA)研究会を立ち上げた。 一方で、仕事では、昨年の振り返りに書いているように、エンジニアとしての専門性を発揮する機会が薄れてきたという問題意識が、いよいよ深刻な課題へと変貌したように感じている。それも残念ながら自分一人だけの問題ではなくなってきた。 この課題をエンジニアリングそのものではなく、人間のスケールアウトでは解決で
人を集めたからといってすぐ機能するわけじゃないという話 | Ryuzee.com
アジャイル開発に取り組むチーム向けのコーチングや、技術顧問、認定スクラムマスター研修などの各種トレーニングを提供しています。ぜひお気軽にご相談ください（初回相談無料） 日々採用や組織がうまく動くように苦労しているみなさんこんにちは。@ryuzeeです。 ひとりで色々な物事を完結できればこんな楽なことはないのですが、特にシステム開発においてそのような規模のものは多くなく、たいていの場合複数人を集めてプロジェクトを遂行することになります。特に案件ベースで体制を作るシステムインテグレーターなんかを思い浮かべて頂くとわかりやすいかもしれません。 さて、そうやって集められた「人たち」はいきなりうまく機能して、プロジェクトのゴールに邁進できるようになるのでしょうか？というと残念ながら答えはノーです。 以下の図は、心理学者のタックマンが提唱する「タックマンモデル」と呼ばれるチーム(集団)の進化形態をあら
工場レイアウト設計の典型的問題と、そのエレガントな解決法 | タイム・コンサルタントの日誌から
工場見学ほど面白いものはない。なぜなら、工場はそれ自体が大きくて複雑なシステムそのものであり、そのシステム作りに各社独自の工夫も盲点も現れてくるからだ。——そういう意味のことを、これまで何度も書いてきた。また、すでにお知らせしたとおり、来る7月20日(水)に「生産革新フォーラム」（通称「MIF研」）で『上手な工場見学の見方・歩き方 〜エンジニアリング会社の視点から〜』というタイトルでお話ししたいのも、その点だ。だが、もう少し具体的に、わたしがよその工場を訪問したら、最初にどこを見るかについて書いてみたい。 ものづくりの方式やプロセスにはいろいろバリエーションがあるが、機械組立加工系を例にとると、だいたい次のような工順（工程順序）をふんでいる： 材料受入 → 部品加工 → 組立 → 検査 → 梱包出荷 この途中に通常、「在庫保管」も入るが、どこに入るかは工場の方針次第のため、ここでは省略して
最適解を組み合わせても、良い生産システムは作れない | タイム・コンサルタントの日誌から
先週の7月20日に「生産革新フォーラム」で行った講演『上手な工場見学の見方・歩き方 〜エンジニアリング会社の視点から〜』には、幸い大勢の方が来場され、このテーマに対する関心の高さをうかがうことができた。そして同時に、「工場設計」という重要な仕事に関する、世間での情報源の少なさも、あらためて再認識することになった。工場づくりのポイントを学びたいと思っても、世の中には殆ど教科書・参考書の類いがないのだ。 たとえば、前回も書いたとおり、機械組立加工系の工場レイアウトには、やっかいな典型的問題がある。それは上下動線の錯綜と分断の問題である。「材料受入→部品加工→組立→検査→梱包出荷」という工程の順序のうち、前半の部品加工はしばしば大型で重い機械設備が必要になり、後半の組立検査は人手中心の作業である。だから、敷地の制約で二階建て以上の工場を計画する場合、重い機械を要する部品加工工程を1階におき、組立
MITがSICPを教えなくなった理由
Programming by poking: why MIT stopped teaching SICP | posterior science このNYC Lisp meetupの動画で、Gerry Sussmanに対する質問として、SussmanとAbelsonの古典、The Structure and Interpretation of Computer Programs(SICP)に基づく、伝説的な6.001講義をなぜMITはやめたのかと聞かれている。 Sussmanの回答としては、SussmanとHal Abelsonは1980年代から延々と教え続けるに嫌気が差し、1997年に、学部長の事務所に行って、「俺らはやめる。後どうするからは勝手に考えろ」と宣言した。より重要なこととしては、SICPのカリキュラムは、今日のエンジニアリングに求められるエンジニアを育てることができないからで
就職して9年が過ぎる - 兼雑記
転職して7年が過ぎたというのを読んで気づいたんだけど、そろそろ入社後9年が経過したらしい。僕は結構長い期間をここで過ごしたことになるんだなと思った。ちょっと以前のことを振り返ってみようと思う。言うまでもないけどこれは僕の書ける範囲での個人的な感想と体験談であって会社の見解等を表しているものではない。 きっかけ わりと重要でない Borgチーム (の周辺) いつのまにやらBorgという名前を普通に言って良くなっている。嬉しい。まあ当時もぶっちゃけ、秘密だから出してないっていうよりは、単に誰もアカデミア的なキャリアに興味が無いから出してなかったんだと思う(私見)。 さて、当時Borgというかクラスタマネージメントのあたりでは、コンピュータのリソースて適当にたくさん使ってるけど、これ節約したらすっげー支出減ったりしない？みたいなのがホットで、なんかとりあえず色々な人々が色んなことをやっていた。い
エンジニアリングしたかったけどマネジメントになっていた
システムをエンジニアリングしたいな※１という思いが強い僕ですが、 気づいたらマネジメント的な部分※２を多くやっています。 というかチームビルディング的なところかもしれません。 なぜか 楽しいことがやりたいからです。 自分にとって楽しいなと思える環境ってなんだろうと考えました。 チームで同じ方向を見ること、良い雰囲気を持って開発をしていくことが重要です。 僕には本当に良いチームだと思えるチームで働いた経験があります。 SIの現場の1チームでしたが、後にも先にもあれ以上に良いと思えるチームはないです。 無いなら作るしかない 過去の経験から、良いチームで働くのは楽しいのは分かった。 しかし、なかなか良いチームには巡りあわない。 ならば作るしかない、という感じです。 待ってても良い環境は来ないと思うし、 そういうチームを作れるような人の周りに人は集まってくるのではないかなぁと思うのです。 おそらく
公式ドキュメントを読もう — みんなのウェディングエンジニアリングブログ
みんなのウェディングの高井です。 最近、若手のエンジニアと話をする機会が多くあります。そういった場で、ここが重要ですよと伝えたい話のうちのひとつがこの話になります。別のところに書いていたものですが、すこし手を入れた上で再掲します。 ハッカーの世界には昔から「RTFM」という言葉があります（参照）。ようするに「マニュアルを読め」という言葉なのですが、これはとても重要な言葉です。 色々な人によってブログにメモやノウハウが記載され、簡単に検索でみつかる世の中ではあります。また、そのためのサービスや技術的な質疑的な質問をすることのできるサービスも沢山あります。 しかし、検索サービスは、その内容が正しいことまで保証してくれません。見つかった記事の著者が誤解している場合もあれば、理解していない場合もあります。そして、ほとんどの場合は最新の情報ではありません。 マニュアルや公式ドキュメントであれば、それ
ここ一年の振り返り - Usual Software Engineer
先月、僕が開発のマネージャーを努めていたサービスがクローズになりました。 こんなに無力さを感じたことがあったでしょうか。 ただ、得られたことや感じたことは大きいので 最後の振り返りとして書き留めようと思います。 立ち上げ 思い切った新規開発でリリースまで辿り着けずにプロトタイプの段階で打ち止めになったプロジェクトから 一転して既存のリソースを流用して内製の開発チームをつくることになり 初めて採用の面接官側をやりました。 採用面接と一口に言っても、考慮しなければいけないことは多方面に渡っていて 結局はバランスをとって何を重視するか判断して決めることになりますが 非常に重要であり難しい問題です。良さそうと感じた人がうまくハマらなかったり、 おとなしそうだなと思っていた人がバリバリ仕事できたり。 ただ、少なくとも現場の人間と面接するのは必須だなと。 社風に合うかも大事なんだろうけれど、所属する予
ミスをエンジニアリングすることについて、例えばなぜ自動化するのかについて−−『「事務ミス」をナメるな！』を読んで - Line 1: Error: Invalid Blog('by Esehara' )
はじめに 今更いうことではないのだけれど、自分は凡ミスの多い人間だという自覚がある。例えば、このブログを書いていたとしても、結構な割合で「てにをは」を間違えることが多いし、また予定等を勘違いして、実は期日を過ぎていたということもある。 そういうこともあってか、「こういう単純な凡ミスを無くす」ことが出来ないかなと思って、本を手に取ったのだけど、いい意味で裏切られた。いい意味、というのは、その本のタイトルに反して、要するに「ミスをエンジニアリングするということがどういうことか」ということが書かれていたからだ。この本はタイトルで純粋に損しているとは思う。 個人において「ミスをする」ということはどういうことか 大抵、人間が何かをミスする場合、そのミスというのは無能であるか、あるいはうっかりといったような「能力の欠如」として捉えることが多い。しかし、本書の場合、それよりかは、むしろ「人間の知恵が働き
勤め人の子弟と、顧客ロイヤルティについて | タイム・コンサルタントの日誌から
横浜・妙蓮寺の中華点心舗「混江龍」は、わたしのひいきにしている店である。すべてテーブル席で、7、8人で満員になってしまうような、小ぢんまりした店を、店主が一人できりもりしている。しかし食べ物はどれも驚くほど美味しい。自然な材料を、余計な人工調味料など使わずに、一つ一つ丁寧に調理して出してくれる。この店は中華なのに、珍しくメニューに麺類がない（夏など、店主が気が向くと手打ちの冷やしそばを出してくれることはある）。客は普通、昼定食とか夕定食とかをたのむ。主菜に副菜、スープと漬け物、ごはんのセットで、料理の内容はその日の季節や素材を活かしたものだ。料理の質と価格の比から見て、横浜広しといえども、（超高級料理店でとんでもないお金を払うなら別だが）勤め人が気軽にいけるクラスでは一番お値打ちの店の一つだと、わたしは思う。 ところで今、勤め人という言葉を使ったが、これで思い出すことが一つある。わたしの息
ソフトウェアプロセス技術がロストテクノロジーになっている - きしだのHatena
最近会った人とよく話すのが、ソフトウェアプロセス技術がロストテクノロジーになってるんではないかということです。 ソフトウェアプロセスというのは、「プロセスがよいソフトウェアをつくる」という前提のもと、どのようなタイミングでどのような成果物を作り、どのような管理をし、どのように検査をしてソフトウェアを作るかという手順です。 そして、プロセス技術というのは、そのようなプロセスを構築し運用し改善する技術です。 このようなソフトウェアプロセス技術は、1995年くらいから2000年くらいにかけて盛り上がり広まりかけたのですが、そのタイミングでWebが広まりはじめ、「Webは進化が速い」「作るものがどんどん変わる」などを合言葉に、「アジャイルプロセスを採用する」という名目でなんら管理されないプロセスが普及しました。その結果、プロセス技術は完全に下火になっているように思います。 もちろん、Webの発展段
書類仕事を追いかけて - steps to phantasien
大きなコードベースの真ん中あたりをさわっていると、仕事の大半はリファクタリングに費やされる。機能を足そうと書くコードも 8 割リファクタリングで新緑は 2 割。失敗して捨てるものも多いから、かける時間は 9 対 1 くらいかもしれない。 それどころかリファクタリング自体がプロジェクトにもなりうる。「今四半期はこの腐ったコードどもをなんとかするのが目標」というように。私もいま大きなリファクタリング、あるいはリアーキテクティング、の手伝いをしている。仕事時間のほぼすべてがリファクタリングに費やされる。今の勤務先で通用する唯一の特技がリファクタリングな私にとってこれはたぶん適職だ。 リファクタリングにコーディングの大半を捧げる人は他にもいる。 プログラマ相手の管理職をエンジニアリング・マネージャと呼ぶ。ほぼ全員プログラマ出身。現場に近いマネージャは多くがコードも書く。ただ血気盛んな人を除くと新機
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
