システム開発を依頼する前に、具体的な開発工程や流れを事前に把握しておきたいという方は多いのではないでしょう。そこで今回は、システム開発工程を10段階のフェーズに分けて紹介するとともに、各フローの具体的な作業内容や注意点を分かりやすくまとめます。さらに、気になる費用相場やおすすめのシステム開発会社など、事前に知っておくとためになる情報を合わせて紹介しますのでぜひ参考にしてください。
はじめに 本稿では、仕事をする上での作業工数の見積もり方法について説明します。 工数とは何か 工数(こうすう1)というのは、仕事において、あるひとつの作業を完了するまでにかかる総累計時間のことです。情報処理技術者試験に出てくるTAT(ターンアラウンドタイム)とは意味合いが異なります2。 例えば、ある作業に40時間(40H3)かかるとした場合、工数は40時間であるといえます。1日8時間勤務だとした場合、40時間は5人日(にんにち)と表現することができます。さらに、1ヶ月20日勤務だとした場合、0.25人月(にんげつ)と表現することもできます。 一般的に工数の単位は「人日」および「人月」で扱います。 学生時代は工数を気にすることはないですが、ITエンジニアとして会社で働くようになると、かならず工数を意識する必要があります。 なぜ工数を意識する必要があるのか なぜ工数を意識する必要があるのかとい
WBSの作り方は組織構造に依存するという記事がとても参考になったのでメモ。 【参考】 WBSはプロジェクト組織を規定する : タイム・コンサルタントの日誌から WBSはコスト見積の基準を規定する : タイム・コンサルタントの日誌から 【1】ガントチャート初心者からよく聞かれる質問は、「WBSは工程単位に作った方がいいですか?それとも機能単位に作った方がいいですか?」だ。 話を聞くと、工程単位にチケットを作ってみると、実際の開発フローに合っていない感触があり、途中で、機能単位にチケットを作り直す時が多いらしい。 WBSの作成方法は、工程単位と機能単位のどちらが正しいのだろうか? (引用開始) さて、3つの機能モジュール×3段階の作業プロセスだから、合計9個のアクティビティからなるプロジェクトである。 これをWBSに構成するとき、二種類の表現が考えられる(IT系の仕事になじみのない人は、「シス
こんにちは、らくからちゃです。ぶらっとTwitterサーフィンしておりますとこんなツイートが目に留まりました。 「なんでもポジティブに考えれば幸せになれる」っての、まるっきりウソだから。現実のネガティブな側面を直視して受け入れることで、不安がなくなり、的確に現実に対処できるようになり、成功確率がぐっと高まり、はるかに幸せになれることなんて、いくらでもある。 — ふろむだ⭐️若い頃知りたかったこと書く (@fromdusktildawn) 2018年2月17日 すげーわかる。 確かに『すごーい』『たーのしー』と言いながらお仕事をしていても、ヤバめな何かを『あれ大丈夫なのかな・・・』『もしかしてヤバくない...?』と不安を抱えながらだと、全く楽しめません。 で、こうした不安を綺麗さっぱりしてお仕事を楽しむため、弊チームでは定期的に『怒らないからヤバいと思っていること全部言う会』を開催しているの
リスト型としては リスト と、 キー・バリューリスト の2種類ありますが、リスト型を選択しました。 キー・バリューリストは値にリスト選択肢文字が割り当てられるため、選択肢文字の設定を変更すると既に登録済みのチケットの内容も変更されます。 とても便利な機能ですが、インシデント管理ではそれぞれのチケットは内容を変更せず、記録として残すべき対象と考えられます。 今回はあえてリスト型を採用しています。 設定例:情報源 設定例:事象経過 カスタムフィールド作成画面で対象となるトラッカーとプロジェクトにチェックを入れることで利用可能になります。 表示フィールドのカスタマイズ 画面上に不必要なものが表示されていると操作者は混乱してしまいます。これらを整理します。 まずトラッカーとワークフローで不必要なフィールドを消しましょう。 トラッカー 使用するトラッカーにて標準フィールドの項目から使用しないフィール
インセプションデッキとは インセプションデッキとは、プロジェクトの全体像(目的、背景、優先順位、方向性等)を端的に伝えるためのドキュメントです。ThoughtWorks社のRobin Gibson氏によって考案され、その後、アジャイルサムライの著者 Jonathan Rasmusson氏 によって広く認知されるようになりました。 インセプションデッキについては、Jonathan氏のブログ「The Agile Inception Deck」にて説明を読むことができます。 Jonathan氏が作成したインセプションデッキのひな形 インセプションデッキ(Inception Deck)を直訳すると「最初のデッキ(カードの束)」という意味となり、アジャイルプロジェクトにおける「プロジェクト憲章」に近い意味合いを持ちます。 プロジェクト憲章とは PMBOKにおけるプロジェクト憲章(Project Ch
昨年末、ブログをネタにTwitterで議論したことを akipii さんが「アジャイル開発にはモデリングや要件定義の工程はあるのか、という問題とその周辺: プログラマの思索」というエントリにまとめてくださいました。ありがとうございます!。 ブログで書かれたことに直接の返答にはならないのですが「アジャイルにおける事前合意はどうあるべきか?」ということを書きたいと思います。 アジャイルは最初に全てのCDSを決めない まず、狭義のアジャイル開発プロセスは優れたマネジメント手法です。システム開発を評価するQCDS(品質/コスト/期日/スコープ)ですが、Q(品質)というは「そのシステムにとって問題ないレベルにする」でしかないので、CDSの調整が論点になります。 ウォーターフォール型開発というのは、 「スコープは最初に確定」し、 「コストや期日はスコープを達成するために必要な分を最初に設定」し、 必要
軍事ドクトリン(原則)や戦略書、兵器の変遷史などを読むのが好きです。 戦争が好きなわけではなく、とても勉強になるからです。戦争というのは、有史以来、全文明がもっとも真面目に研究し、アップデートを繰り返してきた分野です。なので、最も合理的かつ実践的なノウハウが詰まっています(軍事が合理的でない国は、だいたい滅びました)。 これらの知識を、応用ができることはいっぱいあります。限られた時間やリソースでの意思決定や、ライバルとの競争、団体競技などなど… 以下は、ジョン・フレデリック・チャールズ・フラーという、英国陸軍の人が提唱する陸戦原則。この原則は、世界中の陸軍教練に広く取り入れられています。デザインやビジネスなどでも、非常に使い勝手良いかなと感じています。 (上のリストは、厳密にはフラーのオリジナルでなく、彼のセオリーから米軍が作った改訂版「1986年版の米陸軍の野戦教範100-5」ベースの、
エンジニア組織を強くするための本を出版しました Qiitaでエンジニアリングをめぐる様々なコミュニケーションの問題とその解決策や考え方を書いてきた。それらの背後にあるエッセンスをこの度書籍として出版するに至りました。 エンジニアリング組織論への招待 ~不確実性に向き合う思考と組織のリファクタリング この書籍は、エンジニアリングを「不確実性を削減する」という第一原理で捉え直し、様々なエンジニアリングとその間のコミュニケーションをめぐる現象を説明していくものです。 はじめに 何かはじめてのことをする場合、人はとても「不安」を感じます。人は未来を考えることができる生き物です。その特異な能力ゆえに、未来に起こるかもしれないよくないことを考えると「不安」を感じてしまうのです。 仕事のプロジェクトなどは、「間に合わなかったらどうしよう」とか「この仕事はちゃんと終えられるのだろうか。」など、未来のことを
ユーザーストーリーとプランニングポーカーを使ってアジャイルに見積もりしよう! By tracpath • 2016-09-02 • Development はじめに アジャイル開発に興味がありますか? スクラムなどのアジャイル開発には、いくつかのプラクティスがあります。アジャイル開発のプラクティス中には「ユーザーストーリー」と「プランニングポーカー」があります。 この2つは、実際に開発をはじめる前の計画づくりに力を発揮します。ウォーターフォール型の開発のように、一気に見積もりや計画を行っても予定通りに進むことはありません。アジャイル開発を導入して、少しずつプロジェクトを前進させていきましょう。 この記事では、アジャイル開発に興味があるエンジニアの方のために、ユーザーストーリーの作り方とプランニングポーカーのやり方をお伝えしていきます。まわりのエンジニアの方を巻き込んで、実際にやってみてくだ
多機能で汎用的なプロジェクト管理ツールを利用したい。 複数の管理ツールを使い分ける手間を減らしたい。 プロジェクト管理ツールの乗り換えを考えている。 OpenProjectの紹介 OpenProjectはオープンソースのウェブベースプロジェクト管理ソフトウェアです。Ruby On Rails 5.0で開発されており、ライセンスはGPLv3です。 主な機能を列挙します。 タイムライン管理・カレンダー タスクボード・バックログ管理 ロードマップ・リリース計画 タスク管理・ウォッチ機能 タイムトラッキング・コスト・予算管理 Wiki・フォーラム バクトラッキング・イシュートラッキング Git・Subversionリポジトリのサポート 最近話題になるプロジェクト管理ツールは最低限の機能を備えたミニマム志向なツールが多い中(2017年時点)、このOpenProjectは最初から豊富な機能を備えていま
私は仕事でシステム開発プロジェクトに発注者側として関わることがあります。 ソフトウェア開発と建設工事はよく似ているといわれますが、両方みてきた経験からしても確かに似ているかも。 長期にわたるプロジェクト体制が組まれ、そこには多くの関係者が関わります。 受注するのは大手企業でも、1次請、2次請は当たり前。最末端では「何を作っているかも分からない」ことも多いプログラマたち。かなり過酷な労働環境で働いています。最近では日本語がわからない外国人がオフショアでコーディングしていることも多いですね。 ただ建設業とソフト開発で決定的に違うのは、進捗が目で見えないところ。建設工事なら「もう3Fまで出来上がったな」と、素人目でもわかりますが、ソフトウェアはそうはいきません。 そのため、ソフトウェア開発の進捗管理は、コンサルティングファームなどからくるマネジメントのプロでも至難を極めます。 開発プロジェクトと
先日、2013/3/23(土)に弊社でチケット駆動と開発環境に関するイベントを開催しました。リンク先には資料も上がっていますので参照ください(※アトラシアン製品関連のイベントです)。 基調講演にはチケット駆動開発を推進されている関西XPUGのあきぴーさんをお招きして「チケット駆動開発をパターン言語で読み解く」という話をしていただき、最終枠ではパネルディスカッションをしました。 チケット駆動開発とウォーターフォール パネルディスカッションでは、僕が「チケット駆動開発を作業計画に使うのは難しく、WBSとの併用が現実的」と話し、あきぴーさんが「作業計画をチケット駆動開発で回していくには」というノウハウを紹介されていました。 この違いは僕がウォーターフォール的な新規案件を、あきぴーさんがアジャイル的な開発/保守運用案件を前提にしているためです。 僕自身はBTS(Bug Tracking Syste
最近、久しぶりに『人月の神話』という書籍を読み返して、改めて「やはりこの本はスゴイ」と感動したので、その内容をシェアしていきます。この書籍は私のようにSI業界で働いている人なら、一度は読んだことがあるでしょう。それほどとても著名な本なのです。 SIとはSystem Integrationの略で、簡単に言えば「システムを導入しようとしている顧客の面倒を最初から最後まで全部みる」という意味になります。 顧客の権限がやたら強くて、「締め切り厳守」をSI企業に押し付けた場合、SI企業はついつい投入する人員の数を増やして対応しようとします。しかし、それは間違いです。その間違いをより論理的に指摘したのが『人月の神話』になります。 この書籍で語られている概念は、IT企業で働いている人や投資を考えている人はもちろん、複数人で仕事をしている人なら誰でも知っておくべきことだと思います。(『ウォーレン・バフェッ
tl;drコードレビューが上手く回って無くてチームが疲弊して辛かったよレビュアーの言い方を変えるだけで大体解決するよ立場とかで例外を許さず、みんながレビューしてレビューされると良いよはじめにあるプロジェクトでGitHubのPRベースでのコードレビューを導入をしました。いかんせんチーム開発が初めてレベルの新人さんが多く、何かと苦労しました。特にレビュイーに対して不効率な指摘はそのまま指示の不明確さに繋がり、チーム全体の開発生産性を下げるので、レビュアーはレビュイー以上に気を使う必要があると感じました。下手をすると、レビュイーのメンタルが弱って闇堕ちするので、チームメンバーの最も大人な人がメンタルケアしたりします。大人な人は大体がリーダー格なので、その人の時間が奪われると何かと開発現場が疲弊しちゃいますね。コードレビューってそんなに難しいものだっけと思ったりもしますが、反省の意味も込めて実際に
「技術的負債だらけのチームで技術マネージメントしてみた」の公開資料が素晴らしいのでリンクしておく。 【参考】 akipiiさんのツイート: "すごく良い資料。RT @yassan168: #kichijojipm 発表資料upしました。誰かの役にたてば良いのだけど。connpassにもUPしています。>技術的負債だらけのチームで技術マネージメントしてみた https://t.co/3R25aUnI4S" 前任の仕事を引き継ぎしたら、下記の問題があったらしい。 技術的負債込みで引き継いでしまった、という例は、本当によくある。 (引用開始) 1年前の状態 ・すべてがメールベース ・ドキュメントはほぼ無い ・最強の属人化。個人のパワーで乗り切る ・技術に関心が無く誰も行動しない ・暫定スクリプトが今も元気に本番稼働中 ・ソースには、ほぼコメント無し ・hoge.pl.(日付) 形式のソース管理
第18回Redmine大阪の見所~「チケット管理システムによるソフトウェア開発支援と今後の課題~気象庁のRedmine利用事例報告」 来年2月3日に開催予定の第66回 SEA関西プロセス分科会&第18回 Redmine大阪の見所を書いておく。 【参考】 第66回 SEA関西プロセス分科会&第18回 Redmine大阪 - connpass 気象庁の数値予報課におけるRedmine利用事例: プログラマの思索 【1】(引用開始) テーマ~「チケット管理システムによるソフトウェア開発支援と今後の課題」 今回の勉強会のメインセッションでは、気象庁の担当者の方にRedmineやGit等によるソフトウェア開発支援の事例報告を講演して頂きます。 気象庁|数値予報課報告・別冊 第63号(平成28年度) 数値予報モデル開発のための基盤整備および開発管理 気象庁におけるソフトウェア開発プロセスの事例で興味深
Redmineを受け入れて貰うためのプラグイン紹介の記事が素晴らしいのでメモ。 WF型開発に固執した古い体質の現場で、Redmineをいかに使いやすくするか、という観点で読むと、とても参考になる。 【参考】 Redmineを受け入れて貰うためのプラグイン紹介 - Qiita 親チケットの詳細ページに表示される子チケットの一覧項目 - Google グループ 【1】(引用開始) Redmineは小規模なチームでも比較的簡単に導入できる、素晴らしいソフトウェアだと思います。 ただ、このようなツールを知らない人や絶対Excelマン達にとっては、得体の知れない面倒なモノと思われてしまうこともあります。 そういった人たちにも積極的に利用して貰うためには、日々の業務で感じるイライラを極力減らす努力が必要ではないでしょうか。 この記事では、Redmineを少しでも快適に使って貰うため、開発者にとって有用
印籠を見せた途端、悪代官も無法者も平伏する。そういう印籠をシステム開発などのプロジェクトに関わる人は持つ必要がある。 途中で理不尽な要求を出してくる悪代官のような役員。賛成と言っておきながら全く協力しない無法者のような現場の部長。印籠があれば、彼らに要求を撤回させ、協力させることができる。 ここまで書いたものの、2017年にITproを読んでいる方々は上述の光景を理解できるのだろうかと少し気になった。だが、「プロジェクトマネジャーの身を護る印籠」という表現をした人がいるので踏襲する。 チャーターが印籠になる 印籠とは「チャーター」を指す。印籠に例えたのは、神庭PM研究所の神庭弘年所長である。チャーターとは、何らかの活動あるいは組織の狙い、活動範囲、参加者の役割と責任などを記載した文書を指す。プロジェクトチャーター、チームチャーターなどがある。 印籠になるのは「承認されたチャーター」である。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く