PMにはなぜ設計論がないのか？ | タイム・コンサルタントの日誌から
前回の記事（「プロジェクト＆プログラム・アナリシス研究部会」（12月2日）開催のお知らせ）でも少しふれたが、なぜPMBOK Guide(R)には「設計論」がないのか、不思議に思われている方も多いと思う。米PMI (Project Management Institute)が'90年代に作成し、現在は改定第６版になっているPM界の標準ガイドブックは、10個のマネジメント領域を定義している（最初は9個だったが、途中からStakeholder Engagementが加わって、10個になった）。その10のエリアには、「調達」や「品質」があるのに、肝心の設計マネジメントがない。 プロジェクトにおいて、もしも設計がまずかったら、実装段階でどんなに頑張っても、良いプロダクトは生まれない。つまりプロジェクトの価値は上がらない訳だ。プロジェクト・マネージャーの任務は、プロジェクトの価値を最大化することのはず
Developers.IO 2018 で「API 設計」の話をしてきた #cmdevio2018 | DevelopersIO
緊張すると声がアムロ・レイになる都元です。 ここからしばらく、キャッチコピーの迷走期が始まりますのでよろしくお付き合いください。 さて、去る 10/5 (金) 秋葉原 UDX にて開催された Developers.IO 2018、その中で 「クラスメソッドにおける Web API エンジニアリリングの基本的な考え方と標準定義」 という仰々しいタイトルで1講座持たせていただきました。 スライド 話したかったことと、話したこと 本セッションで話したかったことはだいぶ多岐にわたり、当然 40 分では話しきれないので、当初は次の 2 テーマに絞ってお話しようと考えてスライドを作っていました。 アプリケーション動作ログガイドライン RESTful / リソース指向 API 設計 しかし実際にスライドを作ってみると、それぞれで 40 分の規模となってしまい…。 ログの話は断腸の思いで見送りとさせていた
ランキング設計はどうあるべきか？ その3｜深津 貴之 (fladdict)
ここまでランキングのあるべき方向性と、実行可能なアプローチについて考察してきた。そして、いよいよプロトタイピングと実験の時間だ。残念ながら自分はサーバーサイドのコードが書けないので、ここからは開発チームに託すことになる。 妄想や実証不能なものをオーダーするのは非効率だと思う。ある程度はクラスをモデリングしておくと、エンジニアとディスカッションしやすい（ように思える）。 とりあえずnoteでのランキングは、様々な試行錯誤や実験が予想される。そのため、以下のような要素が必須となる。 ・工数最小 ・あらゆるランキングを表現できる ・拡張しやすい 今回はDecoratorパターンとCommandパターンを混ぜたような実装で、柔軟性のあるランキング計算システムのコンセプトを描いてみた。下手なコードでも、設計がある方がエンジニアさんに説明しやすい。 設計イメージとしては、まずランキングの各処理を同じイ
イベント・ソーシングを知る
This document summarizes a microservices meetup hosted by @mosa_siru. Key points include: 1. @mosa_siru is an engineer at DeNA and CTO of Gunosy. 2. The meetup covered Gunosy's architecture with over 45 GitHub repositories, 30 stacks, 10 Go APIs, and 10 Python batch processes using AWS services like Kinesis, Lambda, SQS and API Gateway. 3. Challenges discussed were managing 30 microservices, ensur
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
system-design-primer#system-design-interview-questions-with-solutions
