トップ  > メモ一覧  > カテゴリ「プロマネ」の絞り込み結果 : 5件

5件中 1 〜 5 表示  1 

No.1454 安全なWebアプリケーション開発のための発注・要件・検収

安全なWebアプリケーション開発のための発注・要件・検収 アジェンダ
  • セキュア開発をベンダーに促すにはどうすればよいか
  • セキュア開発においてコストを低減するには
  • セキュア開発の要件定義はどう考えればよいか
  • セキュア開発で大切な3つのこと
    • セキュリティ要件とセキュリティバグ
    • 開発標準と教育  
    • セキュリティテスト
  • セキュリティテストツールとしての「ウェブ健康診断仕様」

引用元

更新:2009/09/07 21:08 カテゴリ: web開発  > プロマネ ▲トップ

No.1381 意識しておきたい「修正」と「変更」

意識しておきたい「修正」と「変更」

こんにちは、モバイルディレクターの飯田瞬です。

ディレクターの皆さんは、「修正」と「変更」という言葉に対してどのようなイメージを持っていますか?

どちらも現状あるものに手を加えるという点では同じに見えるかもしれませんが、自分の置かれている立場や状況によって、意味合いやプロジェクトに与えるイ ンパクトが自分の予想以上に違ってきたりします。特に対外的なやりとりを多く行うディレクターはこの部分にセンシティブになったほうがいいかもしれませ ん。

そこで今回は「修正」と「変更」の違いについて紹介いたします。

修正


発注側と受注側の立場で置き換えると、受注側に誤りがある場合は「修正」(もしくは「訂正」) を用います。

たとえば、ウェブサイトのデザインを外注に発注していたとします。発注側は「青系統のサイト」を依頼しましたが、外注先から上がってきたデザインは「赤系統のサイト」でした (あくまで極端な例です)。

発注側は「青系統のサイト」で発注していたので、明らかに受注側のミスになります。このような場合、発注側は受注側に対して「青系統のサイトに修正してください」と修正である旨を伝えます。

変更


「修正 (訂正)」が受注者側の誤りでしたので、「変更」は発注者側の誤り (もしくは純粋に方針変更) の場合に用います。

先ほどのたとえ話の続きで、「赤系統のサイト」を「青系統のサイト」に修正してもらいましたが、青系統はどうもイメージとマッチしなかったので別の色で作り直してほしいと依頼したとします。

一番最初の発注から方針を変えた依頼になりますので、受注側には一切瑕疵がありません。このような場合は、発注側は受注側「黒系統のサイトに変更してください」と変更である旨を伝えます。

そこで、明らかに発注側の意志によるものなのに「○○に修正してください」と依頼すると、受注側は「え……これはこちらがミスした訳じゃなから変更だよね……」と思わせて心証を悪くしてしまうかもしれませんので、細心の注意が必要です。

使い分ける意味


それぞれの違いが分かったところで、使い分けることでどんなことが見えてくるのでしょうか。

よく「ゼロサムゲーム」にたとえられるのですが、先方の「変更」を聞き入れて「貸し」を作っておき、こちらの修正を最低限にすることで、作業交渉の引き合いにすることがあります (言うは易く行うは難しですが)。

また、営業側の立場だと「修正」や「変更」の違いは料金交渉やスコープ交渉の材料になる場合があります。「修正」が多いと、こちらが弱い立場になってしまうのはなんとなく分かるかと思います。

社内でのやりとりではそこまで神経質になる必要は無いかもしれませんが (現場の人のほうが敏感だったりします)、業務に対する取り組みとして意識しておいて損は無いと思います。

ディレクターとしての心構え


そもそも、ディレクターは「修正」「変更」の発生を極力少なくすることが務めになります。「修正」「変更」が多いプロジェクトはディレクションがうまくいっていないのではないでしょうか?

デザインの発注段階であらかじめ複数パターンを作ってもらうことや (複数パターン依頼する調整も予算内で済ませておく)、リテイクは何回まで大丈夫か? などさまざまな調整を済ませておくことで、お互い気持ちよく仕事できることかと思います。

引用元

更新:2009/08/26 09:05 カテゴリ: web開発  > プロマネ ▲トップ

