https://geechs-magazine.com/tag/tech/20160323
【SIer新人向け】研修では教えてくれないノウハウ集 - Qiita
「ようこそ 魔境 SIerへ！」 はじめに この記事は、SIer（Systems Integrator）に入ったシステム開発未経験者の新人さんたちへ送る、研修では教えてくれないノウハウ集です。 実際、弊社の長い研修では実務に使えそうなことをあまり教えてくれませんし、ノウハウは現場の人の頭にしかない状態なので、新人さんは暗中模索で仕事を覚えていくことになります。 それも非効率なので、実際に私が２年半1で失敗したこと、やってきてよかったこと（ノウハウ）を体系化したので共有します。 新人さんは、これを参考として、使えるところだけ今後の業務に持っていってください。 （本当はガッツリ社内向けに書いたものなので、一部汎用的でない表現がありますがご了承ください。） 目次 業務面 技術面 プライベート面 の三本柱でお送りします。 対象読者 SIerの1,2年目相当であり、学生時代に契約のあるシステム開発を
デスマーチが起きる理由 - ３つの指標
鳥のさえずり声を聞いて、私は悪態を吐いた。今日の早朝に予定されていたミーティングのことをすっかり忘れていたのだ。 まったく、最悪の朝だ。着替えている間に、電話も鳴った。「高い金を払ってコンサルタントを雇った極めて重要なミーティングだ」と念を押されていたというのに。 それもこれも昨日のバグのせいだ。睡眠時間も、開発スキルも、人員も、私の現場には何もかもが足りていない。 それにも関らず、理解の足りない上司は「テスト工程を削ってでも早く納品しろ」とプレッシャーを与えてくる。 あの馬鹿どもめ。一体何を考えているんだ？ スーツに着替え終わった私は、冷蔵庫の缶コーヒーで空腹を誤魔化すと、バイクに跨った。通勤時間が5分なのが、せめてもの救いだ。 「遅れてすまない」 そう言って会議室に入ると、奇妙なことに気がついた。教室のように整然と並んでいたはずの机が、即席の半円形に並べ替えられていた。 何より、ホワイ
マネジメントのポイントは "44 engineering management lessons" から学んだ - kakakakakku blog
今年は「組織変革」「組織マネジメント」「育成」あたりをテーマにした発表をしたり，ポッドキャストで話をしているので，最近は「マネジメント関連」で相談や質問を受ける機会が増えている．一言で表現すると？みたいに聞かれたときは 「愛情のある無茶振り」 って答えてはいるけど，そもそも一言で表現できるようなものじゃない． 44 engineering management lessons 今まで紹介したことはなかったけど，マネジメントの参考にしている “44 engineering management lessons” という記事がある．本当に大好きな記事で，記事の存在を知った2年前ぐらいから定期的に読み直すようにしている．タイトルの通り，44種類の原則が紹介されていて，大きく7種類に分類されている．どの原則も参考になるけど，その中でも特に好きなものをコメントを添えて紹介したいと思う（翻訳するわけで
計画する技術 - kakakakakku blog
今日は社内勉強会で「計画する技術」というタイトルで発表をした． 前から少し「計画」のところに課題感があって，そのあたりの知識を組織に広めて欲しいというオーダーもあったため，僕が日々考えていることを言語化して，発表することにした．僕は今までに様々な「計画」の経験があり，実際に今の組織でも難易度の高いプロジェクトを何度も計画し，遂行してきたため，「計画」に対する信頼残高は増えているのではないかと思う． 発表資料 意識したこと 今回，発表資料を作るときに意識したことが2個あった．他にも話したいことはたくさんあったけど，組織マネジメントの話はまた別でしようと思って，あくまで「計画」に特化した話にした． 明日からすぐに使える話をする 開発プロセスに依存しない話をする 1. 明日からすぐに使える話をする 原理原則すぎる話や，難しい法則の話は控えるようにした．そういう話をしてしまうと，その場では「おー，
プロジェクトをリードする技術 - kakakakakku blog
今日，社内勉強会で話す機会があり，過去1年間を振り返りつつ「プロジェクトをリードする技術」というタイトルにした．今回は参加者がエンジニアだけじゃなく，ビジネスチームのメンバーもいたため，できる限り，技術的な用語を使わないようにした．質疑応答とディスカッションもあり，1時間非常にワクワクした時間だった． 関連する領域 僕がプロジェクトをリードするときに意識しているのは，スクラムなど特定のプラクティスに依存しすぎないことで，チームの特性によって，関連する様々な領域からプラクティスを集めている．ザッと挙げるだけでも，こんなにたくさんある． チームビルディング ファシリテーション マネージメント 3.0 アジャイル (スクラム / カンバン / XP) 組織論 育成 心理学 メンタリング プロジェクトマネジメント 資料 過去1年間に取り組んだことを全て詰め込んだ！プレイングマネージャーとして頑張っ
増え続ける工数を変わらぬ人数で捌いていくフロムソフトウェアの方法論
2018年3月30日，大阪府・グランキューブ大阪で「Game Creators Conference '18」（GCC'18）が開催された。 GCC'18は関西発のゲーム業界向けゲーム開発カンファレンスだ。関西地区のゲーム企業有志による「勉強会」を母体としたイベントだったが，いまや4トラック24セッションという規模という一大イベントに成長している。地元である関西企業によるセッションのほかに，東京などからこのイベントのために多くの企業が参加している。 ここではそんなうちの一つであるフロムソフトウェアによる講演の模様を紹介してみたい。「複数タイトルの開発を維持しつつ大規模化に適応した中小企業エンジニアの取り組み」というタイトルの講演だが，「複数タイトルの開発を維持」「大規模化」といったあたりはちょっと見ただけでは意味が分からないかもしれない。 さて，フロムソフトウェアといえば，初代PlaySt
技術的負債のパターンと悪影響・原因・返却方法について考える - $shibayu36->blog;
先日飲み会で技術的負債についての雑談をしていた。結構いろいろな側面の話をしていたのだけど、技術的負債って一括りにしているのが今はあんまり良くなくて、負債の性質によって技術的奨学金、技術的FX、技術的年金などと言葉を変えると良いのではみたいな半分冗談で会話をしていた。 いろんな問題が技術的負債という一言にまとめられてしまっているので、負債の性質に合わせて、技術的奨学金、技術的FX、技術的年金、など用語を分けると良いのではないか、という話をした— 趣味はマリンスポーツです (@hitode909) 2018年3月27日 技術的負債について - hitode909の日記 それで技術的負債のパターンを見つけて、それによりどういう悪影響があるか、それがなぜ起こるのか、どう返却するかについて考えておくと良いのではと思ったので、今日思いついた3つのパターンをメモしておく。 思いついたパターンは3つ。 変
「エンジニアリング組織論への招待」はいろんな立場の人に読んで欲しい - $shibayu36->blog;
最近メンタリング制度のことや、技術組織のことについて興味がある。最近「エンジニアリング組織論への招待」という本が出版されて話題になっていたので読んでみた。 エンジニアリング組織論への招待 ~不確実性に向き合う思考と組織のリファクタリング 作者:広木 大地技術評論社Amazon この本は、エンジニアリングで重要なのは「どうしたら効率よく不確実性を減らしていけるのか」ということと述べている。その考え方に従って、思考方法、メンタリング、チーム運営、組織運営といったプログラミング以外でのやるべきことについて、様々な背景も含めて教えてくれる。 全部読んでみたところ本当に良い本であった。メンタリングや組織運営といった、なかなか汎用化や言語化がしにくい分野を、納得のできる形で言語化されていて本当にすごい。僕は最近はメンタリング制度について考えているので、特にChapter2のメンタリングの技術の章が一番
viron_20180201
CAMはエンタメコンテンツ、ビジネスバラエティメディア、ライフスタイルメディアを主軸に30以上のサービスを展開しています。エンタメコンテンツの分野では、国内外で圧倒的人気を誇るアーティストやアイドルグループとのパートナーシップを結び、オフィシャルファンサイトや動画関連サービスを運営しています。
管理職のためのエンジニア組織構築マニュアル | DevelopersIO
はじめに クラスメソッド株式会社 AWS事業部長の佐々木です。 私は前職で創業メンバーの1人としてビジネスを立ち上げた後、エンジニアとして実業務に携わりながら、統括マネージャーとして50人規模のエンジニア組織を構築しました。 また2014年にAWSエンジニアとしてクラスメソッドに入社し、2015年7月よりAWS事業部の部長に就任。事業は順調に拡大しており、2015年と比較して組織も2倍以上に大きくなりました。これは優秀な仲間に恵まれたのはもちろんのこと、組織設計と構築プランが功を奏したことも一因だと感じています。 そこで、私がこれまでに培ってきた経験から得たエンジニア組織の構築の仕方をお伝えしたいと思います。 エンジニア組織構築マニュアル 骨子を定義する これはエンジニア組織に限りませんが、組織には3つの骨子が必要です。 ポリシー ビジョン ターゲット ポリシーは、その組織が最もこだわる一
PM（Product Manager）って何やってるのか具体的な案件を見ながら説明してみる - freee Developers Hub
この記事は freee Developers Advent Calendar の17日目です。 自己紹介 freee 株式会社で、PM（Product Manager）をやっているfuji_tipです。 freeeに入ってから4年で、マーケティング/事業開発 —> データ分析 —> 事業戦略 —> PM という変遷で、社内ジョブホッパーです。フルスタック社員と自称しています。 趣味は飲酒です。 PMってなにやってるの 社内外から、PMって何やってるかわからない、どういう能力があればPMになれるのかわからないなどの声をもらうことが多いので、具体的な案件のリリースまでのプロセスを振り返りながら、PMの仕事について理解いただければと思います。 ある機能を作る！とか既存の機能改善をする！となったときの大体の流れを簡単に下記の通り説明します。 課題選定・ゴール設定 それが本当に課題なのか？課題だとし
エンジニアが「明日からマネジメントして」と言われたら
製品開発におけるマネジメントの全体感最初に結論エンジニアがマネジメント始める際には、↑のようにざっくり簡単にでいいので開発チームのマネジメントの全体像を掴んだうえで、自分がマネジメントするべき範囲を明確にして動くことをオススメしてみます。 以降、もう少し詳しく説明します。 なんで書こうと思ったかエンジニアにとってマネジメントとはなにか。突出した技術力を持った人というのがエンジニアでは花形なイメージが一般的にはあるでしょうし、マネジメントはエンジニア全員にとって必須科目ではありませんが、一定の経験、年齢、スキルになったら考えることだと思います。 しかし、エンジニアにとってマネジメントという言葉はとても曖昧。必須科目でない分、特定技術に関するものよりもずっとドキュメントや教材がすくなく、なにをやればいいかけっこうわかりにくい。 最近だとVP of Engineeringみたいなポジションがメジ
個人開発のWebサービスで、Trelloを使っていい感じに開発ロードマップを公開した話 - NOT SO BADなブログ
個人開発のWebサービスで、Trelloを使っていい感じに開発ロードマップを公開した話Sep 29, 2017 個人開発論Trello 個人で開発しているトーナメント表作成サービス「THE TOURNAMENT」で、今後の開発予定などを載せた開発ロードマップをTrelloで公開しました。 前から開発ロードマップは作りたかったのですが、なかなか作り方・運用をどうしたものか悩んでました。 今回Trelloを使ってみたらなかなかいい感じにできたので、やった内容をメモしてみます。 なんで開発ロードマップがほしかったかこれはいくつかあります。 サービスがちゃんと運営されてることを伝えたいまずはこれですね。 開発ロードマップがあると、死んだサービスじゃなくて、 ちゃんといまも積極的に機能追加されている生きたサービスですよってことが伝わるかなと。 Webサービスを探して使うときって、ちゃんと運営が安定し
チームリーダーをやるときに気をつけてた「4つの混ぜない」 - Mitsuyuki.Shiiba
開発チームのチームリーダーやってたときってどんなこと考えながらやってた？って相談があって、僕がチームリーダーやってたときはこういうことに気をつけてたよ。って話をした。今は僕はリーダーは後輩にまかせて、自分はシニアエンジニア的な立場でコードを書いたりウロウロしたりして楽しく過ごしてるんだけども。 4つの混ぜない やってるときは特に考えてなかったけど、今になって考えるとこういうこと気にしてたなーってのね。数は、単に4つ思い出した。ってだけ。 帽子を混ぜない エンジニア出身のチームリーダーって、こんな帽子をかぶってることが多いかな: 組織マネージャの帽子で 後輩の育成や組織としての成長を考えたり 開発リードの帽子で クオリティの最後の砦みたいな役割や、チームの外との調整をやったり プロジェクトマネージャの帽子で プロジェクトをどうやってうまく回していくかを考えたり なので「今の自分の気持ちはどの
開発運用チームを立て直した話 - 下町柚子黄昏記 by @yuzutas0
SPI Japan 2017というカンファレンスで発表をしました。 グロースフェーズの痛みの中で、いかに開発・運用チームを立て直したかという内容になります。 発表スライド 「Rebuild Team - 急成長プロダクトのDev&Opsで生じる悪循環とその解決策」 ここ最近の発表の集大成です。 急成長フェーズを体験した人は多くないはずなので、有用な知見ではないかと自負しています。 参加した感想 運営が非常に丁寧でした。選考通過時にはレビュアーから「こういう点が素晴らしい」とコメントいただき、また当日には司会者からフォローをいただき、非常に話しやすい場作りがなされていました。 一方で内容面については全体的に違和感を覚えました。もやもやです。 内容 思ったこと 補足事項 「改善施策が現場に受け入れられない」という意見が多かった 改善施策は現場の人が現場のために生み出すものではないか。 現場にメ
初転職4年間のまとめ、あるいはCTOを辞めたお話 - 考えた。
4年間務めた株式会社セプテーニ・オリジナル、およびコミックスマート株式会社を退職しました。役職はどちらもCTOでした。どなたかの役に立つことを願い、4年間の活動とその結果をまとめます。2014年。開発組織を作るためにやってみた事 と 2015〜2016年で開発組織を作るためにやってみたこと を最新結果と共にまとめた物になります。 前提：自分は何をやりたかったのか "高速で高品質な開発ができる組織を作りたかった"が一つ。これは前のエントリ技術的負債について考えたで詳しく述べています。 もう一つは "有名プロダクトも知名度もない会社で腐った開発をしてたら、採用ができないよの解決"です。採用は会社の生存には欠かせない重要な要素ですが、エンジニアにはセプテーニの知名度はほぼありませんし、GANMA!等を除けば基本的に社内向けのツール開発になります。その上で開発文化も残念な状態になってしまってはエン
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
バス因子が自分で バス因子を脱するための方法
急成長するサービスを支える DevOps 戦略と組織変革へのアプローチ / Approaches of DevOps and Organization
ぼくのかんがえたさいきょうの機械学習プロジェクト進行法（PoC/デモ編）
