一緒に読まれている質問
- W3QはTters内にてサービス継続中です。今後とも当サービスをご愛顧のほど、よろしくお願い申し上げます。
- CSSのpadding-topで画像のアスpeクト比が調整できる仕組みがバカだから全然理解できないままとりあえず使ってる...
- ディスクリプションとかキーワードとかseo的になんの効果もないのに聞きかじった知識披露するクライントって何なんだろうこん...
- 単発の案件で作った Slack のワークスペースって終わったらどうしたらいいん？ 継続して取引のあるクライアントなら残し...
- 一般的にiPhoneユーザーってGoogleアカウント持ってるもんなの？特に20代～30代で。肌感でもいいから教えてくだ...
14 件の回答
なお開発自体は外部Sierに委託して作ってます。
そして私はWebデザイナーあがりのディレクター(インハウス Web担当)です。システム開発は専門外っす。
仕様書？ 運用マニュアルの間違いでは？ 仕様書ならその外部SIerから取り寄せろ。
Re:3
コメントありがとう。その外部SIerがまったく役に立たず(作りかけの古い仕様書ならあるのですが)、普段の保守チケットも数ヶ月ほったらかしとかザラな状況で更新を待ってたらいつになるか分からず。仕方なく内部で作ってる所存です。
開発運用も関わるので仕様書が必要なんです。運用マニュアルも兼ねて。
自社で使うならWiki立てれば？
Re:4
協力会社に対して「まったく役立たず」とか言う奴がディレクターの会社とは仕事したくないな
「仕様書」というのが具体的に何を説明しているドキュメントなのかはっきりしませんが(仕様書ではなく運用マニュアルのような印象を受けますが。ちなみに業界一般的に、仕様書と呼ばれるドキュメントには、要求仕様から基本設計・詳細設計に至るまで多岐に渡ります)、
基本的に仕様書を作成する場合はドキュメントリーダーとなるシステムエンジニアが対応しているはずです。そして、多くの場合で仕様書が「ない」という状況はありえません。ゴリ押しで推進されスクラムのようなフレームワークを採用して構築した場合なら別ですが。少なくとも、コードはあります。
Webデザインを齧っただけの素人にシステムやアプリの仕様書は作れません。未知の仕様やロジックを発見したり考慮することが出来ないためです。社内SEや然るべきパートナーに協力を仰ぐべきでしょう。
まあ、そもそも仕様書ではなく運用マニュアル程度のものであったとしても、開発経験のない人が一定の品質を担保するレベルで作成することは困難です。不可能ではないかもしれませんが。あきらめるか、試行錯誤するしかありません。
非技術者が仕様書をかけるわけがないので、主が言ってるのは運用マニュアルだな。
というより、非技術者だからこそ仕様書の意味を知らないのでしょう。
まず、そのマニュアルの目的を明確にすれば、少なくとも質問の意図は、はっきりするでしょう。
ご意見ありがとうございます。
非技術者同士で話をして作っているので本来の意味での「仕様書」ではないのかもしれません。
盛り込んでいる内容はシステム開発運用に必要となりそうな情報です。
例えば、顧客の利用データや料金を日次月次でグラフ表示でき目標設定などもできる機能があります。CSV出力ができたりもします。
その機能がいつどういう目的で作られて、どの部署が管轄で、データはどこから取ってきているか(客先に設置している端末からデータベースを経由して取り込んでいるものと、社内の基幹システムからと、直接入力と、機能ごとにいろいろです)、データはどことどう紐づいているか、計算テーブルはどうなっているか、機能表示フラグ、機能開発時の関連チケットNo、注意点、画面キャプチャなどなどです。
例えば今後仮に新料金プランができて新たな契約種別と計算テーブルの追加が必要になったみたいな時や、最近あった例だと、CSV出力したファイルのデータがおかしい、みたいな問い合わせがあった際、開発会社に正しく依頼するためにも把握しておくべき内容が記載されていて欲しいと考えてます。
そういうドキュメントは現時点ではないんです。
これって「運用マニュアル」なんですかね？
Re:9
このWebシステムを主幹していた元々の部署に、非技術者ながらシステムに詳しい人Aがおり、A主体で外部開発会社とスクラム開発でどんどん機能追加されていった経緯があります。要求仕様書的なものはその都度Aが書き起こしたいろんな形式のファイルがありますが、開発チケット上でどんどん変わっていったりしてるのであまり意味がなく、その開発にドキュメントが追いついていない状況と思われます。
Re:9
仕様書は建築で言えば設計図。当たり前だが建てる前に作るもの。それナシで行き当たりばったりでやってきてて、そのSIerに頼んでもまとまったものが出てこないから自分で建物から設計図を逆に起こしてると。ほおほお。
技術者でも困難だよ。頑張ってねとしか言いようがない。
ネガティブな意見が散見されますが、主は制約の多い環境でかなり頑張ってると思います。現状に対する責任はないにも関わらず。応援されて然るべき事ですので、落ち着いて物事を進めてください。
さて、すでに稼働しているサービスの今後の開発運用という観点でドキュメントを整備しなくてはないらないのであれば、まずは速やかに網羅的な資料を作成してください。見た目や使いやすさ、粒度は二の次でいいと思います。もちろん、成果物として納品される権利があるのでしたら、検収しなくても良いです。主が体験されているように、システム運用は時間とともに形骸化し、やがてブラックBOXと呼ばれる状態になりがちです。まずは、俯瞰に努めてください。いずれにせよ、システムを運用するということは様々な専門性が必要とされますので、ひとつひとつのディティールにこだわっていては道のりが遠くなるだけです。
賢明な主なら、それくらいのことは心得ているかもしれません。しかし、これから主管となる以上、必要なのは全体を見渡せることです。このレスにあるような細かい話は専門家にさせましょう。粗くても全体が網羅されてきたら、システムの脆弱な部分やユーザー操作に関するところからなど優先順位を付けてブラッシュアップするのがいいと思います。追加開発が終わっていない箇所は、担当Aに責任を持つよう促してください。大事なことは、ブラックBOXにする担当者は今後もそれで良しとする傾向があります。それは、主の基本的概念と相反するので、可能ならば今後は権利を剥奪するのも良いでしょう。
少しでも納得されるようでしたら、続けます。
Re:12
少ない情報から見事に状況をお察しいただき、嬉しいです。泣きそうです。
頂いたアドバイス、大変参考になります。全体を俯瞰するための網羅的な資料、まずはこれを進めたいと思います。
しかしながら「終わっていない追加開発」がいくつかあり、本番機リリースされたところで引き継いだのですが不具合やバグだらけ。元主管部署はもう知らぬ存ぜぬといい(なので権利剥奪する必要はなさそうです)、その機能を使う部署からは使い物にならんとクレームが入り、今は無心で修正依頼チケットを発行している状況です。システム仕様もよく分からぬまま。
ドキュメント整備はこの目の前の炎上案件を消火してからになりそうです。
顧客が使うWebサービスなのにUIが酷すぎて(開発にデザイナーがまったく関わってこなかったので)、デザイナーとしてはその辺を整えたく。
開発自体がグダグダとなるときっちり仕切り直した方が良さそうだけどね。よかれと思ってだとしても色んな立場の人が勝手に動き出したりするとやばい。要件、指揮系統の確認など関係者と協議するのをお勧めする。