No.1246 ディレクターが押さえておきたい営業取引の基本的な流れと頻出ワード

ディレクターが押さえておきたい営業取引の基本的な流れと頻出ワード

ディレクション
こんにちは、小久保です。

私の経歴は、受託開発のディレクター → 自社媒体のディレクター → 事業責任者 という流れを経ておりまして、以前「受託開発事業から自社媒体事業へシフトするための意識改革のポイントとは?」という記事を書きましたが、実はキャリアパスの中で一番焦ったのが営業面での知識不足でした。

受託開発を担当している時は、開発工数と人月単価さえおさえておけば渉外対応はある程度事足りていたのですが、自社メディアの場合だと提携内容の検討と営業的な話は一体となって進むことが多く、必然的に営業的知識が必要になってきました。

今回は、営業職の経験が無いディレクターの方でも、ビジネス上で最低限これだけは知っておいたほうが良いと思う、営業面での知識について紹介します。

まずは、一般的な取引成立までの流れをまとめてみましょう。以前、弊社の「ビジネススキル勉強会」というブログに「取引行為についての勉強会」を社内でやりましたと書きましたが、今回はもう少し、ディレクターの立場から見ての流れに沿って説明してみます。

c55e4ab0


それでは順に説明していきます。

(1) 打合せ


何はともあれ、まず大枠の取り組みに関しての打合せです。この段階では、いきなり細かい情報の話をするのは避けましょう。技術情報や数値情報など、会社として外部に公開していない情報のやり取りをするのは、NDA(秘密保持契約)を結んでからにしましょう。

(2) NDA締結


ということで、具体的な情報開示をするために取り急ぎNDAの締結を行います。「NDAの雛形はどうしましょうか?」と聞かれることが多いですが、通常は 大きな会社の方にあわせた方がいいと思います。これは大企業ほど契約稟議の調整に時間がかかるため、あらかじめ用意された雛形のほうが早いからです。

(3) 情報開示


NDAが締結できたら (または並行して)、必要な情報を相互に開示します。

(4) 条件交渉


提携の具体的内容・ビジネススキームを交渉し、大枠合意が取れたら契約書の作成に取りかかります。後にも述べますが、このあたりで相手方の会社の与信をかけ取引きを問題なくできるかどうかの確認を行います。

(5) 契約書雛形作成


通常は提案した側が契約書の雛形を作成します。既に提携実績のあるサービスの場合、雛形は作られていることがほとんどですので、それをたたき台として詰めていきます。

(6) 法務確認


法的な確認の前に、担当ディレクターとしてざっと見ておかしい部分は先に先方と調整を済ませておく方がよいでしょう。その後、法務部や担当弁護士に契約書雛形の確認を回しますが、基本的にはすべて履歴付きのWordファイルでやり取りすることが多いと思います。

(7) 争点の交渉


弁護士等から大抵いくつかの修正点が入ります。弁護士の基本スタンスは会社の不利益にならないように防御するということが主ですので、ガチガチに防御する 文言が赤入れされて戻ってくることでしょう。そこから、相手方との駆け引きになりますが、最終的には会社間の力関係で落としどころを見つけることになりま す。

(8) 契約締結


無事争点がクリアできたら、最終版のファイルにて契約書の製本・押印にうつります。こちらも雛形を作った方が2 部製本して、押印→一部ずつ保管という流れが通例です。ここで、一点大変重要なことなのですが、最終版のWordファイルと、製本されて届いた契約書が同 じものであるかは、絶対に確認しましょう。意図してか、うっかりかに関わらず、製本されたものが最終版でない場合があります。最終的に残るのは押印をした 紙の契約書なので必ず確認しましょう。

(9) 取引開始


ここまで済んで初めて取引が開始できますが、契約書の締結に思ったより時間がかかってしまい (特に争点の調整に時間がかかったりします)、リリースに間に合わないということがしばしばあるので注意が必要です。特にお互いの弁護士主張のバトルに なって泥沼化することも少なくないです。

(10) 請求/支払


取引が行われたら、契約書に書かれた条件に基づき、毎月の請求や支払が行われます。特に問題なければ期日どおりの請求・支払が行われますが、こんなご時世 ですので支払いが遅れる会社が出てきたりして、滞留債権として問題になるケースもあります。営業取引はお金を回収できるまでが重要ですので、こういったア ラートが上がったら速やかに取引見直しの対処をしましょう。

