カテゴリー別アーカイブ: 設計

[サンプルあり]機能設計書を作成する

機能設計書の記載

今回はLichtwork(リヒトワーク)で書く設計書のコンテンツの一つである機能設計について紹介します。機能設計は画面ごとの仕様やAPIごとの仕様といった内容を記載します。プログラミングを行う上で最も参照する仕様書の一つです。

フロント画面については大きく画面表示時の処理、タップといったアクションについての処理と項目を分けて書きます。APIについてはAPIが呼び出された時の一連の振る舞いについて記載します。 こういった一連の動きや挙動については。RedmineやBacklogのチケットといったタスク管理ツールに書いてしまったり、仕様変更の際にはその部分だけの指示書の形にすることも多いと思いますが、後で探すことが面倒なのと、仕様改変前後の違いがわかりにくいため、仕様書の形で一元化して残しておく方が後々メンテナンスやリニューアルの際にも役に立つと思います。

記載する内容

前回に引き続き、今回モデルケースとしてLichtwork(リヒトワーク)で開発したIntrappsというアプリ配布基盤をベースとした設計書となっています。これも前回と同様ですが受託で開発する時に画面(デザイン含む)と機能は大体決まってるけど、開発する人がいないというケースを想定しています。

続きを読む

プロジェクト全体についての設計書を作成する

全体設計の記載

今回はLichtwork(リヒトワーク)で書く設計書のコンテンツの一つである全体設計について紹介します。開発についての全体感を記載する設計書で、これをベースに細かい部分は「機能設計書(共通設計と画面設計を記載)」、「非機能設計書(可用性や性能、セキュリティ等について記載)」、「運用設計」といった各設計書に詳細を書いていきます。

Lichtwork(リヒトワーク)の場合、前回でも書きましたがサービスを開発メンバーにどう創って欲しいかを伝えるために設計書を書きます。昨今はコロナの影響もあり、チャットなど非同期にコミュニケーションを取るケースも多いと思いますが、設計書をかくことも、エンジニアとプロジェクトマネージャーのコミュニケーションの一つと考えています。近くにいれば口頭や伝わってくるカルチャーで自ら開発メンバーも判断することができるかと思いますが、リモートである場合は難しいと感じています。そのためにもどう創るかであったり、どのように進めていくか、何を求められていくかは可視化していく必要があると思っています。

記載する内容
続きを読む

設計書を創ること

Lichtwork(リヒトワーク)では様々な形でシステムやアプリの開発や運用をお手伝いさせていただいています。やはり開発についてのご依頼が多いのが現状です。

開発を行うに関して、Lichtwork(リヒトワーク)では設計書を「そこそこ」作成します。

弊社の場合、チームとしてまるっと開発やデザインを担当する場合と、プロジェクトマネージャーの立場で開発を支援する場合がありますが、前者の場合だと意思伝達に苦労することがないのですが、後者の場合は会ったことがない人との開発の業務になることもあり、どういう風に作って欲しいかをある程度提示する必要があるためです。もちろん、どういうものを開発したかお客様に提示する必要があるため(お客様が引き継いだ後困らないように)作成するということもあります。

故に状況によって分量の違いはあれど創っていることが現状です。

私が設計書をかく時に意識していること

私が設計を書くときは「使いやすく」や「便利に」、「メンテしやすく」、「自動で」などフワッとしているところを開発者に対して具体的な方法を提示することを意識します。

続きを読む