フロントエンドエンジニアが「自分はJSON色付け係」と自虐する理由を考察した - パンダのプログラミングブログ
「JSON色付け係」という自虐 フロントエンドエンジニアの間では、「私の仕事は JSON に色を付けることです」という有名な自虐ネタがある。 おそらく初出は以下のツイートなのだろう（*1）。ただ、出典はあまり詳しく調べていない。 初めてこの言葉を見た時、面白い言い回しだなと思った。確かにフロントエンドの仕事にそういう側面はある。 実際、コンテンツの表示がメインのページで作業すると上記のような気持ちになる。この場合、フロントでやることといえばせいぜい日付の表示形式を適切にフォーマットするくらいだ。結局バックエンドからデータが返ってこないとフロントだけでは何もできないと思うこともある。 もちろん、フロントだけで簡潔する手書き風グラフ作成ツール excalidraw のようなものは別だし、フロントで複雑な状態を扱う部分を書いたり、フォームを使ってユーザー入力を受け付け、入力値を検証するバリデーシ
日本の大企業のソフトエンジニアはコードを書けない人だらけ
僕は日本でも有数の大企業で、ソフトエンジニアというポジションで仕事をしているが、もう転職をしたほうがいいんじゃないかと考え始めている。 元々、僕は大学を卒業後、ある中小のメーカーに就職した。そこではソフトエンジニアが企画の段階から入り込んで、まず商品企画から出てきた機能のプロトタイプを作り（コードは当然自分で書く）、そのプロトタイプを会議に持ち込んで、この機能はいいか、もっとこうすればいいんじゃないかという議論の上、プロトタイプを作り直しては企画を練り直し、最終商品としてリリースするというのが当たり前の時代を過ごした。要求仕様を確定する前に、プロトタイプを何度も作り、ブラッシュアップするスタイルで仕事をしてきた。それがソフトエンジニアの当たり前の姿だと思っていた。 そこから僕はその仕事をする中で、大企業だったら、もっと高度な制御を行うソフトを書ける人が沢山いて、自分もさらに難しい課題を解く
奇妙で残酷な作業依頼 - フリーランス残酷物語 Advent Calendar 2016 15日目
この記事は「フリーランス残酷物語 Advent Calendar 2016」15日目のポエムです。えっ、まだ12月15日じゃない？あぁ、そんな事もあるかもしれないですねぇー。でも気のせいじゃないですかたぶん。 まず前置きですが、mesaka さんの書いた記事が萌えましたねぇ。じゃなくて燃えましたねぇ。まぁ、会社にバカにされたっていいじゃないですか。社員プログラマーにバカにされたってしったこっちゃありませんよ。Qiita ユーザーにもバカにされ、はてブに晒され、社会からゴミ扱いされたかどうか分かりませんが、フリーランサーはそれでも生きている限り契約を繰り返し日々前進していかねばならないのです。愚痴ることで生きていけるのなら問題ないのです！というわけで、mesaka さんには最終日の日記でも燃料を投下してほしいと思うわけです。よろしくお願い致しますm(_ _)m 前置き終わり。さてさて、僕がフ
開発の見積もりとスケジュール管理 - クックパッド開発者ブログ
こんにちは。会員事業部の丸山です。 エンジニアが開発を開始する時にはタスクの見積もりとスケジュールを作成行って、実装を進めていくと思います。 しかし1ヶ月を超えるような規模の開発をする場合、なかなか予定通りの期日に終わらなかったりすると思います。 そして大抵の場合、増える方向になりますよね。 今回はそういうことにならないために、私が気をつけていること・実践していることをいくつか紹介したいと思います。 見積もりとは まずは「見積もり」とは何なのかを正しく理解したいと思います。 一般的には「見積もり」＝「全タスクとその工数を洗い出す」というものだと思います。 しかしここで以下のことに気をつける必要があります。 見積もりとスケジュールとコミットメントは違う 見積もりとはあるタスクがどれだけの工数(規模)なのかを算出することです。 対して、スケジュールとはあるタスクがどれだけの工期(期間)なのかを
プロジェクトが失敗する10の兆候
今年こそは失敗プロジェクトをなくしたいと思っているみなさんこんにちは。ryuzeeです。 先日海外のサイトを見ていたところ、10 Signs When Projects Are Doomed to Failureという面白い記事を見つけたので、10の兆候それぞれをご紹介しつつ私の私見を述べておきたいと思います。 なお、アジャイルなのかウォーターフォールなのかは関係なくあてはまります。 失敗プロジェクトの兆候(1) プロジェクトメンバーが自分たちのタスクをこなすよりもプロジェクトの悪い状況について話し合いをするのに時間を使っている よくあるパターン。 たとえばなかなか仕様が決まらないので見切りで発射してみたら、途中で色々な仕様変更がおこったり考慮漏れが出てきたりして常に対策会議をしなければいけなくなったり、 品質が悪すぎて品質改善のための会議を頻繁におこなうことになったりといった状況。 タス
ガントチャートの功罪 〜 新規事業で工程表を作ることに意味はあるか？ | Social Change!
「納品のない受託開発」を通じて、新規事業におけるソフトウェア開発を手伝わせて頂いていることもあり、そこで得た知見を活かして新規事業の審査員のような仕事をさせて頂くことがあります。 そこで審査のために提出された資料の中にあるガントチャートや工程表を見るとき、いつも違和感を感じていました。この記事では、ガントチャートが新規事業においては有効ではないという気付きについて書きました。 ガントチャートは決められた工程の管理をするのに最適 ガントチャートや工程表は、あらかじめ完成品が見えており、工程がはっきりしたものを「製造」していくときに非常に役に立ちます。どの工程にどれくらいの工期がかかるのか見えるようにすることで全体の計画が把握できます。 ガントチャートを有効に使うためには、きちんと工程を分解できること、とりかかる工程の順番がはっきりしていること、それぞれの工程にどれくらいの期間がかかるのか見積
ノウハウの共有文化がない場所にコードレビューをねじ込んでみた結果とか - タオルケット体操
「コードレビューをキメると品質も上がるし自分のレベルも上がるので最高」みたいな論が巷を賑わせていて、以前はそういうイケてる制度を指をくわえてみるのみだったのだけれど、最近職場と、それと個人的に関わったプロジェクトでコードレビュー制を無理矢理交渉して導入してみた結果、世間のイケてる書籍やエントリから得られる情報とはまた少し違う知見が得られたので書いてみる。 割と泥臭かったり、あまり希望に溢れてたりはしない感じのエントリなのでそういうのは期待しないほうがいいです。 準備 些末なコードレビューを極力避けるために、コードの規約やスタイルについてはlintとフォーマッターを用意した。 他は無策。 結論 結論から言うと、理想的な運用は出来なかったものの、コードレビューについて世間で言われるような成果（作業を共有する意識、レベルの向上）は得られた。良かった。 ぶっちゃけ僕なんかが浅はかな考えで導入しても
巨大銀行の巨大システム開発で大変素晴らしい経験を得たという話
最近まで、ネット上のIT系ニュースで度々システム障害で我々にネタを提供してくれる某巨大都市銀行の次期システム開発に下請けとして新卒から参画していた。「某巨大都市銀行の次期システム」という時点でどこの銀行かピンとくると思う。次期システムとは大雑把にいうと80年代に構築され今なお稼働しているシステムのうち、外為、内為、預金などの業務にて稼働するサービス(実際のプログラムになる)を疎結合化してそれぞれのサービスを部品として再利用性やメンテナンス性の向上を図る、いわゆるSOA(サービス指向アーキテクチャ)で作り直そうというものだ。この辺も心当たりのある銀行と次期システムとかでググれば出てくると思う。銀行システムをSOAで構築するのは日本では初めて！！すごい！！先進的！！！という触れ込みだったらしいが、立ち上げからいるわけでもなくSOAの利点も結局実感できぬままこの業界から去ってしまったので本当に謎
エンジニアの面接でコードレビューさせてる
（あんま多くないみたいだから多分すぐ身バレしそうだけど書く） エンジニアの面接で実際にコードを書かせる会社が最近は多いみたいだね。でもウチでは特に面接で書かせない。というか今まで書いてきた、関わってきたコードなんて書類で大体分かるでしょ？ それよりも、ウチではコードレビューをさせてる。 選考用にわざと少し突っ込みドコロの多いコード（30〜50行程度のコードを3〜4ファイル）を渡して、もちろんファイル構成自体へのレビューも含めて、どんな意見をその人が出せるかを問う。 レビュー用のコードは複数言語用意してて、一番得意な言語を選んでもらってる。 時間は1時間。資料と赤ペン、そしてネットに繫がったパソコンを渡して、いくらでもググってもらって構わない環境でレビューを紙に赤して貰う。 「コードレビュー」ってものに対しての認識だとか、コードを管理するための能力もある程度分かるし、すごく良い選考制度だと思
ITエンジニアの『生産性』と、データ・サイエンスの微妙な関係 | タイム・コンサルタントの日誌から
ある、社外の人との集まりに顔を出した時のこと。IT分野の経験を積んだ人が多く、みな一家言持っておられる。わたしは昨年後半から、久しぶりに社内のIT関連業務を見るセクションに移ったばかりなので、最近の事情に疎い。なるべく拝聴する側に回ることにした。話は業界の技術トレンドから、クラウドやビッグデータといった最新のバズワードに向かい、日本のIT業界の現状をなげく論調にうつった。日本を代表する大手SIerたちの低空飛行ぶり、技術的イノベーションの不足、そして多重下請に象徴される業界の構造的問題。追い打ちをかけるように、オフショアとの競合による単価の下落。なんだか、あんまりエンカレッジされるような話題が出てこない。 －－だとすると、日本のSI業界というのは将来性があるのでしょうか？ わたしは思い切って、直球ど真ん中の質問をなげてみた。しかし返ってきたのは、苦笑いするように首を横に振る姿ばかり。 「情
あるソシャゲ会社のプロジェクトのひっくり返り方。 島国大和のド畜生
伝聞。 あるソシャゲ会社のプロジェクトのひっくり返り方。 １年目 新卒に運営の手伝いをさせる。 ２年目 運営を切り盛りさせる。 ３年目 開発の頭をやらせる。 （実際にはそれぞれ６ヶ月ぐらいと思われる） そりゃひっくり返るわ。 何一つ開発で学んでないじゃんか。なぜ開発ができると思うんだ。 運営業務はウィークリーでデイリーなので、関わってると運営に関しては結構いいスピードで詳しくなるが。 開発は少なくとも数ヶ月かかるので。詳しくなるには何本かの完成に付き合う必要があり数年を要する。 絵でも漫画でもゲームでも。１本仕上げる度に能力がつく。 １本まるっと面倒見ないと、それを作る間にどういうコストとリスクがあるのかを肌で理解できない。 どういうトラブルが発生し、それをどう解決したかの蓄積がたまらない。 そもそも今あるトラブルがどれぐらいのトラブルなのかも見当がつかない。 イベント１コつくるのとゲーム
残念なソフトウェア開発の現場は、沈みかけの巨大な船に乗った航海に似ている。
残念なソフトウェア開発の現場は、沈みかけの巨大な船に乗った航海に似ている。 船底の穴からの浸水を必死でかき出しながら、どうにか進んで行く。そういう航海だ。 船のどこにどれだけ浸水箇所があるのかは分からない。 ある穴を塞ごうと船底に板を打ち付けたら、 それによって別の場所に新しい穴を空けてしまったりする。 船の構造はあまりに複雑で、膨大な部品の間にどんな依存関係や相互作用があるのか、 誰も完全には把握していない。 それは、はるか昔に組み立てられた太古の船で、 構造把握の手掛かりは、代々伝わる不十分で不正確な古文書だけなのだ。 新任の船員は、出た水に対してとにかく手当たり次第に対処した。 どんな物でも使い、徹夜で穴を塞いで回った。 ひたすら大きな声で号令を出し、 いかに早く穴を塞ぐかが、船員の間で競われた。 何人もの船員が過労と心労で倒れ、 航跡には水葬者が点々と残された。 船員たちが経験を積
組み込みもけっこう末路なのかもしれない
業務系SEの末路的なお話でして - 急がば回れ、選ぶなら近道 業務系に限らず、組み込み系もけっこう先行きは明るくないと思う。 メーカーの下請けでやってるようなところだと ・メーカーの予算削減で人員は減るが仕事量は変わらない ・むしろシステムの高機能化でアーキテクチャは複雑になる ・しかし一つの製品の納期はどんどん短くなる ・メーカー側もコスト面から製品に対して人員を割かなくなるので、メーカー側の社員が手が回らず下請けに丸投げしだす ・請け側の会社も仕事が少しでもあるところにスキルをあまり考えずに要員を投入する はい、デスマ。 発注側も受け側も余裕が無くなっていて、それでも請けるほうは仕事無いから請けるしか無くて、だいたい当初の想定通りのフェーズや要因で炎上する。で、年中残業やら休日出勤やらで疲弊するエンジニア。 請ける側にも多分に問題はあって、マネジメントできない人がマネジメントをし、設計
最強のIT系かあちゃんからたかしへのアドバイス
バーンれっどさーん @ledsun たかしへ あなたの勤怠確認しました．こんなに残業が多い割に大して売上が上がってないのはどうしてですか？顧客との信頼関係の構築も甘いとと思います．来月からは頑張って下さい．ちなみに母さんは今月、10人月で作ったシステムを3000万で売ってきました。 2012-02-24 13:21:23 バーンれっどさーん @ledsun たかしへ あなたの立てたスケジュール読みました。作成工数だけでバッファがありません。予想外の事態が起きた時はどうするのですか？残業でカバーですか？お客様が参加するイベントが入っていません。都度調整ですか？事前に提示していないと都合がつかなくても納期延長できませんが大丈夫ですか？ 2012-02-24 13:46:29 バーンれっどさーん @ledsun たかしへ あなたの作った機能仕様書読みました。技術的面ではチャレンジグで素晴らしかっ
120131_52_フリーランスとか大手とか言ってないで「ソニーの開発18か条」を今こそ振り返ってみよう！ - Onigiri.blog
サブメニュー Get the RSS Browse the Archive Random post Mobile version 当ブログの人気エントリ ★はてブ1500超えのエントリ 120131_52_フリーランスとか大手とか言ってないで「ソニーの開発18か条」を今こそ振り返ってみよう！ ★はてブ500超えのエントリ 121015_78_音楽業界周辺で「CDがなぜ売れないのか」と未だに議論している人がいるので実際に最近CDを買った人の話を交えながら考えてみる ★筆者オススメのエントリw 120104_45_2012年の音楽業界のWeb＆ソーシャルまわり動向予想と３つの変化について（前編） 111229_41_スタートアップに挑戦し、シリコンバレーを目指す若き日本人たちへ思うこと（ランディ・パウシュのスピーチを紹介しつつ） フォロー Wednesday, February 1, 2012
2012年に開発者が学ぶべき10のスキル
印刷する メールで送る テキスト HTML 電子書籍 PDF ダウンロード テキスト 電子書籍 PDF クリップした記事をMyページから読むことができます ここ数年、ソフトウェア開発の世界は比較的穏やかだった。しかし、HTML5が地歩を固め、Windows 8がWindowsの開発シーンに大きな変化を迫っている今では、ジェットコースターの日々が戻り、スピードはますます上がってきている。もし最先端に居続けたいのなら、少なくともこの記事で挙げる10のソフトウェア開発スキルを身につけることを検討すべきだ。 1．モバイル開発 モバイル開発を学ぶのに時間を割く価値などないと考えているのなら、考え直した方がいい。2011年のAndroid携帯の世界出荷台数は、ほとんどPCの販売台数と同じだ。他の有名なモバイルデバイス（iPhone、iPad、そして「瀕死状態」のRIMデバイス）を加えれば、販売台数で見
チーム内でやる進捗会議はムダ - 勘と経験と読経
ソフトウェア開発プロジェクトでは、顧客への定期的な進捗報告を行うために、当然のことだが進捗を管理しなければいけない。中規模以上のプロジェクトではプロジェクトはいくつかのチームに分かれていて、さらにチームごとに担当する会社が異なることもある。ありがちな事だが、チーム別にプロジェクト内の進捗会議を行うようになってくると、これが壮大なムダになっていく。 チームリーダーはソフトウェア開発プロジェクトのボトルネック ソフトウェア開発プロジェクトは、ウォーターフォール形式であれアジャイル開発プロセス型であれ、膨大なコミュニケーションと意思決定を行うことで進んでいく。ソフトウェアの仕様や構成について決定するのは、たいていはチームリーダーの仕事だ。また、各開発担当者の仕事の結果が正しいのかをレビューやインスペクションによって判定するのもチームリーダーの仕事であることが多い。そして、チームリーダーはチームメ
強いリーダーを求めるよりもチームビルディングを志向する先に成功がある - FutureInsight.info
この前、NHKスペシャルの「リーダー論」という番組を見ていたら強いリーダーが必要という論調の意見が特に50代の管理職に多く見られた。ただ、最近いろいろと本を読みながら、この強いリーダーという概念にすごく違和感を覚えるようになった。というのも、最近たまたまなのだが、チームビルディングについての本をいろいろ読む機会があったが、なんとなく強いリーダーを求める先に日本での成功はないのではないかと思うからだ。 世界最高のイノベーションファームIDEOのチームビルディング方法 まずは以下はIDEOでチームを結成するときに人材をどのように分類し配置するかについてのノウハウが記載された本。イノベーションの達人!―発想する会社をつくる10の人材 トム ケリー ジョナサン リットマン Tom Kelley 早川書房 2006-06 売り上げランキング : 109660 Amazonで詳しく見る by G-To
Maka-Veli.com / 作業工数を見積る、という事。
たまには企業ディレクターっぽい記事を書いてみようかと・・・見積作業がたぶん一番多いです。失敗すれば、お客さんにも会社にもデザイナーにも迷惑がかかってしまう重要なタスク。お金に関する問題なので、全工程を把握し、リスクヘッジも含みつつボッタクリなんて思われないようにし、きちんと作業工数分ご請求させて頂く為にミスのないよう心がけています。今回はそんな御見積時に関する、僕が気をつけている点。ディレクターってなんだよ、何してんの偉そうに、って疑問視される方も、少しは身近に感じてもらえるでしょうか？※画像のネコさんは内容と全く関係無いです、申し訳ございません。 個人的に重要だと思うポイントは以下です。 作業の終わりはどこかを決める 「見えない工数」が見えていないと、終わりが無いです。 ラインはきっちり引きましょう。 なぜかというと、 もちろんこちら側の作業が終わらないのを防ぐ理由も大きいです
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
研究をはじめる前に知っておいて欲しい7つのこと / Welcome to Lab