(11) 契約更新


契約には必ず期間というものがありますが、いつからいつまでの契約なのかは常に把握している必要があります。気が付いたら1年自動更新されていた……など ということがないように。また、契約変更・中止する場合には必ず「何ヶ月前or何日前に申し出ること」ということが記載されていますので、その告知期間の チェックも重要になります。

また最後に、営業取引で頻出する用語について、いくつか私なりに説明したいと思います。

営業取引における頻出ワード


●契約期間
契約書には必ず、契約期間と、更新の条件を盛り込みます。契約期間はその名の通りですが、トライアル期間を設けて、「初回3ヶ月契約、以後1年ごとに更 新」のような形にすることもあります。また、更新の条件については、「自動更新か否か?」「条件変更する場合は事前通知期間はどれくらいか?」ということ を盛り込みます。

支払サイト
支払サイトとは、取引代金の締め日から支払日までの日数のことを言います。「○日締め、○日払い」といった書き方をしますが、その内容でOKかは、社内の経理部門に必ず確認をした方がよいと思われます。

●与信管理
与信とは、そもそも取引する相手が信用できる相手なのか?を判断することになります。信用調査会社が提供する、各企業の評点というのがあって、そのランクによって信用度が計れるものになります。有名な信用調査データとしては、帝国データバンク東京商工リサーチなどがあります。

●覚書
契約書本体には個別の金額などを直接記載せずに別紙という形で覚書に記載したり、契約を締結したあとに修正事項が発生した場合などは、覚書を後追いで結ぶことがあります。「じゃあ、その件は別途覚書を結びましょう」などと、とても便利な感じで頻出するワードです。

●証票 (請求書など)
注文書・検収書・売上報告書・請求書など商取引において様々なものがあります。会社によって必須となるものや、省略できるものが違いますので、事前に確認しておくべきでしょう。

●ビジネス条件・経済条件
要はお金に関する条件の話です。慣例として一通り提案内容を説明した後に「さて肝心のビジネス条件についてですが……」と最後におもむろにお金の話を切り出すことが多いです。

●締め日
「○日までに請求書を送ってもらえないと月内に処理できませんよ」なんてことを言われて社内を走り回った経験ありませんか? 特に大手企業の場合はそうですが、 25日までに請求書の原本が無いとだめですとか、会社によって事情が違いますので、しっかりと事前に確認しておく必要があります。

●売上計上・費用計上
いつ売上として計上できるのか? 費用として乗っかってくるのか?これを認識していないとエライことになります。これは受託でもそうですが、検収書の日付がいつになるのか? は予算を持っている人にとっては死活問題とも言うべき確認事項です。

●エクスクルーシブ (競合排除)
案件によっては契約の条件として、独占契約を条件とする場合があったりします。契約書には競合指定したサービスとの併用は不可と明記されたりしますが、一般的には「エクスクルーシブな契約」などと呼ばれます。

●レベニューシェア (料率)
ビジネス条件の代表的なワードですが、サービス収入をどのような割合でシェアするか? というのを示すものです。

●マージン (営業手数料)
商品によっても違いますが、代表的なもので広告の代理店マージンが挙げられます。広告の場合、広告主への販売料金を「グロス金額」と言い、そこから代理店マージンを除いたものを「ネット金額」といいます。例えば「媒体様へのレベニューシェアはグロスから代理店マージンを除いた金額の40%になります」のように使います。

バーター
もともとは物々交換の意味のようですが、契約交渉の中でも頻繁に出てくる用語です。一方の条件を飲むために、一方の条件を要求する時に使いますが、あんまり良い印象の用語では無いかもしれないです。

●ビジネスジャッジ
これこそ万能な言葉ですが、結局のところ、会社としてのリスクをどこで取るかというのを、最後はビジネス上で判断せざるを得ません。契約内容をいくら弁護 士が強気に出たとしても、双方折り合いがつかない場合には、最終的に会社としてどういうジャッジをするかという点に尽きます。その場合には、「この争点についてはビジネスジャッジとして丸飲みします」というような表現をします。

