仕様書がない開発が増えた理由 | ScrapEngineer
最近の開発で仕様書等のドキュメント類を書くことが少なくなりました。 私は主に業務系のWebサービスを作成してましたが、最近はオープン系のサービスも受け持つことも多いのですが、仕様書やテストのエビデンスがオープン系のお客様の場合は求められることが少ない・・・ というかほぼない。 何故、お客様は仕様書を求めないのか？ 予算を削りたい お客様にとって仕様書なんて見てもわからないもの貰ってもしょうがない。 貰ってもしょうがないものなら作ってもらわないで、削ってしまおうって考えがあります。 テストのエビデンスも同様です。 これは仕様書の作成やエビデンスの作成に工数が掛かるため、工数の削減を計って予算を削りたいという考えがあります。 例えば、おおまかに計算しますが以下のようなシステムがあります。 開発工数：1人月 検証工数：0.5人月 設計工数：0.5人月 ドキュメント作成工数：0.5人月 管理工数：
データサイエンティストというかデータ分析職に就くための最低限のスキル要件とは - 渋谷駅前で働くデータサイエンティストのブログ
追記（2017年7月） こちらのスキル要件ですが、2017年版を新たに書きましたので是非そちらをご覧ください。 「データサイエンティストというかデータ分析職に就くためのスキル要件」という話題が某所であったんですが、僕にとって馴染みのあるTokyoR界隈で実際に企業のデータ分析職で活躍している人たちのスキルを眺めてみるに、 みどりぼん程度の統計学の知識 はじパタ程度の機械学習の知識 RかPythonでコードが組める SQLが書ける というのが全員の最大公約数＝下限ラインかなぁと。そんなわけで、ちょろっと色々与太話を書いてみます。なお僕の周りの半径5mに限った真実かもしれませんので、皆さん自身がどこかのデータサイエンティスト（）募集に応募して蹴られたとしても何の保証もいたしかねますので悪しからず。 統計学の知識は「みどりぼん以上」 データ解析のための統計モデリング入門――一般化線形モデル・階層
安定寄りの零細IT会社を作って1年ちょいで得た知見 - terurouメモ
デンキヤギ株式会社という名のITの会社を作ってから1年強になった。 自社プロダクトを事業の中心に据えたいとは考えているが、まずは安定経営のため受託開発を優先してきたことにより得た知見をまとめておく。ちらほらと「会社を作ってどうよ」みたいな事は聞かれた際に、まともに答えてきていなかったという自覚があるので、その回答でもある。 設立以前から現在までのざっくりの状況 中小SIerでサラリーマンエンジニア歴10年（うち5年ぐらいはR&D部門所属） 名古屋ローカルではあるが、コミュニティ活動はガッツリやってきた方 まずは1人だけの株式会社を設立 設立から1年ちょいの間に社員を2人採用 現時点では受託開発中心で、安定に寄せた経営方針 業績はボチボチ、倒産の危機とかはない程度には良い とりあえず受託で食っていくために必要なもの カネ コネ 相場・市況感 ちゃんと仕事を回してちゃんと納品する能力 さえあれ
「10倍プログラマ」の神話、Ruby on Railsの生みの親が語った高い生産性のカギとは!? | HRナビ by リクルート
ずいぶん前のことだが、Webアプリケーション開発フレームワーク「Ruby on Rails」が00年代後半にブームを巻き起こしたとき、強い主張を持つソフトウェアとしてRailsは多くの議論を呼び起こした。その中でも最大のものはプログラマの生産性に関するもの。当時、すでにいくつも存在していたJavaベースのWebアプリケーション開発フレームワークに比べて、Ruby on Railsは10倍の生産性を達成できるという主張だ。 Rubyの生産性はJavaの10倍――。この主張が多くのエンジニアの琴線、もしくは逆鱗に触れた。「さすがに10倍は大げさだ」、「いや、現実に設定ファイルやコードを書く行数が劇的に減るのだから、そのぐらい当然だ」と意見が分かれたのだ。 2005年のリリースから約10年。Railsの生みの親で、今もプロジェクトをリードするデイビッド・ハイネマイヤー・ハンソン氏は当時を振り返り
プログラマが知るべき97のこと
プログラマが知るべき97のこと大人気の書籍『プログラマが知るべき97のこと』のエッセイを無料で公開中！すべてのプログラマにおすすめの本がウェブで読めるようになりました。 エッセイ一覧分別のある行動関数型プログラミングを学ぶことの重要性ユーザが何をするかを観察する（あなたはユーザではない）コーディング規約を自動化する美はシンプルさに宿るリファクタリングの際に注意すべきこと共有は慎重にボーイスカウト・ルール他人よりまず自分を疑うツールの選択は慎重にドメインの言葉を使ったコードコードは設計であるコードレイアウトの重要性コードレビューコードの論理的検証コメントについてのコメントコードに書けないことのみをコメントにする学び続ける姿勢誰にとっての「利便性」かすばやくデプロイ、こまめにデプロイ技術的例外とビジネス例外を明確に区別する1万時間の訓練ドメイン特化言語変更を恐れない見られて恥ず
技術力がつかない負の流れに陥ってしまった。 - 東京アンダーグラウンド
最近自分がとらわれている負のスパイラルについて、思うところがあって書いてみた。 吐き出せば楽になれるかもしれない。 例外的な人はもちろんたくさんいると思うけど、一般的にSIer社員は技術力が低いと言われている。 たしかに自分の周りのSI社員にまともにコードを書ける人なんていないし、話に出るのは1990年代から2000年代のテクノロジーだ。 業務中にプログラミングをするときは、それが業務を改善するためのものであっても、周りの目を気にしてIDEを開く。 隙間の時間に、ほんの少しだけ。 手を動かさないと技術が身に付かないのは事実で、そういう意味だと、SI社員が技術を身に付ける時間は非常に限られている。 少なくとも、業務中に技術的なことをやる時間はほとんどないので、何かを身に付けたいときは、業務外に頑張って時間をとって勉強しなければならない。 家に帰ってからが勝負になる。 例外的な人になるためには
通勤手当なんて廃止すべき - Chikirinの日記
首都圏で働く多くの人が、片道でも 1時間、時には 1時間半や 2時間など、全員あわせれば膨大ともいえる時間を通勤に費やしてる。 往復だと 2時間から 4時間にもなるし、混み方も尋常じゃない。 座れないとか人とぶつかるってレベルじゃなくて、「なんで他人とここまで密着しなくちゃいけないわけ？」みたいな状況。 時にはヒールで踏まれたりコートに口紅を付けられたりもするし、顔に他人の汗や髪の毛がついたりもしてマジ気持ち悪い。 妊娠してる人や足が悪い人、閉所パニックなどの持病があれば、身の危険を感じることもあるはず。 このヒドい通勤事情をさらに悪化させてるのが、会社が通勤手当を払うという制度です。 たとえば、 A) 会社から 2駅の A駅近くに住むと家賃は 10万円だが、通勤定期代は月 3千円、通勤時間は 15分 B) その駅から 10駅（合計 12駅）離れた郊外の B駅近くに住むと、家賃は 8万円に
Twitterの日本人エンジニアに聞く、天才ハッカーと凡人の違い
Twitter社において日本人エンジニアとして活躍するひげぽんこと蓑輪太郎氏が、ITジャーナリストの西村賢氏と対談。勤務の習慣や開発環境、また社内の天才ハッカーが見せる特別な技術などについて語りました。 Twitter開発のテストはローカルで 西村賢氏（以下、西村）：Twitterって巨大な世界的企業で、一般的な開発と全然かけ離れているイメージがあったんですね。今ちょっと驚いたのがRailsでローカル環境でまだやってるということで、ローカル環境、例えば蓑輪さんも入られて最初、Macかなんかで開発するわけですよね。その上に開発環境を整える。 具体的に、例えばデータベースのところはどうするとか、結構この環境構築は大変なんですか、最近、その開発環境とステージングとプロダクションをなるべく近づけろとか、ありますよね、そういうトレンドが。そういう意味で言うと、ローカルTwitterが再現できちゃうと
RE: どんなことを勉強すればいいですか？ - satococoa's blog
仕事でインターン生や経験の浅い方のレビューをしたり面接を担当したりしててよく聞かれる質問が「どんなことを勉強すればいいですか？」です。 それについてちょっとポエムを書いてみようかと思います。 主に会社で一緒に働いている人やこれから一緒に働くことになりそうな方向けに書いていますので、一般論として捉えるとやや極端だったり偏っていたりするかもしれません。ポエムなので許して。 専門家であるという視点から エンジニアとして仕事をする以上、専門家 (プロ) であるという誇りと責任を常に持って欲しいと思います。 そのためにはその自信を裏付けるための知識が必要となります。 僕のいる Web やスマホアプリの業界は流行の移り変わりが激しく、新しい情報を常に追いかけ続けないとあっという間に置いていかれてしまいます。 しかしながら新しい知識を追いかけ続けるにも確固とした基本がないと、曖昧な知識の上にさらに曖昧な
スペック不足を補う思考法 - ちるろぐ
＊ 今日はスペックについて話そうかな。 僕が学校にはじめて登校した日、まるで猿の群れにほうりこまれた気分だった。向こうからすれば猿は僕のほうだったのだろうけど。 覚えられない。計算できない。カタカナ書けない。人と同じことできない。IQテストでは可愛い先生にふざけるなと怒鳴られた…。 パソコンにたとえるなら致命的なスペック不足。つまり、生まれたときから、情報を処理したり記憶する能力が圧倒的に足りていなかったんだ。 そんな僕がこの世界を生き抜くための生存戦略。今日はそれを紹介するよ。 photo by ryantron. 不要なアプリを削除する 低スペック最大の弱点は記憶容量（メモリ）が少ないところ。だから余計なアプリを常駐させちゃいけない。たとえば「プライド」や「悩み」なんかは、物心ついたころに削除したよ。 音楽や書物も容量を圧迫するから、保存したいデータは、ウェブクラウドにまとめてアップロ
Martin Fowler's Bliki in Japanese - 犠牲的アーキテクチャ
@@ -0,0 +1,37 @@ +http://martinfowler.com/bliki/SacrificialArchitecture.html + + +会議の席であなたは考えている。自分のチームが二年間かけて書いてきたコードのことを。そして決断に至る。いま打てる最善の手は、あのコードをすべて投げ捨てまったく新しいアーキテクチャを再構築することだ。死にゆくコード、それに費やした時間、自分が下し続けてきた判断。この決断は、あなたはどんな気持ちにするだろう？ + +多くの人にとって、コードを捨てるのは失敗の証だ。ソフトウェア開発の探索的な性質を考えれば、わからない判断ではないかもしれない。けれど失敗には違いない。 + +ところが、いま書ける最良のコードは二年経ったら捨てるつもりのコードだということはよくある。 + +私たちは長命なソフトウェアとして偉大なコードを思
ペヤングゴキブリ騒動について元食品メーカー営業・現ニートが言いたい
大前提として日本の食品メーカーの品質管理はおそらく世界トップレベルだよ それでも真っ白で清潔な無菌室をイメージしてるかもしれないけど、実際はめっちゃ汚いよ（もちろん品質的には問題ないレベル。） 2chでまるか食品工場を見て汚いだの食品を作る会社とは思えないって言ってる人いるけど、多分君たちが普段口にしてるものの工場行ったら卒倒するんだろうなぁ。工場は工場なのであって、おしゃれなインテリアや壁紙って実は衛生には全く関係ないんですよね。そもそも衛生面で見れば君たちの台所の１００倍は綺麗なんだよ 全身エプロン・マスクで台所に入るたびにエアシャワーでホコリ取って、それでも虫が入ってきそうな箇所には全部トラップしかけて毎日掃除・殺菌消毒とかしてる人いたらごめんなさい。あなたの台所は結構綺麗です。 そんなトップレベルの日本メーカーでも月間で異物混入が0件だったら野球でノーヒットノーランやるくらいすごい
受託開発の会社が本格的にWebサービスを開発・運用してみてぶつかった課題（只今5ヶ月目） - ヴェルク - IT起業の記録
うちの会社は、基本的に受託開発の会社ですが、自社サービス開発の両立を目指しています。その取り組みの一つとして、今年の5月、boardという受託ビジネス向けのクラウド型業務システムのベータ版をリリースし、8月に正式リリースしました。 昨年、PattoというスマホアプリCMSをリリースしていましたが、これはどちらかというとソリューション型の製品のため、今回のboardが、うちとしては初めての本格的なWebサービスです。 ベータ版リリースから約5ヶ月、正式リリースから2ヶ月が経ったところですが、これまでにぶつかった課題について書いてみたいと思います。 まとまった開発時間がとれない 当然ですが、できるだけ早く開発して、早くリリースしたいという思いがあります。しかし、基本的に受託開発を止めて自社サービスの開発をしていたわけではないため、1ヶ月がっつりとboardの開発をする、ということができませんで
適切なフリーランス料金を決めるための鉄則は、クライアントの思考プロセスを理解すること | ライフハッカー・ジャパン
フリーランスとして初めての仕事をいただいたとき、料金をどう決めたらいいのかわかりませんでした。高すぎればがめつい印象を与えてしまうし、安すぎては生活していけないし。あれから2年。ようやく、クライアントと私の双方にとってベストな料金設定のコツがわかってきました。 フリーランサーは大局的に見るのが苦手 私はウェブデベロッパーです。多くの同業者が、現在または過去の給料をもとに料金を決めています。給料はそのまま市場価値を意味するので、それを料金設定の基準にするというのは、一見妥当なように感じます。でも私は、それが間違いであることに気がついたのです。 フリーランサーの多くが、大局的な視点で物事を見られていません。料金設定に必要なのは、クライアントの予算にあなたの仕事が見合うかどうかを把握すること。クライアントの予算は知ることができても、その予算がどうやって組まれたかまではわかりません。ではいったい、
デザインが機械化されても心配しない理由
それって本当にオリジナル？ レスポンシブ？フラット？ビデオをつかった背景？CSSアニメーション？ゴーストボタン？いろいろな『トレンド』を見て勉強している間に、すべて導入されている 14ドルのテンプレートをすぐに手に入れることができます。 CMS を活用して情報が更新しやすいレストランサイトを構築したい？専用の WordPress テーマを使えばすぐに完成します。英語だからダメと思うかもしれませんが、UI のローカライズが簡単できるように工夫されているので、使うことを諦めることはありません。 制作者の視点で語られる『オリジナルのデザイン』には、ひとつの矛盾があると思います。最新のデザイン動向を追いかけ、それを実践することが良いデザインに繋がると考えることがありますが、トレンドになる表現はすぐにコモディティ化されていきます。オリジナルを求めているつもりが、誰でも使えるものをゼロから手作りにして
濱口秀司氏が語る「社内説得」のジレンマと解 | Biz/Zine
USBメモリの発明をはじめ、幅広い業種のイノベーションに携わってきた濱口秀司氏。誰も見聞きしたことがないイノベーティブなアイデアは不確実性が高いため議論を呼びやすい。そのため、イノベーションを実現するには、通常のマーケティング（エクスターナルマーケティング）の前にまずは、仲間や社内を説得すること（インターナルマーケティング）が不可欠だという。クリエイティブ層を悩ませる、マネジメント層とのコミュニケーションギャップを埋める「社内説得」に関して、濱口氏が豊富な経験から導き出した方法論を解説いただいた。前回の記事はこちら。 アイデアは構造に載せ「コンセプト」として伝える 図1:発想、説得（社内マーケティング）、認知（社外マーケティング） © Hideshi Hamaguchi ——組織内イノベーターが心得ておくべきコミュニケーションのポイントを教えてください。 組織内のマネジメント層とクリエイテ
pelletkachels | blog over bedrijven en feitjes en de pelletkachel
Welkom bij Pelletkachels.nl, jouw ultieme bron voor alles wat met pelletkachels te maken heeft! Maar we zijn meer dan alleen een platform voor het bespreken van warmtebronnen. Bij Pelletkachels.nl geloven we dat het delen van kennis en ervaringen over bedrijven en gebeurtenissen ook essentieel is voor het creëren van een betrokken en geïnformeerde gemeenschap. In dit blog duiken we dieper in de we
元『ぐるなび』のエンジニア起業家が語る、若手が「フルスタック」を目指すべきじゃない理由 - エンジニアtype | 転職type
SEやWebサービス開発者の理想の姿として、フロント～バックエンド開発からインフラ構築まで一通りこなすことのできる「フルスタックエンジニア」が脚光を集めている。米国IT企業の求人で使われ出したこの言葉は、近年の日本でバズワード化。その実現可能性をめぐって、さまざまな議論が繰り広げられるようになった。 そんな中、主にデータベース/ビッグデータ解析基盤の開発とコンサルティングを提供するITベンチャーINTHEFORESTで代表取締役社長を務めている冨田和孝氏は、「若いエンジニアがフルスタックエンジニアを目指すのはお勧めできない」と語る。 その理由は、自身の過去の経験から、「地獄を見る思いをするから」だと言う。 「とんでもない修羅場」でもつぶれないことがフルスタックへの道!? INTHEFORESTのホームページ 冨田氏は、2000年を前後して起こったITバブル期に、ある受託開発会社でシステム開
ソフトウェア開発時に気をつけてる振る舞い - futoase
他人と開発する多人数開発(2名以上)のお話。 なんとなく思ってること。 修正してください 仕様が変更になった上での変更であれば、修正ではない。 ので、「変更した理由」と「変更して欲しい意図」を説明する。 その前に一言、「修正」とかチケットで「修正」とつけてはいけない。 その人は「変更前の仕様」を充足した形で実装していたのだから。 バグを出した後の言葉かけ 僕は率直に、見つかってよかったと思うし、そう表現するのだけど、 人によって追い詰める言葉を発してしまう。 追い詰めると、次バグが見つかっても「気が付かなかったフリ」をされてしまう。 そうなると品質が下がる。意味が無い。 話を自己の経験100%で話してしまう 自分が得られた知見は重要なんだけど 働いてきた場所は10も無いだろう。というので 50%ぐらいに抑えて、後は他社の事例とか、 なんか優れたようなドキュメントとか開発の歴史事例とか それ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
『銀座でホステスをした人間としての意見〜女子高校生、女子大学生の皆様へ』
