転職ドラフトチームのおいちゃんこと @inouetakuya です。リブセンス アドベントカレンダー 2017 - テーマ「関」 の 25日目として、「賢い大人」問題について書きます。 なんだ、その「賢い大人」問題とやらは？というのを説明する前に、つい先日、僕がやらかした失敗から。 失敗談 チームの営業企画的なポジションの人が、僕を含むエンジニア 2人に、次のプロジェクトの開発の話を持ちかけてくれたときのこと。 彼女がプロジェクトの「説明」をしてくれて、僕たちエンジニアがいくつか「質問」した。 あなた vs 私たち わざわざ括弧を付けた箇所に注目してほしい。そう、これは「説明会」的なものの構図に似ている。言ってみれば「あなた vs 私たち」の構図。説明を受ける側と説明を聞く側。目指すべき「問題 vs 私たち」にはほど遠いものだった。 参考）問題 vs 私たち https://www.sli

ここ１ヶ月ぐらいは、海外のメンバーと仕事をしているが、Serverless Hackfest というイベントと、Serverless Conf やワークショップに関わっているので仕事量が増えていった。日本にいることだし、久々に「日本流」のハードワークをしてしまったのだが、一つ気づいたことがあった。それは、ここしばらくの謎だった、日本人のIT エンジニアはなぜイノベーティブな感じがしないのか？ということに対する問いだった。 Microsoft Hack week 日本人はイノベーティブ Rochelle Kopp さんとの仕事で知ったことで、一つとても意外だったことは、アメリカ人から見ると日本人は相当にイノベーティブに感じるらしい。 自分的には、少なくともIT 分野に関しては、向こうの真似ばかりしていて、後追いのイメージがある。私たちも向こうで生まれたツールやサービスばかり使っていて、全然日

Ever had an idea that seems impossible to realize? Or unexpected obstacles that seem too big to overcome? That’s where teamwork comes in. From space travel and climate change to bugs in code and remote... equipment requests, no task is impossible with the right team, apps, and practices. Join co-founders Mike Cannon-Brookes and Scott Farquhar to see how Atlassian can help your team achieve what’s

おしながき メンバーは3〜5名、協力企業は1〜2名の小規模チーム メインは某小売店の大規模ECサイト案件統括（開発は外部委託） サブで基幹連携等を担う周辺業務システム開発・運用 マネジメントが上手く回らず高残業が常態化。PM前任者異動に伴い、部下だった私にお鉢が回る 上長指示により残業削減へ そんな2〜3年前のお話です。 改善"前"のタスク運用 ※あくまで改善"前"の話です。 基本はRedmine + Kanbanプラグインでタスク（チケット）運用。 ナレッジ可視化の意識付けも目的の一つだったので、以下を徹底した。 作業に伴うタスク発行の徹底 進捗状況の逐次反映 そして、運用ルールの入念な教育（五十六メソッドを採用した） 当時はITSベースのタスク管理自体が社内で先進的な試みだったので、当時部下だった私もPMと協力して「できるだけ丁寧な運用」を心がけた。心がけた、のだが… おかしいな だれ

みなさんこんにちは。@ryuzeeです。 スプリントをずっと回していると、「いつもスプリントに追われている気がする」「一回立ち止まってゆっくり考えたい」「情報共有ができていない気がするので整理したい」「技術検証をもっとやりたい」「勉強時間をとりたい」といった話を聞くことがあります。 それに対して、どのように対処していくべきか考えてみましょう。 考えられる対応策はいくつもあるので、まずはそれを列挙します（ダメなものも混ざっています） 複数回スプリントを実施したら、1回分のスプリントでは開発チームは好きに活動する（✕）スプリントとスプリントの間に休憩を入れる（✕）フィーチャー開発以外の取り組みを行うスプリントを必要に応じて用意する（△）スプリントのキャパシティを見直して、開発チームが持続可能なペースで働けるようにする（◎）それぞれを順番に見ていきましょう。 複数回スプリントを実施したら、1回分

ツールに任せることができないどんなことを人間は指摘できるのだろうか？ 驚くほど多数の事柄があることがわかっている。この記事の残りで幅広い重要事項のリストに触れ、2つの特定の領域、パフォーマンスとセキュリティに関してはもう少し深く言及する。 設計 新しいコードは全体アーキテクチャに適合しているだろうか？ コードはSOLID原則、ドメイン駆動設計、もしくはチームが採用する他の設計手法に従っているだろうか？ 新しいコードでデザインパターンは使用されているだろうか？これらは適切だろうか？ コードベースの標準や設計スタイルが混合されている場合は、新しいコードは現在の原則に従っているだろうか？コードは現在の方向性を引き継いでいるか、徐々に除去される古いコードの例に従っているだろうか？ コードは正しい場所に配置されているだろうか？例えば、コードが注文に関係する場合は、それは注文サービスの中にあるだろうか

