優先順位が口癖になる危機感 - ジンジャー研究室
開発サイクルの終盤に近づくと「今回は優先順位の高いここまでを実装して、残りは優先順位が低いのでまたの機会にしましょう」という話になりがちだ。自分もこれまで何度もそうしてきたし、その場の判断としては正しい。が、このやり方に味をしめて常にこの調子で進めて、なんとなく上手く仕事をこなしている気になってしまうことには危機感がある。 以下、普段考えていることを自戒を込めてメモしておく。（なお、筆者の経験は toB ・Web 系・自社開発が中心なので読者の置かれている状況とは一致しないかもしれない） 優先度が低いタスクに着手する機会が一生訪れない 仮にあるタスクの優先度を下げたとする。バックログを眺めるとそのタスクに着手できそうなのは３ヶ月後だ。そして３ヶ月後、やっとそのタスクに着手できるかというと、そんなことは決してない。３ヶ月の間にそれよりも優先度の高いタスクが積まれているからだ。タスクを消化する
t-wadaさん「質とスピード」カケハシ社内講演会 - KAKEHASHI Tech Blog
2023年9月25日、和田卓人さん（t-wadaさん）をお招きし社内講演会を開催しました。 和田 卓人さん / プログラマー、テスト駆動開発者 学生時代にソフトウェア工学を学び、オブジェクト指向分析/設計に傾倒。執筆活動や講演、ハンズオンイベントなどを通じてテスト駆動開発を広めようと努力している。 『プログラマが知るべき97のこと』（オライリージャパン、2010）監修。『SQLアンチパターン』（オライリージャパン、2013）監訳。『テスト駆動開発』（オーム社、2017）翻訳。『事業をエンジニアリングする技術者たち』（ラムダノート、2022）編者。テストライブラリ「power-assert-js」 作者。 Twitter: @t_wada GitHub: @twada 開催のきっかけ カケハシでのシステムの質とスピードの前提知識を理解し、改めてシステムの質についてチームで会話するきっかけにな
タベリー | とある仕様書 – Yamotty – Medium
グループ共有機能仕様書の公開に踏み切ったのは、10Xのプロダクトがどうやって作られているか、について部分的に触れてもらえると思ったから。 10Xでは「細かな実装・デザインの白兵戦」・「認知と理解を獲得していく空中戦」を一緒に戦えるプロダクト・マネージャーを育てていきたいと思っているので、この仕様書を読んで「10Xで力を試してみたい！」という方はぜひ以下のフォームから応募してほしい。ユーザーの感情を科学できる人が10XのPMにはフィットすると思う。 仕様書の前提となる考え仕様書は「チームのワーキングスタイル」によってその役割をかえるものだ。今の10Xは「ユーザーの前に積まれた膨大な課題の山に優先度を付け、とにかく早くプロダクトをプッシュしていくこと」が最優先のチーム。 そのため、「膝を突き合わせて瞬発力の高いコミュニケーション」を重視している。リモートはしない。 この環境では議論のすべてが口
失敗して気づく「意図の伝わる設計書」の書き方
どんなにシステム開発工程の標準化が進んだとしても、多かれ少なかれ“Art”の領域は残る。平たく言えば開発者個人の「経験」「力量」に依存する部分である。 設計書の作成もそうだ。設計書の標準フォーム（ひな型）があったとしても、そこに「設計意図が正しく伝わる文章や図表」を書き込めるかどうかは、設計者の腕による。この領域には絶対的な“正解”や“ルール”は存在せず、システムの特性や関係者とのコミュニケーションレベルなど、様々な要因によって最適解は変化するだろう。 連載『意図が伝わる設計書作成の心得』では、実際の失敗例を通して「意図の伝わる設計書の書き方」のポイントを紹介している。プロジェクトの状況を踏まえた上で、どんな設計書ならコミュニケーションツールとして最適なのか、一緒に考えてみてほしい。ここで論じている内容は、決して文章力や図解テクニックの話ではない。「設計者の基本的な心得に依存するもの」と連
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
SimpleとEasyは違う / Simple is not Easy
Wantedly（ウォンテッドリー）はたらくを面白くするビジネスSNS
