設計書

はじめに なぜ設計をするのか？ 情報の共有 作業の分離 開発手法と設計の位置づけ ウォーターフォールの設計 設計書の構成 何を主眼とすべきか スクラムの設計 設計書の構成 何を主眼とすべきか まとめ 終わりに はじめに DIGGLEエンジニアのaki0344です。 去年から専任のスクラムマスターとして活動しています。 最近設計について思うところがあり、記録の意味も込めてブログにしてみました。 なぜ設計をするのか？ みなさん設計していますか？ 1つのプロダクトを2～3人程度で開発しているような環境では、明確に設計という工程を設けずにいきなり実装を行っているかもしれません。 あるいは、納期に対して…

初めまして。株式会社シー・エス・エス、ファイナンシャル・ソリューション開発部のこじこじです。 普段は証券系のシステム開発のプロジェクトに携わっております。 唐突ですが昨年11月に発生したボイジャー１号の通信トラブルのニュースはご存じでしょうか？同機から送られてくるバイナリコードが意味をなさない状態で送られてくるようになったというトラブルです。この問題に対処するためボイジャー１号に対してコマンド入力が必要になったのですが、そのコマンド自体がどの様な影響を与えるのか調べるために打ち上げ当時のエンジニアが書いた資料を参照して対応を模索しているという内容でした。 そんな宇宙規模の話とはスケールが小さく…

物事には衝撃的な事実もあるもの・・・ 以前の設計資料を見ていて・・・ 「なんだこの日本語！書いたやつだれだよ！」 てなって・・・ もう、マジで勘弁してほしい。なに言いたいのかさっぱりわからねぇぇっぇ！と、部下とも四苦八苦して解読した で・・・ 結末 ひと段落したので、当時の履歴を確認したら・・・ 衝撃の結末が！！！ 「あ！作ったの俺だわ！」 笑えない・・・

今日Xでこんなことを呟いてみた 個々のロボットに対して技術的観点からのレビューしかできず業務観点で質の高いレビューができなくなってきたとき、頑張って業務理解する時間を確保すべきかどうか。まぁ1日でレビュー終わらせようとせずに数日時間もらって、業務/技術観点でのレビュー日を分けるとかして工夫するしかないかなぁ — いろはまる@RPAエンジニアCEO (@irohamaruRabbit) 2024年2月1日 ここ数ヶ月、開発メンバーにも業務理解と最適化、RPA化ができるよう、僕がしゃしゃり出るのをちょっと控えている。もちろん僕が完璧にそれらができるというわけではないし、むしろ僕をどんどん超えてほし…

新人OJTネタです。 機能開発における仕様書のレビュー。 今回、仕様を説明するために、初めて仕様書を自分で書いてもらうことに。 そして、その仕様書の説明会に向けて、まずは個別にレビューで説明してもらいましたが… ・・・うん、分からん（笑） 第一印象は、何を言っているかがチンプンカンプン。 最初に出てきた初版を見ると、文字がずら〜〜っと書いてある状態。 箇条書きもなければ、図も表もない…。 国語のテストとかでよく見る「長文」が果てしなく続いているような感じですね。 ・・・ちょっと目を離すと、今どこを読んでるんだ？というような内容。 これでは、聞いている方は何が書いてあるかがさっぱり・・・。 なの…

アプリなりシステムなんかを作っていると、 設計書を書くことが多いと思うのですが、 結構書くの難しいですよね〜。 人の設計書を見てても、自分で書いたりしていても思うのですが、中々難しいです。 自分に対する戒めも含めて設計書あるあるを書いていこうかなと。 やりたいことがやたらと書かれている 設計書なので、ある程度実現性が見通せたものを記述する必要があるのですが、 これが中々難しいです。 どうしても、仕様から抜け出せないんですよね。 仕様を実現するための設計を説明するためには、何を作るかからどうしても説明してしまうんですよね。 ただ、これをすると仕様書の内容を焼き直すだけになって、イタズラに量が増え…

最近はVisual Studio Code（以下VS Code）の記事のばかりですね。今回はリバース・エンジニアリングしたプログラムの処理をPlantUMLを使って、マークダウン形式のファイルで整理しました。その際、PlantUMLのデフォルトのデザイン（見た目）があまり好みではなかったため、デザインの変更を行いました。 今回の記事ではVS CodeをつかったPlantUMLの使い方（とくにマークダウンでの記載方法）とPlantUMLのデザイン変更の方法を紹介したいと思います。 PlantUMLのデザイン変更の方法では、全体的なデザインの変更方法と個別にオブジェクトのデザインを変更する方法を紹…