いかがでしたか?この他にもビジネス上で慣例となっている、もっと「ゆるい大人語」みたいなものもあると思いますので、またいつかご紹介したいと思います。

引用元

更新:2009/07/31 08:41 カテゴリ: web開発  > プロマネ ▲トップ

No.1240 少人数グループのカンタン便利なタスク管理術!

少人数グループのカンタン便利なタスク管理術!

webサイト開発
こんにちは。ブログビジネスユニット ディレクターの浪越です。
前回は『ライブドアに入社したばかりの私が驚いたこと』と言うエントリーを書かせていただきました。今はしたらば掲示板の担当ディレクターとして頑張っています!

現在は、したらば掲示板の管理画面の全面リニューアルを進めています。
この度、10年(ライブドアに移ってから5年)ぶりに管理画面をリニューアルすることになりました。目標は、長年使い慣れたユーザーと、新しいユーザーに受け入れられる管理画面作りです。

作成したエクセルの見本


今回はシステム全てリニューアルということで、大量のテンプレートを作成することになりました。
ガントチャート等便利な管理ソフトは色々ありますが、多機能過ぎました。
あくまで全体のどの程度が終わっているのか、を確認する『タスクの可視化』をしたかったのと、開発する人の手を煩わせない簡単なものを…と思い、辿り着いたのは、自作のエクセルファイル管理シートです。

実際どのようなファイルだったかというと――

schedule

こちらはマークアップエンジニア用のシートです。
デザイナー用、エンジニア用はまた別にシートがあり、それぞれのタスクが完了し、日付にが入るとマークアップ用のシートの SignOK 表示に変わり作業を開始できます。
お互いが横で確認をしあわなくても、自分用のシートを確認していれば問題がないように作ってあります。

基本編


今回は上のようなファイルを作るための手順をご説明いたします!
使うのは、IF関数AND関数OR関数です。

各関数の簡単な説明です。

IF関数
If(条件,真の処理,偽の処理)
条件に当てはまれば、真の処理をして、それ以外であれば偽の処理をします。
AND関数
AND(条件,条件,...)複数の条件を合わせて、全ての条件が揃うと真の値を返します。
OR関数
OR(条件,条件,...)
複数の条件のうち、どれか一つでも当てはまれば真の値を返します。

d_blog01

higaくんの参加条件>
goくんが「いくよ」と言っていて、kohakuraくん兄弟のどちらかが「いくよ」と言っているとき。
・なので、kohakuraくん兄弟が「いくよ」と言っていても、「いくよ」とは言いません。

ではこの判別式はどうなっているかと言うと、

<判別式の解説>
=IF(AND(C4="いくよ",OR(C5="いくよ",C6="いくよ")),"いくよ","いかない")
C4セルが"いくよ"と記入されている上に、C5セルかC6セルのどちらかに"いくよ"と記入されていた場合は、条件を満たすので、セルに"いくよ(真)"と記入する。
それ以外の場合は条件を満たさないので、"いかない(偽)"と記入する。

お祭りには、goくんもkohakura兄弟も参加するので、higaくんも参加表明をしました。
他のイベントを見ていただければ分かるように、kohakura兄弟がいくら参加すると言っても、goくんが参加しないものには、頑なに参加表明はしませんでした。

応用編


では少しシートを分けて、実際に近いものを作ってみたいと思います。
新しい関数として COUNTIF関数 を使います。

COUNTIF関数
COUNTIF(範囲指定,カウント対象)
指定された範囲の中に、カウント対象の文字がいくつあるか数えます。
カウント対象は、文字であれば "" で囲い、数字であればそのまま書くことが可能です。
また、セルに記入されたものを対象にすることもできます。
(ex> A1 セルに OK とあったら、指定された範囲内から OK の文字を探します)

d_blog02

これはデザイナーさんのスケジュールシート(シート名 : DE)です。
○は完成した作業を、△は未完成ですが作業を進めて問題ないことを指しています。
COUNTIF関数は、○と△が同じ範囲内に同居しても、計算式を二重で換算しないように条件分岐として使用しています。

それでは、達成度に入っている、判別式を見てみましょう。

