エンジニアが納期を守れていないとしたら、そこにはいったい何があるのだろう？（あるいはいったい何がないのだろう？）XP 祭り 2016
夏休みの宿題進捗管理をIT化したら子供が凄くやる気出した話
長男(今年9歳)が通っている学校は、かなり宿題が多い学校のようで、低学年でもそれなりの量の宿題が出ます。当然、夏休みの宿題も結構な量です。 長男は、普段の勉強については特に苦労をしていないようですが、やはり小学生であって、計画的に宿題をするのは苦手です。 一年生の時の夏休みの宿題も、結局すべて片づけるのはかなりギリギリになっていたようで、8月下旬くらいに泣きべそをかきながら宿題をやっているのを観測しました。 小学校の宿題に親が口出しするのもどうかなと思いまして、一年の頃はあまり干渉しなかったんですが、ちょっとそれを見て反省というか、考えを改めました。 宿題の本来の意味は、「家庭での勉強の習慣を作ること」だと思います。それが機能しないばかりか、単に嫌な思い出ばかりになってしまい、机に向かうこと自体がイヤになってしまったら可哀想だなーと思ったからです。 そこで、2015年の夏休みは、多少干渉し
今どきの若手育成にひそむ3つの思いこみ
2016年4月13日に六本木Super Deluxeで開催されたIT/Webエンジニア向けイベント「TechLION vol.25」（http://techlion.jp/vol25）に出演した際の講演スライドです。 持ち時間20分ということで、以前にシェアしたスライド「効果が出る仕事の教え方」を本題の演目と捉えて、そこに入る前のマクラとしてお話をまとめました。 ※直接対面でお話しする前提で作ったスライドなので、スライドだけ見てもいまいち伝わりづらい部分、誤解釈させてしまうリスクもあって、内心こわごわの共有ですが、いくらかでも、つまんでお役立ていただけるところがあれば嬉しいです。 出演後の後書きをブログにまとめましたので、よろしければあわせてご覧ください。 TechLION出演の後書き┃心のうち http://hysmrk.cocolog-nifty.com/blog/2016/04/te
物理サーバを選定する際のポイント – Eureka Engineering – Medium
Eureka EngineeringLearn about Eureka’s engineering efforts, product developments and more.
プロダクトマネージャーについて - naoyaのはてなダイアリー
Twitter でプロダクトマネージャーについてぶつぶつ呟いていたら、まとめられていました。ありがとうございます。 プロダクトマネージャー制度を導入するにはどうすれば良いのか プロダクトマネージャーについてあれこれ考えていることを、ここらで一旦整理する良い機会かなとも思いましたので、ちょっと文章をこさえてみることにしました。一年ぶりにブログでも書いてみようと思います。 プロダクトマネージャーはユニコーンなのか。なぜそれが必要なのか。プロダクトマネージャーを見つける / 組織で制度化するとはどういうことなのか。それについて自分の考えを述べていこうと思います。 プロダクトマネージャーは新しいユニコーンか? 昨今よくプロダクトマネージャーが話題になっていますが、人によっては「プロダクトマネージャー」 が今自分たちができないことを象徴している/それが登場すれば全てが解決する銀の弾丸的なもの･･･い
IPAが「IT人材白書2015」を発行。国内のIT系人材は約112万人、IT企業の人手不足が生じる構造の分析など
IPAが「IT人材白書2015」を発行。国内のIT系人材は約112万人、IT企業の人手不足が生じる構造の分析など IPA（独立行政法人情報処理推進機構）は、国内のIT系人材の最新動向を示す「IT系人材白書2015」の発行を発表しました。 IT系人材白書2015は、2014年10月に876社のIT企業、587社のユーザー企業、257の大学や大学院、高等専門学校などの学科、約2500名の個人などから寄せられた調査結果を基にまとめたもの。PDF版を無料でダウンロード可能です。 以下はその一部を抜粋したもの。 国内のIT人材は推計111万8000人 まずIT系企業（IT提供側）におけるIT人材を推計すると84万1000人で、内訳はシステムアーキテクトが約5万4000人、プロジェクトマネージャが約11万5000人、インフラ系技術者が7万3000人、アプリ系技術者が34万人など。 一方、ユーザー企業（
第1回ペパボテックカンファレンス参加レポート - りあるふぁいとぷろぐらまー
渋谷のセルリアンタワーGMO Yoursにて第1回ペパボテックカンファレンスが開催されたので、参加レポートです。 開会の辞 なぜ、開いたか あんちぽくんさんより 色んな会社が自社のテックカンファレンスをやっているので、やってみたかった 領域が広い → 普段やっていることを話せば面白いかも これからのペパボの技術 by あんちぽくんさん speakerdeck.com ペパボがなにを考え思いエンジニアリングしているのか これからどうエンジニアリングするのかを話していく これまでやってきたこと 技術基盤の改善 基本事業部制で縦割りだったのを技術基盤チームを作ったことで横につなげた 技術的な改善&エンジニアが言うことを聞き入れてくれる組織作り CTOとは 経営をすることのみ それ以外はない 経営の中で技術を担う 今後の技術的展望 １.マイクロサービシーズ化 色んな言語で細分化して小回りがきくよう
チケット管理システム大決戦 JIRA vs Redmine vs Trac ユーザーが語る、なぜ私はこのツールを使うのか
チケット管理システム大決戦 JIRA vs Redmine vs Trac ユーザーが語る、なぜ私はこのツールを使うのか
SIerの余命は5年、オオカミは本当にやって来る
どうも私はIT業界の人たちから、オオカミ少年だと思われているらしい。随分前から「SI（システムインテグレーション）ビジネスの終焉」を騒ぎ立てていたが、SIビジネスは幾多の不況期を乗り越え、しぶとく生き残ってきた。だから私がオオカミ少年だと言われるのは、まあ仕方が無い。だが、あえてまた言う。「今度は本当にオオカミがやって来る」。SIerの余命はあと5年である。 SIビジネスはユーザー企業などからシステム構築を請け負う人月商売だが、日本では“SIガラパゴス”と呼ぶ、世界に類を見ない多重下請け構造のエコシステム（生態系）を発達させてきた。このSIガラパゴスには、零細ベンダーも含めると約1万5000社がひしめき、元請けのSIerを頂点に、顧客である企業や公共機関のシステム構築に関するあらゆるニーズ（≒わがまま）に対応してきた。 これは、システム構築ではERP（統合基幹業務システム）をそのまま使った
スラッシュドットに聞け：ソフトウェア開発の現場で設計書は必須か | スラド IT
先日、「ソフトウェアの開発における見積もり」が話題になっていたが、ふと設計書についても同様の事を感じていたのでタレコミしてみた。 以前大手SIでプログラマをしていたとき、自分一人のワンマンプロジェクトをいくつか持っており、それに加えてチームプロジェクトにプログラマとして参加していたのだが、自分のプロジェクトではプログラミング時に設計書を使う事はなかった。 いっぽう、チームプロジェクトでは設計書はあったが、内容は酷く古く、一貫性も無く、必要な情報が載っておらず、結局一番最初の開発以降、プログラムの改修時に設計書を参考にプログラミングをする人間は誰もいなかった。結果、素人の設計書通りに作られたチームプロジェクトのアプリケーションは駄作になり、私が設計書無しで取り組んだワンマンプロジェクトはどれも高い評価を受けた。 とはいえ、プログラムの完成後に設計書の作成を要求されたために設計書を書いた事は書
優秀なエンジニアと優秀なチーム、日本企業が欲しいのはどっち？
連載目次 本連載のテーマは「チームリーダーシップスキルの向上」です。では、そもそも、なぜチームで仕事をしなければならないのでしょうか？ 今回は経営者の視点に立って、企業にとってのチームの有用性を考えます。 メンバーは個人の成果を優先しがち ITエンジニアの仕事は、設計やプログラミング作業を始める時点でモジュール分割がきちんとなされ、自分の分担が明確になっていることが多いものです。スケジュールがはっきりして仕様もしっかりしているので（例外もありますが……）、きちんと計画的にこなしていけば、仕事は一人でやれるという認識が強くなりがちです。そうなると、「仕事の成果は自分の成果」で、自分の成果を上げるためには人に邪魔されないようにバリアーを張らねば、といった極端な考えに陥る人も出てきます。 しかし、メンバーが個性を発揮し、自主的に生き生きと仕事をするためには、チームを活性化させることが必要です。そ
巨大銀行の巨大システム開発で大変素晴らしい経験を得たという話
最近まで、ネット上のIT系ニュースで度々システム障害で我々にネタを提供してくれる某巨大都市銀行の次期システム開発に下請けとして新卒から参画していた。 「某巨大都市銀行の次期システム」という時点でどこの銀行かピンとくると思う。 次期システムとは大雑把にいうと80年代に構築され今なお稼働しているシステムのうち、外為、内為、預金などの業務にて稼働するサービス(実際のプログラムになる)を疎結合化してそれぞれのサービスを部品として再利用性やメンテナンス性の向上を図る、いわゆるSOA(サービス指向アーキテクチャ)で作り直そうというものだ。 この辺も心当たりのある銀行と次期システムとかでググれば出てくると思う。 銀行システムをSOAで構築するのは日本では初めて！！すごい！！先進的！！！という触れ込みだったらしいが、立ち上げからいるわけでもなくSOAの利点も結局実感できぬままこの業界から去ってしまったので
使いやすいアプリを作る簡単な方法
使いやすいアプリを作るための、とても簡単で、確実な方法があります。 それは、ユーザの問い合わせに対応することです。具体的に言うと、問い合わせが気軽にできるようなUIにして、そこで得た情報源を元にUIを分かりやすく改良していく。(機能追加とはまた別の話) ただ、直感的に感じるように、これは手間がかかるのでたくさんの人は逆のことをしようとする。つまり、ユーザヘルプを設置して、問い合わせ先は出来るだけ発見しにくい洞窟の奥深くに設置する。 でも、問い合わせには、アプリの利便性向上につながるヒントが豊富に隠されています。ユーザがどんな問題やニーズを持っているかのヒントもザックザック出て来ます。ザックザックです。 アプリ開発にとって、やったことがいい事は星の数ほどあって、そのどれもをやろうとすると時間やお金がいくらあっても足りません。だから、”やったほうがいい事”の優先順位は常に意識して、メリットとそ
[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)
Javaでいかにifやfor文を使わないでコードを書くか考えてみよう : IT速報
1: 以下、＼(^o^)／でVIPがお送りします 2014/12/29(月) 13:23:22.49 ID:aDj/zqBFNIKU.net if文for文使いまくってるのってキモいよな 2: 以下、＼(^o^)／でVIPがお送りします 2014/12/29(月) 13:24:15.50 ID:/y8HWckGNIKU.net じゃあ代わりにswitchとwhile使う 3: 以下、＼(^o^)／でVIPがお送りします 2014/12/29(月) 13:24:18.06 ID:afkjonbrNIKU.net switch 6: 以下、＼(^o^)／でVIPがお送りします 2014/12/29(月) 13:25:46.44 ID:5e4wCC7eNIKU.net ３重switchできたった 4: 以下、＼(^o^)／でVIPがお送りします 2014/12/29(月) 13:25:07.80
Microsoftの開発現場ではVSSではなくCVSが、プロジェクト管理はMS ProjectではなくExcelが使われている | gihyo.jp
濃縮還元オレンジニュース Microsoftの開発現場ではVSSではなくCVSが、プロジェクト管理はMS ProjectではなくExcelが使われている Microsoftに勤めている人との会話をまとめたものです。Googleの開発手法は最近カンファレンスなどでよく聞きますが、Microsoftでどのように開発を行っているのかはあまり知られていない気がします。 まず、コードレビューをかなり重要視しているようです。コードと単体テストが終わったら旧ソースとのDiffをチームメンバーに配り、メールベースでレビューを行います。レビューは1行1行細かく行い、全員がOKと判断したら再度テストを行いチェックインします。コードレビューはチーム全員で行うため、チームの能力が徐々に平均化していく効果があるようです。なおバグが出た場合、チーム全員でレビューしていることから「チーム全員に対する説明責任」が生まれ、
アジャイルが否定したものを見直そう - arclamp
2014/9/6に開催されたXP祭り2014で「アジャイルを手放して得られたこと」という講演をしてきました。Togetterはこちらから。 元々は「アジャイルのダークサイド」の話がしたくて応募したのですが、その後、いろいろと考えているうちに僕自身にも気づきの多い内容となりました。 さて反応を見てると前半のアーキテクチャとマネジメントの話に興味を持っていただいたようです。なので、このブログでは「なぜアーキテクチャとマネジメントの話からアジャイルの話をしたのか」ということを書いてみます。 アジャイルがさまたげたもの アジャイル開発手法が大きく注目されるのは1999年の「Extreme Programming Explained」の出版であり、2001年の「アジャイルソフトウェア開発宣言」です。1990年代後半から2000年代初頭というのは、IT産業が大きく成長する時代であり、同時に、当時主流で
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
「知ってるつもり」では恥ずかしい 基礎から学ぶ、新入社員に教えたい「IT新常識」 － TechTargetジャパン
ゆとりの法則 － 誰も書かなかったプロジェクト管理の誤解
TechCrunch | Startup and Technology News
