SIについて私が思ったこと。そしてSIerにおけるモダン開発について : 小野和俊のブログ
ひとことで言えば、「レビュー文化は良くない」ということになるだろうか。 Slack導入、そして同時期に開始した服装の自由化、バイモーダルという考え方の浸透、AIやブロックチェーンを活用したPOC等の取り組みによって、SIerとしてのセゾン情報システムズは、社内の雰囲気もずいぶんと変わってきた。 しかし、こうした取り組みだけではどうにもならないものも少なからずあった。 そのひとつは、「悪い報告がしづらい」ことだった。 これは他のSIerでも同様のことが多いのではないかと思うが、問題プロジェクトに認定されると、品質管理部のモニタリングが強化されたり、第三者によるプロジェクト監査が始まったり、経営会議での定期的な報告が求められたり、何をやっているのかとレビューでこっぴどく叩かれたり、、、。 そうした責任感から、遅れをキャッチアップできるよう少しでもがんばろう、と励まし合う中で、それなのに四方から
カンバン仕事術
チームの仕事や課題を見える化する手法「カンバン」について、その導入から実践までをイラストでわかりやすく解説する書籍です。カンバンの原則や流れの管理などの入門的な事柄から、サービスクラス、メトリクスの使用、プロセスの改善など、一歩進んだ応用的な話題までを網羅的に解説します。カンバンを一から学びたい、組織で使ってみたい方に最適な一冊です。 序文 はじめに 本書について 第I部 カンバンの学習 1章 チーム「カンバネロス」のはじまり 1.1 イントロダクション 1.2 ボード 1.3 ワークフローのマッピング 1.4 作業項目 1.5 コイン渡し 1.6 仕掛り作業 1.7 特急項目 1.8 メトリクス 1.9 見送り 1.10 まとめ 第II部 カンバンの理解 2章 カンバンの原則 2.1 カンバンの原則 2.2 すぐに始める 2.3 まとめ 3章 作業の見える化 3.1 ポリシーの明示 3.
SIはやめておけ
20代の数年間SIで働いた。1年以上前に退職して今は別業界にいる。 今日、Evernoteを整理していたら「退職理由、SIの嫌な点」というメモが発掘された。退職直前のかなりストレスがたまっていた時期に書き殴った文章だった。学生の頃の私は絵を書いたりしていて、ものづくりで暮らしたいな〜などと思って始めたプログラミングが楽しかったので安易に受託開発業を選んでしまったが、その後悔が如実に表れていた。 一部自分でも覚えていない話もあったがコンテンツとしては面白かったし、今でもシステムインテグレーター業界で消耗する若者を減らしたいとは思うので公開してみる。 以下、同メモに加筆・修正したものなのでファンタジーだと思って読んでくれ。 工数至上主義受注した時点で売上がおよそ確定するので、後はその予定工数に収めて納品できれば御の字という考え方。よくある話だが、見積がおかしくても顧客と対等な関係が築けていない
アプリのリリースに必要な「引き算担当」について - @hitoshi annex on hatena
起業してアプリを出す。 一言で言ってしまえば簡単なんですけど、最初のそのアプリリリースの時に失敗する人が少なくない気がします。 僕の観測範囲だけでも、独立してアプリを出そうとして開発に失敗、「作り直し→リリース延期」となるケースを定期的に目撃しますので、それなりにそういう失敗をする人はいるんじゃないでしょうか。これが20代の若手が失敗したというならまだ分かるんですが、経営者としてすでに十分な実績のある、僕自身も尊敬するような方がその陥穽に陥ったりしていますので、これはもう能力とか才能の問題でなくて、むしろ「知識」の問題なんじゃないかと思うんですね。 そういう僕も、kiznaというアプリを出そうとして落とし穴にはまってしまい、結局日の目を見なかったという苦い経験をしていますので、こういう経験はちゃんと共有して、無駄な犠牲者が出ないようにすべきだと思うわけです。 というわけで、初めてアプリを出
IT人材白書2014を読んだ - Qiita
となり、圧倒的に Web ビジネスがホットな転職先であることが分かります。Web ビジネスでの中途採用は、「IT企業から」と同じ「Webビジネス企業から」の両方。IT企業から流れ込んでいるのかと思ったら、「Webビジネスを渡り歩く」人も増えてきているのでしょう。 逆に、IT企業では、同じIT企業からの転職が圧倒的。（Webビジネス企業からの逆流は少ない）もしくは、ここに数字は出てこないが社内配置転換、が多いと推察されています。 アジャイル開発 p.106 から始まる節では、アジャイル開発における人材像について記述されています。欧米ですでに主流になっている手法だが、日本でも採用が増加傾向にあり、IPAのセミナーでのアンケートでは、2013年にはじめて「すべてのプロジェクトで適用している」もしくは「ほとんどのプロジェクトで適用している」の参加者割合が半数を超えた回があったそうです。 ただし、別
エンジニアのベストプラクティスを非エンジニアチームで活かす - ワザノバ | wazanova
http://www.developingsales.com/ 1 comment | 0 points | by WazanovaNews ■ comment by Jshiike | 約6時間前 Jeff SzczepanskiはStack Overflowのマネタイゼーションの責任者。エンジニア転じて、営業の組織の長になった人物。 「営業というのは科学というよりは芸術。コンピュータ相手じゃなくて、人間を相手にしているからね。」 「営業が結果を重視するのは、計測しやすく公平な指標だから。どうなるか予想したりプロセスをうまく管理するのは難しいんだよ。」 という話しに違和感を抱き、「誰かが決めた営業戦略に従って営業マンは盲目的に数字の達成だけを求めてひたすら実行する。」という従来の営業手法は、 自分で手を汚してコーディングしない「アーキテクト」と呼ばれる人が仕様書をまとめ、下々のエンジニ
OSSの開発モデルを、そのまま社内に持ち込むのは止めたほうがいい（もしくはコードレビューの話） - kazuhoのメモ置き場
以前以下のようにツイートした話だけど、OSSの開発モデルを社内開発にそのまま持ち込むのは危険。 チーム開発の場合、簡単にコメント返せないようなPR送られた時点で負けだと思ってる。無駄なコードが生産されないよう事前に設計を詰める作業をすべき / “雑なレビュー - ✘╹◡╹✘” http://htn.to/by5or1 https://twitter.com/kazuho/status/431602421068877824 今日一般的に想定される「OSSの開発モデル」はEric S. Raymondの有名なエッセーである「伽藍とバザール」によって解説されたところの「バザール」である。 「バザール」モデルにおいては、多くの改善提案の中から最善と考えられる実装が取り入れられ、コミュニティで共有されるようになる。同エッセーから引用するなら、 ふりかえってみると、Linux の手法や成功の前例は G
プログラマの第三の選択 - SonicGardenのビジネスモデルについて考える - メソッド屋のブログ
ソニックガーデンは、利益や、成長よりも顧客、エンジニア、経営者の幸せを求める革新的な形態の新しい企業だ。今後このような形態の企業が増えてくると思われるが、その先便の企業だと思う。 日本のソフトウェア業界の企業形態 日本のソフトウェア業界にある企業を３つに分類してみた。そして、その傾向を分析してみた。 A. モーレツな成長と成功を求める会社 これは２種類あり、スタートアップ系のベンチャーと、Amazon, Google, Facebook等既に成功し、成長したスタートアップ系企業だ。スタートアップの場合は、ほぼバクチのようなもので、当たり外れが激しい。最初の給料は激安。その代わり成功したときに入る収入は段違いだ。その代わり、生活はほぼ犠牲にされると思っていい。経営者もこれは同じで成功した暁には凄く大きなお金と、働かなくてもよくなるぐらいの自由が手に入る可能性がある。ただ、成功の確率はとても低
最強のIT系かあちゃんからたかしへのアドバイス
ぎゃばん -1.0 @ledsun たかしへ あなたの勤怠確認しました．こんなに残業が多い割に大して売上が上がってないのはどうしてですか？顧客との信頼関係の構築も甘いとと思います．来月からは頑張って下さい．ちなみに母さんは今月、10人月で作ったシステムを3000万で売ってきました。 2012-02-24 13:21:23 ぎゃばん -1.0 @ledsun たかしへ あなたの立てたスケジュール読みました。作成工数だけでバッファがありません。予想外の事態が起きた時はどうするのですか？残業でカバーですか？お客様が参加するイベントが入っていません。都度調整ですか？事前に提示していないと都合がつかなくても納期延長できませんが大丈夫ですか？ 2012-02-24 13:46:29 ぎゃばん -1.0 @ledsun たかしへ あなたの作った機能仕様書読みました。技術的面ではチャレンジグで素晴らしかっ
開発手法とコミュ力は捨てろ――SIエンジニアに告げる、Web企業への転職戦略
開発手法とコミュ力は捨てろ――SIエンジニアに告げる、Web企業への転職戦略：きのこる先生のエンジニア転職指南（6）（1/2 ページ） 元プログラマ、現Web系企業の人事担当者による、エンジニア転職指南。「応募書類の書き方」や「自己PRの仕方」について、エンジニアの視点を持ちながらアドバイス。エンジニアの幸せな転職のために、菌類が奮闘する。 皆さん、こんにちは。2011年も残すところあとわずか。忙しい日々をお過ごしでしょうか。 師走ということで、師に負けず菌類も走り回っています。新卒採用のエントリが始まり、やるべきことは増えるばかり。冬眠したい気持ちをぐっとこらえてフル稼働中です。 繰り返す、ここはSIerではない さて今回は、かつて私が所属していた「システム・インテグレータ（SIer）」、そしていま所属している「Web系企業」についてお話します。 SIerは、長引く不況とIT業界の構造変
ドワンゴの社内ハッカソンに行ってきた！ - IT戦記
はじめに みなさん、こんにちはあまちゃんです。 さて、今日は先日ドワンゴの社内ハッカソンに UT Startup Gym のメンバーとおじゃましてきましたので、ちょっとそのことについて書いてみたいと思います。 ドワンゴのエンジニアがほとんど参加してるらしいです！すごい人数ですね！ こんな人数でハッカソンをやるなんて、すげえ！ ちなみに、入り口はこんな感じ 僕もなんかサービス作ろう！ せっかくハッカソンに参加したんだから僕もなんか作ろうと思って、 事前にライブラリ作っておいて「あとは組み立てるだけ！」みたいな状態にしてたんですけど、 残念ながら完成せず…。 こんど機会があったら、どこかの開発合宿で仕上げたいなと思います。 ドワンゴの人が作ってたものがすごかった 最後に各々が作ったものを発表する LT があって、その発表が凄かったです。 （チラッ） 技術的にも尖っていて、ユーザー視点としても面
10 Skills to Become a Frontend Developer worth Millions
Yesterday we had a very enjoyable Fronteers meeting at our offices. Fronteers is the Dutch association for frontend developers. Their monthly meetups consist of pizza, drinks and presentations about frontend related stuff.We had four 15 minute presentations, all related to testing and organizing frontend development. I was up last and decided to go a bit philosophical I find that slides either suc
svn＋TeXでcommitするとPDF - オーム社開発部の出版システムでの書籍執筆:Geekなぺーじ
以前、オーム社開発部の出版体制を取材しましたが、今回、私自身がそのシステムを使って本を書きました。 Subversionでバージョン管理をしつつLaTeXで本を書く形式です。 複数人で本を書く時にバージョン管理ツールを使わないと、誰がどこをどういじったのかがわからなくなったり編集箇所が競合する場合が多いのですが、Subversionを使うことでそれらが解決可能です。 さらに、筆者か編集者のうちの誰かがsvn commitを行って最新版を更新すると、それに連動して最終原稿として印刷所に入稿されるものと同じ形のPDFが自動的に生成され、DTP作業がゼロになるとともに、筆者がアウトプットを細かく確認ができるという特徴もあります。 しかも、Subversionのコミットメールを編集者側も見ていて、該当部分に対する編集やコメントがすぐに投入され、こちらが文章を書いた数分後に編集側意見が含まれるPDF
実力を測るのにFizzBuzzも二分探索も使えない：Rails Hub情報局：エンジニアライフ
FizzBuzzをサービスにする「CodeEval」が面白い、というエントリーは、プログラマ採用に必要なスキル判定とリクルーターのマッチングをサービスとして提供するベンチャーの紹介でした。 しかし「良いプログラマ」というのがいるとして、それを見るのに、アルゴリズムのコーディングなんか必要なのか、そんなもので測れるのかという根本的な問題があるように思えます。 最近、RubyInsideで見かけた「Practical Tips for Hiring Ruby Web Developers」（RubyのWeb開発者を雇うための実践的なティップス）と題されたエントリは、まさにこれに答える内容で興味深いです。オーストラリア人開発者のTim Gohさんは、CのatoiだのQuickSortだのを書かなきゃいけなかったことなんて最近ないでしょ、Fizzなんてプロダクション環境で出力したことねぇよとして、
「IT業界」なんて、ないんだよ
このエントリは、新卒準備カレンダー 2011春のためのもので、@shuji_w6e さんの「実践する、コツコツと、少しづつ」の次のエントリになります。 おまえ誰よ? 高橋征義と申します。プログラマです。プログラミングはかれこれ30年近くやってますが、まともに書けるようになったのは20年近くたってからです。人間続ければ何とかなることもあるんですね（ならないこともあります）。 修士の１年のとき、高校時代の友人から「インターネットのベンチャー会社作るんだけど一緒に働かない？」と言われ、あまり何も考えずに修了後その会社に参加しました。1996年、Webが流行り始めたころのことです。 そこから一度転職をはさみ、10年以上Web業界の隅っこの方で開発仕事に励んでいたのですが、昨年３月に退職、６月に電子書籍の制作と販売を行う「株式会社達人出版会」という会社を設立して、今はそこの代表取締役です。いやまあ社
変化するIT企業とエンジニアの関係 - developer’s delight
ここ数年で、ウェブサービスやアプリケーションを開発するエンジニアをとりまく状況は、劇的に変わったと言えるのではないでしょうか。主要なウェブサービスのデータや機能はAPIごしに利用可能になり、アプリケーションフレームワークやOSSなどの道具が多くそろい、いわゆるクラウド系のサービスのおかげで個人でインフラを用意する必要は無くなり、サービスを開発、公開する敷居がぐっと下げられました。また、AppStoreなどのプラットフォームの登場で、エンジニアは思いついたアイディアをすぐに世の中に問い、さらにそこで収益を得ることまで可能になっています。このような状況が、エンジニアと所属企業の関係を大きく変えつつあるのではないかと最近感じています。企業や組織というのは、本質的には個人で成し遂げることが難しい目標を達成すために存在するのだと思います。しかし仮に同じことが個人でもできる、むしろ会社でやるより個人で
ロールプレイングゲーム - @m_seki の
ここでは私が実践している、ちょっと良いプログラマになるためのコツを紹介します。まるで「理想のプログラマ」のように仕事をするための簡単なアイデアです。チームでプログラミングするお仕事に就かれているみなさんが、このアイデアで昨日よりも気分よく過ごせるようになれば幸いです。 多くの達人が「理想のプログラマ」とはどういうものか、よいプログラマのあるべき姿、立ち振る舞いを説いてきました。おそらく、みなさんも達人たちが理想のプログラマについて書いた文章を読まれたのではないでしょうか。そして達人たちの示す理想のプログラマ像を想像してそんな人物になろうとしましたよね。みなさんは実際にそうなれたでしょうか。その振る舞いを実践するのはちょっと難しかったりしませんでしたか。 「理想のプログラマ」といった「理想の何か」になるために、本来の自分を変えて別な自分になる必要があります。しかし変身は痛みを伴うものです。本
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
開発組織マネジメントのコツ - Speaker Deck
「何故クックパッドのサービス開発は日々進化しているのか」という発表をしました。 - yoshiori.github.io
Improvement_process_for_providing_ongoing_value