<判別式の解説>
=IF(COUNTIF(E3:K3,"○")>0,$D3*1,IF(COUNTIF(E3:K3,"△")>0,$D3*0.6,0))
まずIF関数で条件分岐が行われます。
E3〜K3の範囲に"○"が0個以上あれば、条件を満たすので、作業量(D3)×1をかけた数値をセルに記入しなさい。
ここで、真ではなかった場合は、偽の処理に入りますが、更にここに入れ子でIF関数がきています。更に偽の中で条件が分かれ、E3〜K3の範囲に"△"が0個以上あれば、条件を満たすので、作業量(D3)×0.6した数値をセルに記入しなさい。
条件を満たさなければ、0を記入しなさい。

となります。エンジニアさん(シート名 : PG)も同じつくりになっています。問題はデザインとプログラムが済まないと作業に入れないマークアップエンジニアさんのシート(シート名 : ME)です。

d_blog03

重要な Sign の判別式を見てみましょう。

<判別式の解説>
=IF(AND(DE!C3<>0,OR(PG!C3<>0,PG!C4<>0)),"OK","Wait")
まずIF関数で条件分岐が行われます。
DEシートのC3が0以上かつ、PGシートのC3もしくはC4が0以上の場合、OK を記入しなさい。
それ以外の場合は Wait を入力しなさい。


となります。これで、自分のタスクシートだけ管理していれば、作業が可能になった場所を確認することができます。

また、メニューにある「書式」→「条件付き書式」を選択すると

d_blog04

条件によってフォントを変えたり、背景色をつけたりすることができます!重要な箇所目立たせたりするのに重宝します。
(※私が使用しているのは Office2003 です。メニューの箇所はバージョンにより異なる場合があります。)

今回作成したファイルをアップしますので、ご参考になればと思います。
サンプルファイルをダウンロード

一言メッセージ


まだまだディレクターとしての経験が少ない私ができることは、開発のメンバーが迷いのないように進められるように全力でできることをするしかない、と思いました。エクセルは集計を行うのが主だとは思いますが、このようにスケジュール管理シートも自作することが可能です。

d_blog05今進行中の管理画面は、八月の初旬に公開予定です。最後に少しだけ開発中の画面をお見せいたします。チラリッ。


いかがでしょうか?ライブドアではコンテンツの新しい姿を誰よりも早く知りたいディレクターを募集しています。

引用元

更新:2009/07/30 09:48 カテゴリ: web開発  > プロマネ ▲トップ

No.743【引用】他社と共同開発していく際の心得

他社と共同開発していく際の心得
livedoor ディレクター Blog(ブログ) ld_directors

こんにちは。コミュニティビジネスユニットの菊地です。
最近「腰が低すぎる」と指摘され、精一杯偉そうにふるまおうと躍起です。
それはどうでもいいんですが。

今回は、他社と共同で一つのサービスを開発していく際の心得と、その仕様を自社の開発スケジュールに落とし込んでいく際の、エンジニアとのコミュニケーションに関する心得をご紹介します。

■他社との共同開発における心配事とは?

例えば、...

引用元

更新:2009/03/22 01:03 カテゴリ: web開発  > プロマネ ▲トップ
5件中 1 〜 5 表示  1 

FuelPHP

Mac

フロントエンド開発

web開発

プロマネ

マネタイズ

プレゼン

webサービス運用

webサービス

Linux

サーバ管理

MySQL

ソース・開発

svn・git

PHP

HTML・CSS

JavaScript

ツール, ライブラリ

ビジネス

テンプレート

負荷・チューニング

Windows

メール

メール・手紙文例

CodeIgniter

オブジェクト指向

UI・フロントエンド

cloud

マークアップ・テキスト

Flash

デザイン

DBその他

Ruby

PostgreSQL

ユーティリティ・ソフト

Firefox

ハードウェア

Google

symfony

OpenPNE全般

OpenPNE2

Hack(賢コツ)

OpenPNE3

リンク

個人開発

その他

未確認

KVS

ubuntu

Android

負荷試験

オープンソース

社会

便利ツール

マネー

Twig

食品宅配

WEB設計

オーディオ

一般常識

アプリ開発

サイトマップ

うずら技術ブログ

たませんSNS

rss2.0