管理職のためのエンジニア組織構築マニュアル | DevelopersIO
はじめに クラスメソッド株式会社 AWS事業部長の佐々木です。 私は前職で創業メンバーの1人としてビジネスを立ち上げた後、エンジニアとして実業務に携わりながら、統括マネージャーとして50人規模のエンジニア組織を構築しました。 また2014年にAWSエンジニアとしてクラスメソッドに入社し、2015年7月よりAWS事業部の部長に就任。事業は順調に拡大しており、2015年と比較して組織も2倍以上に大きくなりました。これは優秀な仲間に恵まれたのはもちろんのこと、組織設計と構築プランが功を奏したことも一因だと感じています。 そこで、私がこれまでに培ってきた経験から得たエンジニア組織の構築の仕方をお伝えしたいと思います。 エンジニア組織構築マニュアル 骨子を定義する これはエンジニア組織に限りませんが、組織には3つの骨子が必要です。 ポリシー ビジョン ターゲット ポリシーは、その組織が最もこだわる一
[IPA] デスマらないために「超上流から攻める IT 化の原理原則17ヶ条」が思った以上に使える件 [要件定義] | oshiire*BLOG
「超上流」という言葉自体はとても気に入らないけれども、IPA 独立行政法人 情報処理推進機構 が作って公開している「超上流から攻める IT 化の原理原則17ヶ条」が、当たり前のことを当たり前に並べてあってとても役に立つ。 原理原則 17箇条 ユーザとベンダの想いは相反する 取り決めは合意と承認によって成り立つ プロジェクトの成否を左右する要件確定の先送りは厳禁である ステークホルダ間の合意を得ないまま、次工程に入らない 多段階の見積りは双方のリスクを低減する システム化実現の費用はソフトウェア開発だけではない ライフサイクルコストを重視する システム化方針・狙いの周知徹底が成功の鍵となる 要件定義は発注者の責任である 要件定義書はバイブルであり、事あらばここへ立ち返るもの 優れた要件定義書とはシステム開発を精緻にあらわしたもの 表現されない要件はシステムとして実現されない 数値化されない要
![[IPA] デスマらないために「超上流から攻める IT 化の原理原則17ヶ条」が思った以上に使える件 [要件定義] | oshiire*BLOG](https://cdn-ak-scissors.b.st-hatena.com/image/square/bfb41ba2bfefb166491d5d3e83380136f2017ab2/height=288;version=1;width=512/http%3A%2F%2Foshiire.to%2Fwp-content%2Fuploads%2F2015%2F01%2F17principles-300x212.png)
なぜ開発で見積り失敗して忙しくなりがちなのか(アジャイルな見積りと計画づくり読んだ) - $shibayu36->blog;
最近タスクがどのくらいで終わるか見積もることが多いんだけど、そのたびにうまく見積もりができてなかったり、思ったより長引いてしまってすごく忙しくなってしまったり、といったことが何度かあった。このままじゃ良くないなーと思って、「アジャイルな見積りと計画づくり」を読んだ。 アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~ 作者:Mike Cohn,マイク コーン毎日コミュニケーションズAmazon 実際読んでみると今の状況に非常にぴったりで良い本だった。この本を読んでいくと、最初から正確な見積りをするのは不可能で、作業をしながら見積りの精度をあげるといったり、変更やリスクに強いスケジュールをうまく作るということをしていく必要があるということが分かる。なんとなく自分がタスク管理をしないといけなくなったけど、なんかうまくいかないと思っている人には非常に参考になると思う。あと
Í×·ïÄêµÁ¡¦´ðËÜÀß·× - µ»½Ñ¾ðÊóWiki
´ðËÜÀß·× † ¥·¥¹¥Æ¥à¤Î¥ê¥×¥ì¡¼¥¹°Æ·ï¤¬ºÇ¤â´í¸±¤ÊÍýͳ 2008.2.24 ±¿ÍѤ·¤Æ¤¤¤¯¤¦¤Á¤Ë¡¢¥Ð¥°¥Õ¥£¥Ã¥¯¥¹¤äµ¡Ç½Äɲäǡ¢¶²Îµ¤Î¤è¤¦¤ËÇϼ¯¤Ç¤«¤¯¤Ê¤Ã¤¿Ãæ¿È¤Ï¡¢ºÇ¿·¤Î¥ª¥Ö¥¸¥§¥¯¥È»Ø¸þ¸À¸ì¤Ç¡¢Æ±¤¸¤è¤¦¤Ë¤¿¤¯¤µ¤ó¤Î¥Ð¥°¥Õ¥£¥Ã¥¯¥¹¤ò½Å¤Í¤ÆÀѤ߾夲¤¿¤â¤Î¤ËÊѤï¤ë¡£ Ʊ¤¸¥½¡¼¥¹¥³¡¼¥É¤ÎÃÇÊҤϰì¤Ä¤â¤Ê¤¤¤Ï¤º¡£ ¥×¥í¥°¥é¥à¤ÎÊݼéÀ¤ä°Ü¿¢À¡¢ºÆÍøÍÑÀ¤¬¡¢¤É¤Î»þÂå¤Ë¤Ê¤Ã¤Æ¤â¡¢¸À¸ì¤¬¤¤¤¯¤éȯŸ¤·¤Æ¤âÆñ¤·¤¤¤³¤È¡£ Æä˺ÆÍøÍÑÀ¤Ï¡¢¤½¤Î¥
[Think IT] 第1回：アクティビティ図を学ぼう！ (3/3)
【伝わる！モデリング】はじめようUML！ 第1回：アクティビティ図を学ぼう！ 著者：株式会社テクノロジックアート 長瀬 嘉秀 公開日：2008/04/01（火） 業務分析 はじめに業務分析として、業務の流れを整理していきます。 業務の流れは以前から業務フローと呼ばれていて、情報システムを構築する際には、大抵作成されていました。しかし、標準化された表記方法ではなく、コンピュータのディスクや帳票などのシステム構成も混ぜてしまった図を作っていたのが実情です。 通常、業務を整理している段階では、どこをシステム化すればよいかを検討します。しかし以前の状況は、システム化するための資料の作成段階で、すでに導入するシステムが決まっているという、おかしな話になっていました。さらに、流れは役割ごとに整理するべきですが、従来の業務フローではきちんとされていませんでした。 また、UML以外の表記としてはIDEF（
[ThinkIT] 第1回：開発ドキュメント体系と業務フロー (1/4)
ソフトウェア業界の仕事は、下請け・孫請けのピラミッド構成となることが多く、常駐・派遣型のビジネスがかなりのパーセンテージを占めています。そんな中、他の業界と同じように、下請け脱却を目指して"一括請負"で仕事を引き受けたいとする会社もあります。 その志は善しとしましょう。しかし、肝心の"実力"が伴っていないと発注者も受託者もお互いに手痛い目に遭います。ここで言う"実力"とは、単なる技術力のことではありません。スケジュール管理や品質管理、コスト管理などのプロジェクト管理の技術・体制を社内で持っているかどうかが成否の鍵となるのです。 筆者の会社は創立11年目なのですが、創業以来「常駐・派遣の仕事はやらない！」という起業時のポリシーを貫いて来ました。C/SやWebのシステム開発を主体としているのですが、10年間の中では当然（？）、いくつかの失敗プロジェクトもありました。その苦い経験の中で「成功率と
オブジェクト指向なコマンド環境「Powershell」を試してみた - てっく煮ブログ
Microsoft 製の最新のコマンドライン環境「Powershell」が面白かったので、楽しいところをまとめてみた。UNIX な人にも使いやすい親切設計コマンドプロンプトでファイル列挙と言えば dir だけど、Powershell では ls も使える。 PS> ls Directory: Microsoft.PowerShell.Core\FileSystem::C:\ Documents and Settings\nitoyon Mode LastWriteTime Length Name ---- ------------- ------ ---- d---s 2006/02/19 22:35 Cookies d-r-- 2006/02/17 23:39 Favorites d-r-- 2006/02/19 18:56 My Documents d-r-- 2004/08/19 9
上流工程-要件定義---目次：ITpro
NVIDIAの時価総額が526兆円で世界首位に、生成AIが促す11年ぶりの地殻変動 2024.06.19
いつの間にか増えてしまったサーバ台数を減らしたい － ＠IT
【ITインフラ】【サーバ】【仮想化】 いつの間にか増えてしまった サーバ台数を減らしたい 三木 泉 ＠IT編集部 2009/10/1 小さい会社なのに、各部署で別々にサーバ機を導入しているうちに、多数に膨れ上がってしまった。各部署ではPCをサーバ機の代わりに使っているケースも多い。これらのコンピュータは机の下など、あまりいい環境に置かれていないし、何よりも管理が行き届かない状況だ。サーバ仮想化でサーバ機を少数にまとめられると聞いたが、どうすればいいのだろうか。 サーバ仮想化は、増えてしまったサーバ機を少数にまとめるには非常に便利な技術です。しかも、小規模環境での利用なら低コストで始められます。 サーバ仮想化が実現することは、まずサーバ機にカバーをかぶせるような形で本来のハードウェア（チップセットやネットワークアダプタ、ストレージなど）を隠して標準的な単一のハードウェアとして見せることです。
機能一覧表とI/O関連図
システム開発の仕事では、仕様の追加や変更は日常茶飯事です。「これで仕様凍結！と宣言して、仕様変更を受け付けなければ良い」などとこちらの勝手を言う人もいますが、事はそう簡単にはいきません（安易な変更を抑制する効果はありますが…）。現実的にはその仕様のままじゃ動かなかったりするので、ある程度の追加・変更はあるものと覚悟しておく必要があります。 社会においても「警察官や教師は、不正があってはならない」というタテマエにとらわれて対策を打たないことが問題視されています。「彼らも不正行為を犯す」という前提に立って対処方法を定めておくべきというのが現代の常識です。同じように、仕様変更も発生し得るという前提に立ち、それを吸収しながらプロジェクトを成功させるという柔軟な姿勢が重要なのです。 常駐・派遣ベースでは、変更が生じてもリスク（コストやスケジュール）は基本的に相手側にあります。しかし、請負で仕事をする
効率の良いコードレビュー [software]
とある友人が紹介してくれた，「苦痛を伴なわない効率の良いコードレビュー」という記事．なかなか良いことが書いてある． Effective Code Reviews Without the Pain 特に，コードレビューには，1) コードの品質を保証する，2) 開発者を教育する，という2つの目的があると前置きした上で，コードレビューに対するアプローチに言及している点がおもしろい． 1) 物事を断定するのではなく，質問を投げかけるようにすること 2) 「なぜ?」という質問を避けること 3) 褒めることを忘れないように 4) コーディングルールが確立されていること 5) 議論の対象はあくまでもコード，決してコーダー (開発者) になってはいけない 6) 解決方法は1つだけではないことを念頭に そしてもしあなたが開発者ならば， 1) コードがあなた自身ではないことを忘れないように 2) 自分用のチェ
いい仕事をするためのたった一つの心得 - 「美しい」から「かっこいい」へ : 404 Blog Not Found
2009年05月11日12:30 カテゴリArt いい仕事をするためのたった一つの心得 - 「美しい」から「かっこいい」へ ありゃ。流れ弾:) きれいなソースコードを書くために必要な、たったひとつの単純な事 - よくわかりません なお、一般的な「きれいな」ソースコードの最重要事項として正しい名前を挙げたけど、もう一段上の「美しい」コードについてはハッカー達の濃い思いをじっくり味わうのもよいかも知れない。「きれいな」と「美しい」の違いとかは、danさんが書いてくれる事を期待。 名前に関しては別entryをあてることにして、「美しい」について書くことにする。 ここ20年ほどで、じわじわと強くなり、特にblogを書き始めてから強くなっているのが、これ。 かっこつけろ これだけ、たったこれだけ意識すれば、どんどん「仕事」が出来るようになる。「仕事」いっても「賃金労働」だけじゃない。中国語で言うとこ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
単体テスト計画書 （1） ― 表紙・目次・第1部・第1章