仕様書を書く上で必要かなと思うことをまとめてみた。 対象者は、まだ仕様書なんて書いたことないよとか、何書くかいつも悩む、という方。 ここでいう仕様書とは、開発前の設計書というよりは、運用フェーズに引き渡す前に用意しておいたほうがよいドキュメント、という位置づけ。 仕様書の目的 仕様書を書く目的は、新しい人がチームに来た時に、スムーズに業務に取り組めること。 また、「人は時間が経つと必ず忘れる」ので、将来の自分のためでもある。 大事なこと 仕様書の目的を明確にする。 あれもこれも、と情報をたくさんのせても混乱する。 「仕様書にもメンテナンスコストがかかる」ことに注意する。 仕様書は正しい日本語で書く。 主語をきちんと入れることが大事(〜のつもりで書いた、というのは知らない人には伝わらない)。 情報は多すぎず、少なすぎず。 条件について場合分けして整理したり、図を用いたりすると良い。 前提と制

【3】意外と難しい「単体テスト」，「結合テスト」の区別（1/2） 次に，「単体テスト」と「結合テスト」という分類の仕方について考えてみることにしましょう．冒頭の例でいうと，Gさんが担当しているモジュールの単体テストを終えたら，次の工程で全体の結合テストを実施することになります．単体テストから結合テストへという進め方は，一つ一つ部品を確実に組み立てる立場からすれば当たり前のことのように思えます．しかし，実際の開発ではこの「単体」と「結合」の区別はそれほど容易ではありません． 開発者の中には，「単体テストとは関数一つ一つに対して行うもの．それらの確認が終わって初めて結合テストができる」とやや教条主義的に考えている人もいます．また，結合テストはビッグバン・テスト（単体が終わったら全体を一気につなげる）以外考えず，段階的に結合していくことにはあまり関心のない人もいます．このような考え方が行き過ぎる

粒度の大きな部品を組み合わせることで ITスキル関係なく誰でもかんたんに本格システムを構築 楽々Framework3は、チームの情報共有ツールから企業の基幹系システムまで幅広い開発に対応したローコード開発基盤です。 品質が担保された、業務でそのまま活用できる部品を組み合わせるだけで、最小限のコーディングで本格的なWebシステムをかんたんに構築。システム開発の属人化を防ぎ、システムの品質を高めます。 開発スキルを持つ人材の採用に苦戦している 本格的な基幹システムを自社で開発したいが、対応できる人材がいない 開発の属人性が高まり、新しいメンバーへの教育・学習コストが上がっている 事業のスピードに開発が追いつかず、ユーザ部門の要望に応えられない 現状はベンダーにシステム開発を任せているが、いずれは内製化したい

開発青木室長と赤井君の活躍のほか、開発ベンダの若井さんのサポートなどもあり、ようやく製造工程も終了に近づきました。前回の「やってはいけない、『製造工程』の丸投げ」で、発注担当者の開発ベンダへのかかわりあい方などについて解説しました。今回はテスト工程がテーマです。テスト工程では、どんなことに気を付けるべきかなどについて説明していきたいと思います。 (2/3)