2017 - 07 - 30 長時間労働を解消したら優秀な人が来なくなった ブラック企業の代表例からホワイト企業の代表例へと変化したとあるSIerの話 業績はすこぶる好調、次なる課題は労働環境 実在する会社かどうかも含めて想像にお任せするが、ここでは仮にA社と呼んでおこう。 A社はインターネットの発展とともに急激に業績を伸ばしていった。月400時間という超長時間労働に支えられて非常に大きな会社へと発展していったのだ。 当時のA社に勤めていた人は「もらったストックオプションが結構な額になった」と喜んでいたり、「あのころは本当に寝られなかった」などと懐かしんでいたりする。 そうして発展したA社の経営陣は、東京に対して次のようなミッションを掲げたそうだ。 業績はとても好調だ。みんなとても良く頑張ってくれている。しかし、頑張りすぎて弊社がブラック企業呼ばわりされている。会社としてのイメージアップの

はじめに 今期から、クライアント企業の開発案件を抜けて、 企画、マーケティング含めた自社サービスのディレクションをすることになりました。 いわゆる社内外のサービス全般のなんでも屋さんでもあるため、 決まったタスクだけでなく臨時の依頼が割り込んだり、タスク管理が煩雑になりがち。 かといって、現在たった2名のチームで進めているので 堅苦しいタスク管理表とかはいらんだろ、、、(･Д･｀) そこで、Trelloを導入してみたので事例としてまとめておきます。 普通の開発プロジェクトで使う管理方法とはちょっと違うので、悪しからず。 Trelloとは 簡単にいえば、アジャイル開発だとかScrum開発だとか向けの、 チケット駆動に近いタスク管理ツールです。 公式サイトを読んでもわかりますが、 使い方をまとめている記事も多いのでざっと見てみると良し。 要するに、タスク管理から情報整理まで、いろいろできちゃう

A Brief Guide to Success with Agile Agile methods are solidly in the mainstream, but that popularity hasn't been without its problems. Organizational leaders are complaining that they’re not getting the benefits they expected. This article presents a fluency model that will help you get the most out of agile ideas. Fluency evolves through four distinct zones, each with its own benefits, required p

今回は、マイクロソフトにいて自分が感じているIT業界の大きなスタイルの変化の兆候とその対策について書いてみた。今回もいつも通り、単に自分の意見をシェアしているだけであって、他の人にどうこうしろと言いたいわけではない。ただ、日本のIT業界が米国に追いつき、追い越すための議論のきっかけになるといいなと思っている。自分も楽しみながらも、もがいていることと、そこで見えた光について書いてみたい。 世界は「技術力」の重視に向かっている 私のキャリアは、某大手SIerを12年勤めた後、ITコンサルティング企業に３年在籍して、主に超上流を実践した。その後独立し、ビジネスモデリングから、アジャイルや、DevOpsの導入支援、マネジメント、開発などを実施していた。 私がマイクロソフトを受けてみようと思ったのは、友人からの推薦の要素が大きかったのだが、その背景では、海外で勤務したいという希望があったのと、「技術

Shippai Night https://speee.connpass.com/event/46423/ 「クックパッドが失敗から学ぶために行っている取り組み」

ブログ記事『5分で分かるアジャイルムーブメントの歴史』を手がかりに、アジャイルムーブメントに関連する人や書籍に注目しながら、モダンアジャイルに至るまでのアジャイルムーブメントの歴史を辿ります。

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

こんにちは。アプリケーションエンジニアの id:itchynyです。 今回は、コードレビューを会話しながら行う取り組みについて紹介します。 コードレビューは大事なコミュニケーションの場です。 コードレビューの効用としては、単純なミスがあるコードをリリースしない・プロダクトのコードの品質をよりよくしていく、あるいはその方策を模索するといったことが挙げられます。 こういったことは当然のことですが、なによりもまず、レビューというのは一緒にプロダクトを作っている仲間とのコミュニケーションの場だと思います。 多くの人は、プロダクトのコードをよくしていきたい、読みやすいコードを書きたい、分かりやすいコードで目的の機能を作りたいといった共通の思いを持っていることでしょう。 コードを書いた人の思いを汲み取りながら、共感したり、譲歩したりしながら、よりよい方法を提示していきます。 それでも時には、どういうコ

