いまこそ「良い仕様書」がチームの生産性の鍵となる。ので、仕様書に含めたい 14 のポイントについてまとめました。｜Fritz | Lead Product Manager @ Mercari
いまこそ「良い仕様書」がチームの生産性の鍵となる。ので、仕様書に含めたい 14 のポイントについてまとめました。 こんにちは、フリッツ です。今回はプロダクトマネージャーの日課とも言える「仕様書」について。自分にとっては PM 業の施策実行フェーズにおいて最も重要な仕事のひとつであり、最も心躍り、最も興奮する瞬間です。 PM になってかなりの時間が経ちましたが、「仕様書」への力の入れようは減るどころか、「もっと気合を入れなければ。」と感じる一方。在宅勤務が（たぶん） IT 業界のニュースタンダードとなっていくいま、なおさら「仕様書」の重要性を訴えたい今日この頃です。 ということで、今回は ・ 良い仕様書がもたらす 5 つの効果 ・ 仕様書の重要性が増していく 2 つの理由 ・ 仕様書に含めたい 14 の項目・実戦編 ・ 仕様書作成時に心に留めたい 3 つのこと ・ 具体的な仕様書サンプル（
Excel設計書を抹殺したくて4年前にWiki設計書を導入したら、意外とちゃんと開発回ってた話。 - Qiita
初めましてこんにちは。 最近コードレビューの記事書いたら、Excelベースだったことを理由に Qiitaコメントとはてブで徹底的に燃やされたおじさんです。 いやね、僕だって使いたくて使ってるわけではなくてね、 できることなら使いたくないんですよ。 というわけで名誉挽回のために脱Excelできた話、 それも日本の三大悪三大風習に数えられるExcel設計書を抹殺した話を書きます。 (2/25修正：悪は言いすぎました。訂正します。） Growi 最高。 またの名をExcel方眼紙。 エクセルのセルの縦横を同じくらいの大きさに調整し方眼紙のようにして、 そこに設計書として文字と図と表を記載する方式。 メリット 一つのファイルに文字と図と表がまとめて記載できる テキストでは文字は書けても図と表が書けない Wordでは、文字と図表エリアとを2列表示するのが難しい できなくはないが面倒くさい UMLモデ
プレーンテキスト Markdown 時代の終焉
なぜ Day One は Markdown を捨てたのか Day One が Markdown をやめて WYSIWYG に移行した話は前書いた。 Day One がクソになった Day One 、このブログでも度々言及していて、 Markdown で日記が書けて便利だったんだけど、最近のバージョンアップ（ Mac は 2.8 以降 、 iOS は 3.0 以降）でプレー... portalshit.net 自分が知っている範囲でアンチ Markdown 勢は Scrapbox くらいしか思い浮かばず、 GitHub や Trello などのグローバル勢に加え、 Qiita やはてなブログなど日本国内向けのサービスでも当然のように Markdown が共通言語として使われているのに、その Markdown を捨てて WYSIWYG 化する1という戦略は疑問だった。 ひとむかし前の WYSI
全人類に告ぐ。セル結合をやめろ。 - hibitの技術系メモ
（12/13追記 タイトルや表記に過剰な表現があり、セル結合を全否定するかのような印象を与えてしまいました。そのような意図はなかったのですが、補足記事を書きましたので、併せて読んでいただけると幸いです。すみませんでした。） 人類よ、なぜそんなにセル結合を使いたがる？ それが罪深い行為とも知らずに……。 思わず神視点になってしまいましたが、この世界にはExcelのセル結合を無意味に使いたがる人が多すぎます。いや、メリットがないことはないのですが、それを余裕で上回るデメリットがあることを意識している人が少ないように思われます。データというのは、コピペしやすいこと、集計しやすいこと、数え間違いをしづらいことが第一なので、それを損ねるような行為は許されざる大悪というべきでしょう。断固として弾劾していきます。 綺麗なデータとは ここにエクセルで作った、同じソースから作成した3種類のデータ（東京都の区
「誰が書いても同じコード」は大事なことなのか - ひがやすを技術ブログ
昨日、大手SIerの方々と話をする機会があって、そこで出てきたのが、「誰が書いても同じコード」になることが重要で、それを実現するために、ドキュメントをいっぱい書かなくてはいけないという話。大手SIerは、大体同じことを考えていると思います。 でも、「誰が書いても同じコード」にするってのは、そもそも無理だと思うんだよね。そうやって、わざわざドキュメントをたくさん書かせても、めためたなコードを書くやつはいて、総合テストするときに、現場は燃え上がるもの。ある程度の規模以上のプロジェクトなら、どこでもそんな感じじゃないかと思います。 重要なのは、「誰でもメンテナンスできるコード」にすること。そのために、コーディング規約は、きちんと決めてみんなで守る、それ以上は、がちがちに縛る必要はない。 がちがちに縛るために、設定ファイルをたくさん書かせたり、必要以上のドキュメントを書かせるのは、一定の品質を確保
Matzに聞いてみた：効率の良い開発についてどうお考えでしょう？ - builder by ZDNet Japan
曖昧になる技術の境界線 ウェブエンジニアを取り巻く状況は混沌としている。まずは知っておかなければ行けない分野が飛躍的に増えている。HTMLやCSS、JavaScriptはもちろん、ときにはRubyまでもやらなければいけない、さらにはデータベース（DB）のことも知っておかなければならない、といった具合だ。 さらには、どこからどこまでをどの技術でやるべきかという見極めも難しい。たとえば、Ajaxアプリケーションを作る際、JavaScriptを使ってフロント側で処理するのか、バックエンドでRubyで処理するのか、あるいはどこまでをバックエンドで処理すべきなのか。どこからどこまでをJavaScriptですればいいのか。そうした技術の境界は、どこにあると見るべきなのか。ウェブ開発の分野では、技術の境界が曖昧になっているのである。 この“曖昧になる技術の境界”に対して、Ruby開発者であるまつもとゆき
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
なぜExcel方眼紙は嫌われるのか？ 「Wordより使いやすい」「生産性を下げる」など賛否分かれる（1/2） | IT・科学 ねとらぼ調査隊
東大で学んだ卒論の書き方★論文の書き方
【2ch】ニュー速クオリティ:大学生が勧めるフリーソフトウェア。