私は間違っていた。ごめん。ウォーターフォールは何のメリットも無い - メソッド屋のブログ
私はソフトウェアの専門家としてお答えすると、ウォータフォールは何のメリットも無いというのが私の意見であることを共有しておきたい。そういう意見に至った経緯をこのブログで書き留めて置きたい。 尚、これは所属会社の見解ではないことは明確にしておきます。 サム・グッケンハイマーの一言 私は DevOpsのエバンジェリストで、それ以前からアジャイル開発をかれこれ１５年ぐらい実施し、導入の支援をしている。私はかつては、日本の環境の制約の中で如何にアジャイル開発のメリットを最大に引き出すか？ということを考えていた。 ウォーターフォールに対する立場も、真っ向から否定するものでもなく、現状もあるし、それに慣れている人もいるし、実際ウォーターフォールでも失敗しない人も居る。だから、人にウォータフォールのメリット・デメリットを聞かれた時も「変化しないものに関してはウォータフォールはいいのかもしれない」と回答して
それ、開発しないほうがいいですよ | rake enjoy
うちの会社が開発会社なのと会社名からちょいちょいサービス立ち上げの相談を受けます。そこでどういったサービスを立ち上げるのかなど色々お伺いしていくんですが、結構な確率でお断りすることが多いんですね。その際に 「それ、開発しないほうがいいですよ」 と伝えさせてもらってます。うちは開発会社なので、仕事として請けたほうがメリットも大きいんですが、多分結果誰も幸せにならないだろうなーと思って止めさせてもらってます。 割と同じような話を何回もさせてもらっているので、今回は改めてまとめてみたいと思います。 開発はお金がかかる まず、ここの認識を持ってもらいたいのですが、開発をはじめてしまうと非常にコストがかかるんです。今時はサービスを立ち上げる場合、ローンチして終わりではなく、継続して改善し続けないと成長しないどころか立ち上がってもきません。ですのでリーンスタートアップにも書かれているように小さく立ち上
Laravel 5でサービスをフルリニューアルした話 - Qiita
こんにちは！@best_not_bestです。 私は現在、dots.の開発を担当しています。このサービスは全てLaravelで動いています。今回はこのシステムの裏側を説明したいと思います。 dots.とは？ 「エンジニアのため」のイベント情報検索サービスです。 2013年10月にローンチし、2015年12月21日現在、ユーザー数は約34,000人になります。 ちなみにローンチ日は10月2日で、ドッ(10)ツ(2)を意味しています(´･ω･`) 2015年7月にシステムリニューアルを行い、その際にフレームワークをCakePHPからLaravelに変更しています。 使用しているもの ミドルウェア PHP 5.5 Laravel 5.0 fluent/logger guzzlehttp/guzzle aws/aws-sdk-php-laravel watson/validating dakats
プロジェクトを成功させるために最初におこなっていること - $shibayu36->blog;
ディレクター時代に仕事でプロジェクトを受け持つ時にどうやったら成功させることが出来るのかについていろいろ考えていた。僕は開発フローをいろいろ考えるのが好きなのだけど、実際に自分がリーダーシップを取ってプロジェクトを進めることを経験すると、そもそもその前に考える・決めるべきことがたくさんあるということが分かったので、ブログに書いておこうと思う。 ここで言うプロジェクトとはサービスを一から作ったり、サービスの一機能を作ったり、受託案件一つだったりを指す。特に開発プロジェクトに限定するものでもない。 プロジェクトを成功に近づけるためには、まずプロジェクトの開始時に、プロジェクトの5W1Hを明確にし、個々のメンバーの責任範囲を決め、それらを一つの場所にまとめておくということをしておくと良いと考えている。 5W1Hを決める すごい基本的なことだけど、プロジェクトをやる上でやはり5W1Hは大事である。
エンジニア不足はいつまで続くのか（メモ） - yoshidashingo
吉田真吾（@yoshidashingo）です。フリーランスでたくましくやってます。 本日は後ほどこちらにエンジニア代表として参加予定です。 ll.jus.or.jp そこでこんなお題を事前にいただいてます。 Web業界に特有の人材不足の原因とは 人材不足はいつまで続くのか どうすれば解決するのか、あるいは取り組んでること 頭の整理も兼ねて一通り自分の考えを記載しておきたいかなと思います。統計などとの突き合わせはできてませんので、経験則に基づく仮説レベルになってる点はご了承ください。 Web業界に特有の人材不足の原因とは 1. Webに対するニーズに人材供給が追いついてないのではないか説 今回のイベントのお題ではIT業界の中でもとくにWeb業界にフォーカスしています。ITにおけるWeb業界というのは生まれてここ20年くらいの業界です。その前にはそもそもWeb上でのマネタイズがされてなかった（
リードエンジニアを３ヶ月やって得た開発マネジメントに関する教訓 - seri::diary
ここ３ヶ月ぐらい同じRails案件でリードエンジニアとして仕事をしています。 何気にマネジメント的なことをやるのが初めてだったので色々と戸惑うことがありましたが、だいぶ慣れてきて知見が溜まってきたので、自分のしごとの振り返りも兼ねてまとめておきます。 リードエンジニアのお仕事とは 会社やチームによって全くと言っていいぐらい異なると思いますが、私の場合は以下の様なことをしてきました。 開発スタート時 要件確認 仕様書を読んで全体像やどこから着手するかなどを考える Railsアプリのベース部分の実装 rails new DB周りの設定 初期モデルクラスをDB定義に基づいて作成 factoryも使いそうなものについてのみ作成 rspec、rails_config等諸々の設定 ローカル環境動作用のseedsを整備 使いたいGemを追加 共通で使うCoffeeScriptのライブラリを思いつく限り実
バグをドラゴンと呼ぶ運用を始めて1ヶ月くらいたった - Konifar's WIP
1ヶ月くらい前、 「バグをドラゴンと呼んだらどうなるか」というTweetを見ました。 確かに、バグをドラゴンと読んだ場合「Sクラスのドラゴンが出ました！」「Aクラスのドラゴンを相手にしてる最中だってのに！」って会話になるし、ドラゴンは結局人の手で生み出されたものってところが中二ファンタジーっぽくて良い— 尾野（しっぽ） (@tail_y) March 18, 2015 これは天才的発想だなと思って職場で雑談で話してみたところ、 同僚のスペイン人エンジニアにバカウケしまして、 それからちょいちょいバグのことをドラゴンと呼ぶようになりました。 せっかくなので、どんな雰囲気になるのかまとめてみようと思います。 先に言っておくと、自分ともう1人スペイン人エンジニアが時々チャット上で使っているだけで、 正直そんなに流行ってないです。 なんかテンションが上がる バグ修正ってマイナスをゼロにするだけで何
仕様書がない開発が増えた理由 | ScrapEngineer
最近の開発で仕様書等のドキュメント類を書くことが少なくなりました。 私は主に業務系のWebサービスを作成してましたが、最近はオープン系のサービスも受け持つことも多いのですが、仕様書やテストのエビデンスがオープン系のお客様の場合は求められることが少ない・・・ というかほぼない。 何故、お客様は仕様書を求めないのか？ 予算を削りたい お客様にとって仕様書なんて見てもわからないもの貰ってもしょうがない。 貰ってもしょうがないものなら作ってもらわないで、削ってしまおうって考えがあります。 テストのエビデンスも同様です。 これは仕様書の作成やエビデンスの作成に工数が掛かるため、工数の削減を計って予算を削りたいという考えがあります。 例えば、おおまかに計算しますが以下のようなシステムがあります。 開発工数：1人月 検証工数：0.5人月 設計工数：0.5人月 ドキュメント作成工数：0.5人月 管理工数：
開発フロー研修 @ Wantedly - Qiita
Githubでの開発 - Issue, Commit, Pull Request, Mention, Code Reviewに関する基本的なルール ゴール 「 チーム で 長期にわたって 生産性を上げる 」 前提 みんながサービス・プロダクトについて自主的に考える組織 エンジニア全員がそれぞれオーナーシップを持ってよりプロダクトを良くすることを考える いわゆるPM職の不在 = コードは書かずに、マネージだけする人がいない これは組織による。(e.g. 外注やディレクター職の存在) けれど、Wantedlyは、多少変化しつつも、より良いサービスを生み出すために、役割の程度の差はあれ全員がプロダクトについて考え責任を持ったほうが良いと考えている。 理想型 図:「青と黄色」のチーム構成が従来の縦割り+統括チーム、「緑(金)色」のところが目指すべきマイクロサービスチーム マイクロサービスチームは、
若手開発者の後悔 | POSTD
(編注：2020/08/18、いただいたフィードバックをもとに記事を修正いたしました。) これはある仕事熱心な若手開発者のほぼ実話です。2004年の後半、この若手開発者は小さな会社で働き始めました。条件は全て彼の望みどおりでした。給料はいいし、扱うのは彼の得意とするプログラミング言語、アプローチの複雑性、モデリングのアーキテキチャでした。 彼にとって今回の会社が初めての職場ではありませんでした。しかし、ここでの最初のプロジェクトは結果的に 問題だらけ に終わりました。当時、この若手開発者は、機能は絶対に変わらないものだと思っていました。しかし、それは間違いでした。機能が変更されるたびに完全なリファクタリングを行わなければなりませんし、バグを引き起こして膨大な時間を無駄にしてしまいます。彼は、テストを書くといった実直な方法も試してみましたが、書いたテストはメンテナンスが必要な上、書くのに時間
7年働いた時点での私の仕事の極意 - Kengo's blog
最重要 実行に重きを置く やらないで後悔するよりも、やって反省する。 反省は成長を産み生産的だが、後悔は精神の無駄な消費。 時間は有限で貴重な資源だが、たぶん今の段階では行動する前に得るものや結果を予測するのは難しい。 正しい反省の方法とは何か、考え続けること。 「正しく反省するために、何を記録しておくべきか」実行前に明らかにしておくこと。 反省の結果は組織的な何かに落としこむ。組織構造、戦略、静的解析、自動テスト、教育など。意識しないでも巨人の肩に乗れる状況を作ることが、組織の成長につながる。 Done is Better Than Perfect ただし、思考停止の言い訳にしないこと。詰めの甘さを擁護する言葉ではない。詰めの甘さは立場や考え方が違うひと3人くらいに意見を求めればだいたい炙り出せる。 長期的視野を持ちつつ、それに引っ張られない。進展を作ること、現状を少しずつ変えることを意
Kazuho's Weblog: 「技術的負債」は避けるべき？ - 割引率を使って考えてみた
「技術的負債」をコントロールする定量評価手法への期待 からの続きです。 ソフトウェアサービス企業における技術責任者の最も重要な仕事のひとつが、エンジニアリングの効率化です。そのためには、サービスの初期開発コストだけでなく、運用コストを織り込んだ上で正しい技術的判断を行っていく必要があります。 「技術的負債」という言葉は、この運用コスト最適化の重要性を指摘する上で、とてもキャッチーなフレーズだと考えられます。しかし、「技術的負債」を産まないように、あるいは負債を早めに返していこうとすると、開発工数が大きくなってしまうという問題もあります。 初期開発コストと運用コストのバランス注1を、どのようにとっていけば良いのでしょう？ 同等の機能を提供する「ソフトA」と「ソフトB」を考えてみます。ソフトAは、初期開発工数が6だが、２年目以降の維持工数が毎年4かかるとします注2。ソフトBは、初期開発工数が1
とあるスタートアップを抜け、CTOを辞めた話。 - nobkzのブログ
とあるスタートアップを抜け、CTOを辞めた話。 辞めると来まって、1週間ぐらい立ちいろいろ整理してきたので、そろそろこのことについて書く。前々から書かなければ、ならないという謎の使命感を持っていた。 僕は、Technical RockstarsのCTOだった。このスタートアップで、リアルタイムBaaSサービスと等、いろいろなサービスを提供していた。スタートアップ自体は、2013年の11月あたりから、CTOの就任して、大体1年と、半年ぐらいか?そのぐらいの期間CTOだった。 そして、これから、なぜCTOを辞めたのか?というのと、日本のスタートアップ、とくにエンジニアスタートアップの問題点、何を学習したのか? 何を得たのか? そして僕はこれからどうするか?というのを、つらつらと書いていきたいと思っている。 スタートアップとは? ここで、スタートアップがどういうものか?というのを知らない人の為に
共通化でモチベーションと効率が低下した話 - Qiita
自分は普段ソーシャルゲームの開発に関わっていますが、群雄割拠のグリモバ全盛期にその開発を効率化するために社内ではいろいろな取り組みがなされました。そのひとつにアプリ別ではなく機能別のチームを作るということがありました。結果としてそれは失敗だったと言えるのでそのことについて書いていきます。 背景 当時のソーシャルゲームの主流はカードゲームで、クエスト・レイドをこなしつつガチャで引いたカードを合成して強化していくスタイルが一般的でした。そしてその多くがシステムはほとんど同じで見た目だけを変えた「柄替え」アプリでした。 その中で行われたのが二つの共通化です。 コードの共通化 今までのアプリでは元のアプリのソースからフォークするなどして別のプロジェクトとして独立させそれに対して各チームが開発を行うと言う感じでしたが、今回の共通化ではゲームのコアとなるロジック部分をサブモジュールとして分離し、各アプ
起業家が開発者のマネージメントで犯しやすい11の失敗 | readwrite.jp
ソフトウェア開発者達を育てるには、あなたのリーダーシップのスタイルを変える必要があるかもしれない。彼らは、一般的なマネジメントでは必ずしも輝かないのだ。何が一番重要か？前もってはっきりとした予測を立てる事、そして問題になる前に作業習慣の違いを考慮しておく事だ。 我々はYoung Entrepreneur Council （YECの11人の起業家達に、彼らが開発者を管理する上で経験したリーダーとしての大失敗と、同じ間違いを避けるためのコツを共有してもらった。彼らの回答は以下の通りだ。 彼らが意見を述べてくれると思い込む事ソフトウェア開発者達が自分の課題やアイディア、あるいは手柄についてさえも話してくれると思い込まない方が良い。多くの開発者達はチーム・ミーティングでこういった情報を進んでシェアしようとしない。開かれた、真摯なフィードバックは常にあなたから要求しなければならない。 自分の努力に対
2014年にリモートで試したミーティング類のパターン - はまさき
今年の初めからアメリカに引っ越したので社内の人とのやり取りをどうするかという悩みに現実的に直面し、この1年で色々試したのでセーブポイントとしてまとめておくことにした。（ブログの記事を書かなさすぎてはてな記法忘れつつある...） チームとミーティングの距離感 8人くらいの会社。誰もがSPOFで、何かに詳しい人間はだいたい一人に絞られる*1。会社として重要な箇所に一人だと心許ないというより、誰も休めなくなってしまうので概ねわかるだろうという他者を含めるか、共有するなりで冗長化して、2人以上がひとつの何かに取り組んでいる形を組織中に点在させている。 その2人の間や異なる担当間でそれぞれミーティングの時間を取っておきたいが、大仰に週例、月例、毎朝のスタンドアップみたいなミーティングをそっくり入れ込むにはちょっと負荷が大きいので何か工夫が必要だ。 勤務地は強制していない。オフィスはあるけれど必要にな
デブサミ関西2014で「田舎からリモートで働くという生き方」という発表をしました #kansumi - give IT a try
はじめに 先日このブログでもお知らせしたとおり、去る2014年9月5日にDevelopers Summit 2014 Kansai（デブサミ関西2014）で発表をしてきました。 僕が発表したのは「関西で働くという生き方」というオムニバス形式のセッションです。 このセッションで僕は「田舎からリモートで働くという生き方」というテーマでお話ししました。 このエントリでは発表の内容と裏話等について書いてみたいと思います。 当日の会場はこちらの神戸国際会議場でした。 当日のスライド 発表で使ったスライドはこちらにあります。 田舎からリモートで働くという生き方 from Junichi Ito ただ、僕の発表はたいてい「話がメイン、スライドはおまけ」というスタンスなので、スライドだけ見てもあまりピンと来ないと思います。 そこで、どんな話をしていたのかわかるように、動画を用意してみました。 発表の動画（
コミットメッセージのルール - Opacities
2014-11-22 コミットメッセージのルール 開発でGit(Github)を利用している時、コミットメッセージは後からログを見返すときにとても大切なものだけど、 普段適当に記述しているのもあって、改めてルールを書くことにした。 コミットの粒度 コミットの粒度では、何かしら一つの作業を終えたら・・・という粒度でコミットすることにする。 具体的には ある範囲のUIを実装した時 何かしらのコードを削除した時 バグを潰した時 など、比較的作業単位で細かくコミットするようにする・ コミットメッセージの内容 1行目 / 内容の要約 例 modify serarch button for product menu 2行目 / 空行 空行にする理由としては、可読性や要約と内容を分離するためにある。 3行目 / 本文 実際に何をやったのかを書く。長すぎるのもダメなのでだいたい60字ぐらいでまとめるよ
CodeIQについてのお知らせ
2018年4月25日をもちまして、 『CodeIQ』のプログラミング腕試しサービス、年収確約スカウトサービスは、 ITエンジニアのための年収確約スカウトサービス『moffers by CodeIQ』https://moffers.jp/ へ一本化いたしました。 これまで多くのITエンジニアの方に『CodeIQ』をご利用いただきまして、 改めて心より深く御礼申し上げます。 また、エンジニアのためのWebマガジン「CodeIQ MAGAZINE」は、 リクナビNEXTジャーナル( https://next.rikunabi.com/journal/ )に一部の記事の移行を予定しております。 今後は『moffers by CodeIQ』にて、 ITエンジニアの皆様のより良い転職をサポートするために、より一層努めてまいりますので、 引き続きご愛顧のほど何卒よろしくお願い申し上げます。 また、Cod
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
デスマーチが起きる理由 - ３つの指標