はじめに このブログでは言及してませんでしたが、宣言どおり無事転職して、今年の1月から新宿のSIerで働いています。まぁその辺の話は来月あたりの暇な時にでも書くとして*1、今回は別の話。 ついこの間、その新会社で、PM的役割をこなす社員を対象に開かれた「法務研修」という名のついた社内セミナーに参加しました。内容は、SIerの立場で契約に携わる時にどうすべきか、というもの。SIerあるあるの契約にまつわる揉め事を事例に、それを回避するために何に気をつけるべきか、といったことが扱われました。まぁこれ自体は目新しい内容ではなく、SIerに所属する者なら当然知っておく・気をつけるべきことばかり。再確認という意味では非常に有意義でしたが、それ以上でもそれ以下でも無かったなぁ、というのがオレの率直な意見でした。……研修本編終了までは。 ちょっとこれ大丈夫か、と思ったのは、Q&Aに入ってから。社員の誰か

ここでは5つの世界における「パッケージ」の中でも「商用Webベースソフトウェア」、主に小・中規模での場合についての私見を述べます。なお、ここにおけるレガシーコードとはテストの無いコードや、不吉な臭いのするコードを指します。 人間の話 以下ではその規模毎に処方箋案を記載していますがその規模に関わらず、レガシーでありながらも苦痛を伴いながらもメンテナンスが行われているコードというものは、基本的には価値を生み出し続けてきた偉大なコードです。一般的にあなたが日曜日に書く最高にcoolなコードの、一万倍(※)以上の価値を会社や社会へ提供してきた偉大な存在であるというコードと作者への敬意は心のどこかに置いておきましょう。 また世の中には「作者とコードを完全に分けて考えられる人」「ある程度分けて考えられる人」「完全に自分の一部だと考えている人」の3種類がいます。つまりレガシーコードを痛烈に非難する時、6

この記事は、.NetRocksの1160話 No Estimates with Woody Zuillの書き取りと、日本語訳です。2015年7月2日放送。 使ったもの (tools used)：Express Scribe & Music to Code by 翻訳にあたってCarl Franklin氏の了承は頂きました。 リスナーの投稿とか、CarlとRichardのBetter Know Frameworkは飛ばして、ゲストインタビューのみ。 日本語化してない、英語音声書き取りメモは、まんまここにおいてます。 太字は訳者が、声の大きさとかスピードから、特に強調されていると思ったところです。これは主観なので、そう感じない人がいたらごめんなさい。 Carl Franklin（以下C）Woody は30年以上プログラミングやっていて、ハンター・インダストリーでアジャイル手法のコーチやアプリケ

この記事は、はてなエンジニアアドベントカレンダー2016の1日目の記事です。 8月よりCTOになりましたid:motemenです。たいそうな肩書きがつきましたが、引き続きチーフエンジニアという役職も兼任しており、これまでどおりアプリケーションを書きつつ、技術組織の開発・改善をおこなっています。 せっかくの機会なので、このエントリでは現時点でのはてなのエンジニア組織の概観と取り組みを紹介しようと思います。 技術グループ はてなにおいてエンジニアと呼ばれる職種の人は、それぞれが提供するサービス（ウェブサービス、スマートフォンアプリ、インフラなど）を軸とする開発本部に属しつつ、職能を軸とした横串の組織である「技術グループ」に所属する、という形態を採っています。現時点で、ここに属するのは40名強になっています。 会社を駆動させていくお金を生み出すのは造られたシステムであったり、営業活動であったりす

今回の記事ではエンジニアやIT業界ではすでに定着した感のあるポッドキャスト『rebuild.fm』の#123について触れてみたいと思う。 rebuild.fm いきなり横道にそれるが、podcastはランニング中や移動中に1.5倍速で流して聞けるのが便利。一方でメモがとれず終わった後にきちんと整理する時間を取らないと「要旨はなんだったのか」が曖昧になり自分に残らない感があるのが悩ましいですね。 今回のゲストである @naoya_itoさんが『エンジニアチームのリーダーシップ』というテーマについて『Fate/Zero』というアニメの11話「聖杯問答」になぞらえてうまく例えていた。 「聖杯問答」の内容について、超端的に言うと、世代を超えた3人の王が統治の仕方を論じ、民や臣に厚いタイプの王が大いなる野望を追いかけるタイプの王に負ける、という話。 趣旨：サーバントリーダーシップの是非 放送を通じた