複数スペースのBacklogの課題をspreadsheetで一覧表示
Backlog、便利ですよね。
筆者もここ数年、プロジェクト管理ツールはBacklogを使っています。 ツール自体が素晴らしいのは言わずもがなですが、Backlog自体が普及しているということが一番の理由かなと思います。 筆者の場合は付き合っているベンダーさんもBacklogを利用していて、現在は3~4スペースのBacklogで10以上のプロジェクトのタスク管理を行っています。
※Backlogのスペースは、プロジェクトの上位概念で1スペースで複数のプロジェクト管理が出来ます。 スペースが複数となってしまうのは、契約者が違うからです。 自社のBacklogやベンダーさんのBacklogが存在するので複数スペースになってしまいます。
スペースの説明はこちら。 スペース ID とは？ - Backlog（Japanese）
複数スペースのしんどいこと
複数のスペースがあると、筆者自身のスペックの問題もありますが、正直チェックがしんどいです。
理由を考えてみましたが、
- スペース各々でログインしないとタスクがチェック出来ない。
- 全体を俯瞰出来ないので、自分はどれから取り掛かるべきかがわからない。
- 個人の問題が大きいが、好きなプロジェクトばっかり見がち。
- Backlogはタスクの更新があればアラートメールが飛ぶからいいじゃんという話もあるが、全プロジェクトを見る立場になってくると、アラートの数が大量で、とても追いきれない。
複数スペースの課題をチェック出来るツールを作りました！
ネットで似たようなことを考えているか人がいるか探しまして、下記の記事にたどり着きました。
この記事のツールの場合は1スペースにある複数プロジェクトを俯瞰してみるのには良いんですが、やりたいのは複数スペースの全プロジェクトの中で私がやるべきタスクを俯瞰して見たいわけです。
ただ、Google Apps Scriptで結構簡単にBacklogのAPIを利用できるのと、Google Spread Sheetは使いやすい！というのがわかりましたので、作ってみました！
Google Apps Script
とりあえず、コードを張り付けておきますね。大分、さきほどの参照記事のコードを参考にしています。
function main(action) { var IssuesSheet = SpreadsheetApp.getActive().getSheetByName('issues'); /* 一旦、シートをクリアにする */ if(IssuesSheet.getLastRow() > 1){ IssuesSheet.getRange("A2:I"+IssuesSheet.getLastRow()+"").clearContent(); } /* ヘッダをセットする。 */ IssuesSheet.getRange("A1").setValue("space"); IssuesSheet.getRange("B1").setValue("url"); IssuesSheet.getRange("C1").setValue("summary"); IssuesSheet.getRange("D1").setValue("createUser"); IssuesSheet.getRange("E1").setValue("priority"); IssuesSheet.getRange("F1").setValue("status"); IssuesSheet.getRange("G1").setValue("dueDate"); var issuelist = get_issues_lists(IssuesSheet); } function onGet(event) { main('on_manual'); } /* space分の課題を取得して書き込む */ function get_issues_lists(IssuesSheet) { var Confsheet = SpreadsheetApp.getActive().getSheetByName('config'); var range= Confsheet.getRange(2, 1); var values = Confsheet.getRange(2, 1, Confsheet.getLastRow()-1, Confsheet.getLastColumn()).getValues(); var range= IssuesSheet.getRange(2, 1); for(var i=0;i<values.length;i++){ var backlog_team = values[i][0] var backlog_api_key = values[i][1] var backlog_assigneeid = values[i][2] res = UrlFetchApp.fetch("https://" + backlog_team + ".backlog.jp/api/v2/issues?apiKey=" + backlog_api_key + "&assigneeId[]=" + backlog_assigneeid+ "&order=&statusId[]=3&statusId[]=2&statusId[]=1&count=100"); if (res.getResponseCode() != 200) { return false; } // Logger.log("res :" + res); var issues = JSON.parse(res.getContentText()); write_issues(backlog_team, range, issues); range = range.offset(issues.length, 0); } } /* 課題をシートに書き込む */ function write_issues(backlog_team, range, issues) { for(var i=0; i<issues.length; i++) { range.offset(i, 0).setValue(backlog_team); var issue_url = "https://" + backlog_team + ".backlog.jp/view/" + issues[i]["issueKey"] range.offset(i, 1).setValue('=HYPERLINK(\"' + issue_url + '\",\"' + issues[i]["issueKey"] + '\")') range.offset(i, 2).setValue(issues[i]["summary"]); range.offset(i, 3).setValue(issues[i]["createdUser"]["name"]); range.offset(i, 4).setValue(issues[i]["priority"]["name"]); range.offset(i, 5).setValue(issues[i]["status"]["name"]); range.offset(i, 6).setValue(issues[i]["dueDate"]); } }
どんな感じで使うか
見た目はこんな感じです。
モザイク掛かっているのでわかりにくいですが、複数スペースの自分の課題が一覧で取得できました。 これでいちいち各スペースにログインする手間が省けます。 更新は[update]ボタンで行います。
シートに色がついてますが、これはGoogle Spread Sheetの条件付き書式を使っているだけです。 筆者の場合は優先度が「高」のものを目立つように、「低」のものは目立たないようにしました。 これは個人の好みですね。 納期で色分けしてもアリかと思います。
設定はどうしてるか、ですが、別のシートにconfigをまとめています。
ここで、各パラメータについてですが、
「backlog_team」はスペース名になります。
「backlog_api_key」とはBaklogのメニューから「個人設定」＞「API」でAPIキーを新規登録すればすぐに作れます。 こんな画面です。
「backlog_assigneeid」は各スペースでの自分のIDになります。確認方法ですが、課題の検索画面で自分担当の課題を表示したときにurlに「backlog_assigneeid=*****」みたいなパラメータを確認出来ると思うので、それを入れます。
すぐに使えるSpreadSheetをご用意しました
いろいろ説明しましたけど、使い勝手は使ってみて確認するのが一番です。 すぐに使えるSpreadSheetをご用意しましたのでご自由にどうぞ。
Backlog All task - Google スプレッドシート
必ずコピーして使ってください。 Google Apps Scriptもコピーしないと参照出来ないと思いますし。
あと、ご使用は自己責任で！
紙からWebメディアの編集を始める編集さんに知っておいて欲しいこと
前にこんな記事を書きました。
この問題ってデザイナーだけでなく紙媒体からWebメディアの編集を始めた方にもあるかと思います。
つまづく部分って似ているのですが、今回は編集にフォーカスして、留意しておいて欲しいことを書いてみます。
「おれは編集だからWebデザインは知らね(*´Д｀)」っていう編集はいないと思いますし、編集はデザイナーに指示を出すことも多いので、先の記事の内容は読んでる体で書きます。
- Webメディアはタイトル命
- サムネイル画像も重要
- SEOを踏まえた文章を書く
- コンテンツは流通する、プラットフォームの存在
- 記事の単価について
- SNSの存在
- フロー型のコンテンツ、ストック型のコンテンツ
- 広告について
- 校正が雑なわけじゃない、文化が違う
- 今後さらに、紙からWebに移る編集は増えていく
- 編集長はひっぱりだこ
- 誰とWebメディアを作るのか
Webメディアはタイトル命
- Webはクリックされて始めて見られる
先の記事でも書きましたが、この点を補足しますとWebメディアはタイトルが紙より10倍重要です！
タイトルはいろんな期待を背負っています。
- クリックされなければ見られない
- SEOも考えなければいけない
- ソーシャルでシェアされたい
タイトルの重要さはこちらの記事からもわかると思います。
あと、Webメディアは紙と違ってテンプレートにはめるので、タイトルに文字数の制限を設けているケースが多いです。
Yahooトピックスの13.5文字という制限は業界でも有名な話ですよね。
ただタイトルが短いと良くわからない場合があるので、記事ページ用、サムネイル用の2種類のタイトルを設けたりします。
サムネイル画像も重要
クリックされるサムネイル画像については、こちらの記事も参考になります。
彼らは主観に固執せずデータに基づいてノウハウを貯めていますよね。
これはWebっぽい考え方なんだと思います。
また、出版出身の方ってピンボケした写真は許せないと思いますが、Webメディアだと全然ありです。 むしろ写真が綺麗すぎると広告臭がしてクリック率が下がるというケースは多いと思います。
当ブログはサムネイル画像を設定していないくせに偉そうですが(;^_^A
SEOを踏まえた文章を書く
見る・読むのは人間だけではない
先の記事でも書きましたが、文章はSEOという集客方法のキモです。
おすすめの本を挙げておきます。
- 作者: 瀧内賢
- 出版社/メーカー: 技術評論社
- 発売日: 2012/10/11
- メディア: 単行本（ソフトカバー）
- 購入: 3人 クリック: 21回
- この商品を含むブログ (20件) を見る
この「SEO内部対策の教科書」は私がメディアを立ち上げるたびに、編集さんに薦めている教科書的な存在です。
SEOは大きく分けて内部対策と外部対策があり、内部対策というのはコンテンツそのものの対策を指します。
編集はコンテンツを作るのが仕事です。
ですからSEOがわからないWebメディアの編集はもう通用しません。
SEO内部対策をざっくり説明すると、ユーザのニーズが高いキーワードをtitle,description,h1,h2,strongのような重要なタグにバランスよく設定することです。
あと共起語の考え方も抑えおきましょう。
また、外部対策についてもコンテンツは有用です。
外部対策とは外部のサイトからリンクをもらうこと（バックリンク）で、SEOの効果を上げることを指します。
良いコンテンツというのは、
- 当ブログも有用な外部のコンテンツのリンクをたくさん貼っています。こんな形でバックリンクを得られます。
- SNS自体はSEO効果はあまりないですが（はてなブックマークは効果あります！ぜひ当記事もブクマしてくださいｗ）SNSにシェアされることにより、やっぱりバックリンクを得られやすくなります。
- 良いコンテンツというのは、後述する記事の流通により、バックリンクがもらえる可能性があります。ただし、媒体から得られるリンクはnofollow*1のケースが多いですが、たまにdofollowのリンクが得られます。
また、外部対策は競合サイトを良く調べるということが有用です。
それについては当ブログでも書いていますので、SEOの知識を深めたい方は、ぜひ読んでみてください。
コンテンツは流通する、プラットフォームの存在
プラットフォーマーとして、一番有名なのはYahooニュースかと思います。
今ではYahooニュース自体もコンテンツを制作しておりますが、基本的にYahooニュースは他媒体が制作した記事をYahooニュース編集部がピックアップして掲載するプラットフォームです。
プラットフォームとメディアの関係が垣間見える、興味深い記事です。
Yahooニュースは20年を超える歴史があるんですね～
プラットフォームはしばらくYahooニュース１強時代だったようですが、今では、
Gunosy、SmartNews、LINEニュース、Antenna、、、などなど増えて来ています。
プラットフォームに記事を転載するメリットとして
トラフィックが稼げる。Yahoo砲とかGunosy砲という言葉を聞いたことがあると思います。
プラットフォームやメディアの力によっては、広告収入をプラットフォームと分け合うケースもあるようです。私は経験無いですが。
また、プラットフォームだけでなく、メディア同士でも記事を転載する場合もあります。
プラットフォームに転載する方法
プラットフォームには「問い合わせページ」が設けられている場合が多いので、そこから申請する形となります。
例えばLINEニュースの場合はこちらのページです。
もちろん、申請して必ず転載が許可されるわけではありません。
それなりに自メディアが育ってなければいけませんが、規模が小さいから無理、というわけでもありません。
オリジナルの有用な記事を書いていて、ユーザからの反応が良いことの方が重要かと感じています。
逆に規模が大きくても、プレスリリースのリライトばかりの内容の薄いメディアだと転載は難しいかなと感じています。
プラットフォームに記事を転載する際の技術的な話
方法は大きく2種類あります。
- LINEニュースなど人による編集がメインの媒体に転載する場合は、特別な仕組みは不要なことが多い。
- SmartNewsやAntennaなどマシンによるレコメンドを行うような媒体に転載する場合は、転載用のRSSの開発が必要なことが多い。
例えば、SmartNewsのRSSの仕様はこちらに公開されています。
SmartFormat 仕様書 - SmartNews媒体運営者向けサポート
プラットフォームに転載する際の注意点
- 当たり前ですが、自メディアの記事広告、ネイティブアドは転載できない。
- 複雑なレイアウトの記事は転載するときに崩れやすいので、記事のフォーマットはシンプルに。最近はAMPもありますしね。
- 権利関係はクリアにしておく。転載のたびにライターに許可を取るのは面倒なので、著作権は買っておいた方が楽。
ちなみに、こんな偉そうに語っておきながら、私自身はまだYahoo砲、Gunosy砲を受けたことはありません。。。
記事の単価について
記事に掛けられるコストが紙に比べてWebが低いというのは紛れもない事実だと思います。
極端な例ですが、CrowdWorksやLancersといった、クラウドソーシングに上がっているライティングの仕事を見ると１記事の単価が200円！という価格帯の案件が乱立しています。
ただ、この話がちょっと先走ってると感じることがあります。
確かにSEOを考えると記事の本数というのは重要で、安い単価のコンテンツを使ってSEOを高めることも可能です。
しかし質の悪いコンテンツが多いサイトは、プラットフォームや別媒体の転載は困難になり、媒体のプレゼンスを上げることが出来なくなります。
反面教師としてDeNAのキュレーションメディアの問題を考えると理解しやすいかと思います。
安かろうはスケールしませし、良いものを作っていればスケールする、というわけでもありません。
まーこの辺のバランスを取るのが編集の腕の見せ所だと思うので、私が語るのはこの辺にしておきますが、プラットフォームの話は経営にコストを説明するときに使えますよ！
SNSの存在
FacebookやTwitterといったSNSは、集客の方法としてメディアとは切り離せないのは自明かと思います。
他にもInstagram、はてぶ、LINEなどありますので、それは自メディアのターゲットに合わせて運用したら良いと思います。SNSもたくさんあるので全部しっかり運用するのは大変です。
「若者向けなので、Instagram、Twitterの運用を厚めにしよう」とか「写真は重用ではなく、テキストが重要なメディアなのでInstagramは捨てよう」みたいな感じで絞るのはアリかと思います。
また、メディア自体の広告として、Facebook広告、Twitterの広告は役に立ちます。
メディアはターゲット（ペルソナ）を想定し、コンテンツを制作するものだと思います。そしてSNSの仕組みは、ユーザがどんなサイトをフォローしているか、誰と誰が繋がっているのか（興味関心が近い人同志が繋がっている）を把握しています。
ユーザの興味、関心に対して広告を出稿できるわけなのでメディアの広告としてSNSは相性がいいわけですね。
ソーシャルについてはFacebookだけでたくさん記事を書けそうなので、このぐらいの言及に留めておきますが、役に立つ記事をピックアップしておきます。
個人的にはFacebookページのいいね！（記事のいいね！ではない）とTwitterのフォロワーを増やすのが、SNSの最重要KPIだと思っていますが、それについては今度記事を書いてみたいと思います。
フロー型のコンテンツ、ストック型のコンテンツ
この記事を読めばフロー型のコンテンツ、ストック型のコンテンツを理解できると思います。
ちなみにこの記事の著者の田端新太郎さんの本はメディアビジネスに関わる人の教科書的な存在なので、読んでみることをお勧めします。
MEDIA MAKERS―社会が動く「影響力」の正体 宣伝会議
- 作者: 田端信太郎
- 出版社/メーカー: 宣伝会議
- 発売日: 2012/12/19
- メディア: Kindle版
- 購入: 1人 クリック: 7回
- この商品を含むブログ (7件) を見る
出版におけるフローとストック
出版に置き換えると、新聞は日付が変わると新しい新聞が発行されますし、雑誌の場合は週や月が変わると新しい雑誌が出るので、新聞や雑誌はフロー型のコンテンツです。
一方で本屋に行けば「村上春樹」の小説はだいたい置いてますから、名著と呼ばれる書物はストック型です。
Webメディアにおけるフローとストック
Webの場合、Yahooニュースみたいなニュース系・時事ネタなどはフロー型、Wikipediaのような辞典やTipsなどのネタはストック型に分類できます。
Webの場合は出版と違って本屋の場所を押さえる必要がないので、出版よりはストック型と相性が良いと思いますが、ここで抑えておきたいのはコンテンツの種類による流入経路とアクセスの伸び方の違いです。
フロー型、ストック型の流入経路とアクセスの伸びの違い
ストック型のコンテンツの集客方法としてはSEOが重要です。 何かを知りたい、調べたいという場合は検索することが多いからです。 ただし、SEOというのは良いコンテンツを書いていても緩やかに伸びていきますし、みんなが一斉に同じトピックを調べるわけではないので爆発力はありません。 その代わり、長い間役に立つコンテンツであれば、長い間アクセスを稼げます。まさにストックです。
一方でフロー型のコンテンツの場合は、既に読者がついている即時性や更新性の高いメディアが有利でストック型よりはSNSでシェアされやすく、爆発力があります。 時事ネタについて、深い考察のある記事なんかは私もTwitterで良く目にします。Twitter自体がフロー型のメディアというのもありますね。
ただし、フロー型のコンテンツは旬を過ぎるとアクセスはあまり稼げなくなります。
ちなみに当ブログはストック型のコンテンツを中心にしますが、この記事のタイトルはSEOに向いていません。。。
ぜひシェアをオナシャス！
広告について
Webメディアってページの制限が無いのですが、広告枠がある程度決まっている、純広告も当然あります。
すごい量のWebメディアの媒体資料を調べた記事です。骨の折れる作業だったろーなと想像できます。
ただ、純広告を出せるようになるにはある程度のPV・UUが必要になってきます。まーこれは出版も部数が必要ですから一緒ですよね。
出版とWebメディアの広告で大きく違うのは、
- 広告主が媒体を選ばなくても広告を出稿出来る→アドネットワーク
- 課金体系の種類がいろいろある。掲載課金、Imp課金、クリック課金、成果報酬。
このあたりかと思います。
アドネットワークの存在
アドネットワークの説明はこの記事がわかりやすいかと。
Google AdSenseとYahoo! ディスプレイアドネットワーク（YDN）がアドネットワークの2台巨頭かと思いますが、その他にも多数のアドネットワークがあります。
広告主にとっては、無数にある媒体をいちいち選んで出稿する手間がなく、媒体側にとっては広告営業を設ける必要が無いというメリットがありますが、媒体側にとってはやはり単価の低さが気になると思います。
さまざまな課金体系
純広告の場合は基本的には掲載課金型ですが、Imp保障をしているケースもあります。
その他にもクリック課金やImp課金、成功報酬という形があります。
成功報酬といえばアフィリエイトですね。
アフィリエイトの仕組み｜アフィリエイト初めてのかたへ｜アフィリエイトのアクセストレード
この記事はアフィリエイトの仕組みの説明です。 Webってユーザが最終的に商品を購入したのかトラッキング出来るので、こうして成功報酬という仕組みが成り立つんですね。
アフィリエイトって個人ブログやアフィリエイターが作ったアフィリエイトサイトのイメージが強いと思いますが、今後は大手Webメディアでもアフィリエイトの広告が増えていくんじゃないかと個人的には思っています。
ちょっと話はズレますが、ZOZOTOWNは基本的に在庫を持たない、消化仕入れが基本の通販サイトです。売れたときに仕入れと売上が同時に立ちますからある意味成功報酬で、CVポイントに近いアフィリエイトサイトだと言う人もいます。そしてZOZOTOWNをチェックするのも、ファッション雑誌をチェックするのも、ユーザ心理としてはそんなに変わらないケースがあると思います。ファッション括りだとIQONというコーディネートアプリもあります。
つまり競合はWebメディアだけじゃないということを頭に入れておくといいかもしれません。
広告制作部をもっているWebメディアの方がレア
特に雑誌の場合、広告営業と広告制作部、編集部と役割が分かれていることがあるかと思いますが、Webの場合は一緒のケースが多いです。
元々ITの我々からすると、
「仕事選んでんじゃねーよ」
となるので、理解を期待しない方が良いです。
これは文化だと思って割り切ってください。
校正が雑なわけじゃない、文化が違う
出版と違い、Webメディアは24h365、コンテンツを公開できます。即時性の強いメディアです。とことんフロー型に寄せられます。
なのでLINEニュースは3交代制の24時間体制を敷いていると聞きます。
新鮮な情報があるということは、それだけでメリットです。校正に時間を掛けられません。
今では新聞よりNewsPicksが制作した記事の方が新鮮だと感じることがありますし、新聞と違ってページの制約が無いので、インタビュー記事なんかは新聞より面白いと感じます。
一方で出版は日刊紙、週刊誌、月刊誌という形で区切りがあり、印刷すると後で修正が効きません。 なので校正はWebより厳しくやっていると思います。
これはもう文化の違いです。 出版出身の人がWebメディアの記事は校正が雑だ！みたいな話をすることがありますが、文化が違うんです。
また、先に述べた通りコンテンツは流通します。
自メディアのトンマナを一生懸命揃えたとしても、その記事を見ているプラットフォームが違う場合があります。
また、見ているコンテンツのカテゴリが読者によって偏っているという場合もあります。 雑誌だったらお金を出して読みますので、貧乏性の私なんかは購入した雑誌のほとんどのページをくまなく見ちゃいますが、Webの場合は自分の好きなカテゴリの記事だけ見る、というケースが多いわけです。
こういう特性を踏まえた上で、校正をどこまでコストを掛けて行うのか、考えるべきです。
あと、私の記事の校正が甘いのは多めに見てくださいね(´▽｀)
今後さらに、紙からWebに移る編集は増えていく
この記事は約30年に渡る広告費の推移をグラフ化した、とてもわかりやすい記事です。
新聞・雑誌の広告費はこの30年で大きく下がっており、逆にインターネットの広告費は大きく伸びています。
テレビが今でも1位であることは変わりませんが、この先10年でインターネットがテレビに追いつきそうな勢いです。
これはもう、インターネットにシフトする編集さんが増えるのは火を見るよりも明らかです。
編集長はひっぱりだこ
これは出版の場合もそうだと思いますが、Webは媒体が多数あり、しかもどんどん増えていっています。
出版業界より編集長が足りまへん！
媒体の方向性、マネタイズを考え、編集やライター陣をまとめ、広告主と良い関係を築く編集長はそりゃーもうひっぱりだこです。
確かに出版よりWebメディアの収入は低いかもしれませんが、チャンスは多いかなと感じています。
誰とWebメディアを作るのか
編集長が新しい媒体を作る時、恐らく私のようなWebプロデューサーと組むことになるでしょう。
私は編集長がどちらかというと苦手な予算編成からシステム開発、マーケティングまわりを担当します。
その他にもエンジニアやマーケッターといった、出版ではあまり絡まない人と仕事をする機会が増えると思います。
Webプロデューサーはターゲット、マネタイズ、方向性は編集長と一緒に考えますが、私の場合は基本的にコンテンツの内容については、あまり口出ししないようにしています。
編集権の独立は尊重します！
ただし残念ながら、編集のWebの知識が不足していて意見が別れることが多数あります。
経営がWebメディアを理解していなくて意見が割れることもありますね。
もちろん歩み寄る努力をすべきですが、もう少しWebを理解して欲しいなー、と思うわけですね。
意見が割れたとき、この記事が役に立つといいんですけど。
*1:リンクを貼る時にnofollowを指定すると、検索エンジンに対して「リンク先を評価しない」という指示になり、SEO効果がありません。
システムの発注者がシステム開発は素人、はもう通用しない。ブラック顧客は淘汰される時代になっている。
この記事を書いた社長に感動しています。
米村さんよくぞ言ってくれました！
アクシア社の米村社長とはお会いしたことはありませんが、アクシア社は「残業ゼロのIT企業」というフレーズとともに、SNSやメディアで拝見しておりました。
請負開発の仕事をしているとブラックな発注者に当たってしまうことは珍しくありません。 先の記事はそれを本当にわかりやすく分類していますね。
私自身も請負開発をトータルで7年、請負開発のプロジェクトマネージャーも5年ほど経験していますので、この記事の事例を経験しています。
請負開発の仕事をしていると仕事のほとんどが顧客のシステム開発になり、顧客の秘密をたくさん知っているわけですから、仕事の話はあまり発信出来ないかと思います。
そして「お客様が悪い」とはなかなか言えません。
「お客様が悪い」と定義してしまうと、こちらの努力も進まなくなる弊害もありますし、「お客様が悪い」と発信してしまうと、顧客の新規開拓にも大きな影響があるはずです。
そして「お客様が悪い」と言えるのは社長以外に無理だと思います。
プロジェクトマネージャはプロジェクトの収支に責任はありますが、会社全体の利益にまで責任を負えません。だから社長しか言えないんです。
米村さんは全てわかった上での、あの記事なんだと思います。
なかなかの勇気ですよね。惚れるわー！
実は顧客を開拓するより、エンジニアを採用する方が難しい
「お客様が悪い」と言える背景に顧客とベンダー側のここ何年かのパワーバランスの変化もあると思います。
ある程度の実績がある会社だと理解して頂けると思うのですが、コアとなるソリューションが育っている会社の場合、顧客を獲得するよりエンジニアを採用する方が難しいです。
「新規の案件の受注は控えております」と言った会社は少なくないはずです。
私も信頼しているベンダーさんが、リソース不足でなかなかプロジェクトの座組が出来ない、希望通りのスケジュールとならない経験は1度や2度じゃないです。
これはエンジニアの採用が簡単でしたら、すぐ解決する話かと思いますがそれが一番難しいんです。
これはDODA調べの転職求人倍率で、DODA内のデータのようですが、IT業界の転職求人倍率が突出して高いと思います。 恐らく採用コストも比例して上がっているはずですし、社員じゃなくても外部の人、派遣や特定派遣の会社を利用してリソースを確保しようとしても、やっぱり単価は上がってきています。
このような市況なら、
「顧客に媚を売ってエンジニアに無理をさせて離職率を上げてしまい、無駄に採用コストや教育コストを上げてしまうよりは、エンジニアを大事にしよう」
となるのは自然というか合理的な判断です。
発注側は現在の状況を踏まえ、合理的な付き合いをすべきです。
今だから言えますが、私も仕事を受けたくない理不尽な既存顧客の案件に対して、かなり吹っかけて、あえて失注した経験があります。
「新規の仕事を断る状況で、おまえの仕事はいらない」
そもそも請負開発のビジネスモデルって何なのか？
私は請負開発のビジネスモデルは「保守のストックビジネス」だと考えています。
ストックビジネスとは継続的に売上があがるビジネスを指します。
例えば保険の販売はストックビジネスです。
一度保険商品を売ると、解約しない限りは毎月決まった保険料が入ります。 この場合、販売努力は１回です。
ストックビジネスの反対はフロービジネスといい、例えば飲食店はフロービジネスです。
飲食店で例えばラーメン定食を１度提供したとして、また定期的にお客さんが来てくれるかは保証できませんし、もう一度ラーメン定食を提供する場合はまたラーメン定食を作らなければいけません。
これを請負開発に置き換えると
新規取引先の新規プロジェクトはフロービジネス。 初回の営業活動は大変な作業で、新規開発プロジェクトはリスクが大きい。後述します。
既存取引先の保守契約、保守案件はストックビジネス。 営業活動も不要で保守契約以外にも、ソフトウェアライセンスのフィーがあるかもしれないし、ハードウェア、ミドルウェアの販売代理店の場合はそこからのフィーもあるかもしれない。そして保守案件はリスクが小さい。
そもそも新規の取引先と新規のプロジェクトはリスクが大きいです。
大きい案件の場合は間違いなくコンペでしょうし、ソリューションや実績に自信があっても競合がいるわけですから、競合を意識した価格にどうしてもなってしまいます。
その中で大量の人をアサインし、数カ月プロジェクトを進める場合、1カ月納期がずれただけでも多くの人件費がかかりますから、収支的にはトントンでも十分だと思っています。 プロジェクトのリスクは要件定義でかなり減らせるとは思いますが、どれだけプロジェクトの数をこなしても、たくさんの問題が発生するものです。
完璧な絵が描けているプロジェクトを、私はまだ知らない。
一方で保守案件は基本的に既存システムの改善・拡張ですから
- 技術的リスクが小さい
- コミュケーションコスト・リスクが小さい
- 教育コストも小さい
- 納期が新規ほどきつくない。大量に人をアサインする必要も少ないわけで、やっぱりコミュニケーションロスも少ない。→後述するブルックスの法則で説明します。
他にもあると思いますが、リスクが小さいわけです。
だから確実に黒を出せます。
出せなかったらプロジェクトマネージャじゃないですよね。
私の昔の上司の話ですが、彼は大手の事業会社から来た、技術力とかは皆無の部長さんだったわけなんですけど、
「おまえ保守で儲けていれば良いと思うなよ！」
私にこんなアドバイスを送ったことがありました。 それは私の新規案件のプロジェクトの利益率が悪かったために出た言葉だと思いますが、決して赤は出していません。
また、新規案件の価格はどちらかと言うと営業マターが多いわけで、こちらとしては厳しいプロジェクトをいくつも納品し、保守費を積み上げて、毎月安定的なキャッシュを会社に献上しているわけなので、「は？」という受け止め方になります。
今だから言えますが、私がその会社を転職した理由のひとつに請負開発を理解していない、その部長の存在があります。 技術的なリスクをたくさん抱えるか、またはエンジニアにたくさん無理をさせてでも、理想的な利益率を出そうとは到底思えません。 だって保守案件で安定的に儲けようとしていますからね。
なんか、「昔の恨みつらみ」みたいな文章になってしまいましたが、発注者側も請負開発のビジネスモデルを理解していると、ベンダーさんをうまく使えるんじゃないかとも思います。
発注側こそ理解すべき、ブルックスの法則
ブルックスの法則は聞いたことが無いとしても、プロジェクトの人数が多ければ多いほど、ひとり頭のパフォーマンスが下がるのは感覚的に分かると思います。
主な理由としては、
- 人が増えるほどコミュニケーションコストが増大する
- タスクはそんなに分解出来ない。1画面3人日で終わる仕事を、1日で終わらせるために3人のエンジニアを投入しても1日では終わらない。
つまり、
納期がきつい→たくさんの人員が必要→ひとり頭のパフォーマンスが下がる→納期がきつい場合は特急料金が必要
と言えるわけですが、これをちゃんと理解している発注者の方が少ないかと思います。
逆に日ごろQCD（Quality、Cost、Delivery）*1に接しているプロジェクトマネージャはこの現実を理解すべきです。発注者に理解させなければいけなんです。むしろ腕の見せ所です。
じゃ発注者はどうしたら良いのか？
発注者の基本的な立ち位置は「プロデューサー」だと思っています。
プロデューサーといえば、TVのプロデューサーを思い浮かべる人も多いかと思います。
私はTV業界について詳しくはないですが、TVのプロデューサーになるためには恐らく、AD（アシスタントディレクター）、ディレクターという職種を経験しているかと思います。 最初はお弁当の手配などの下積みから始まり、番組制作に関わる多くの部分をディレクションし、最終的にプロデューサーという責任者になるわけです。
つまり彼らTVプロデューサーは制作を知っています。だからいろんなジャンルのスタッフをまとめ、演者さんには気持ちよく仕事をしてもらい、広告主に対しては視聴率について責任を持つことが出来ると思います。もちろん会社には利益で貢献していると思います。
同じ論理で言うと、システムの発注側も制作について知るべきです。
制作を知らないのに多額なシステム投資に責任が持てますか？
TVプロデューサーが、企画が悪い、演者が悪い、ディレクターが悪い、制作会社が悪い、そんな風に人のせいにして成立するとは思えません。
残念なことにITについては、それが結構まかり通っていると思います。
まずIT企業自体がそうです。
10年以上前の古い記事ですが、IT企業がIT企業に発注している例です。10年前とはいえ、日本でNo.1のSierの事件です。
IT企業の社員なのにITは素人でITを発注しているわけです。 これは事件になって明るみに出ていますが、ここまでひどくないにしろ、私も含め、似たようなケース経験している人は多いと思います。
そして、このBlogのタイトルはWebプロデューサーのノートです。
請負開発の仕事をしていた私も今はプロデューサー、発注する立場でもあります。
実際はベンダーに発注するだけでなく、自分でコードも書きますし、エンジニアを抱えてディレクションもしますし、やっぱり根っこは一制作者だと思っています。
誰も私のことを「Webプロデューサー」とは呼んでくれませんが、このBlogではその部分について深堀出来たらなと思っています。
おまけ
ちなみに先のアクシア社も、
この記事を見ると、客先常駐をやめることによって
- 採用力が高まった
- 従業員の質が上がった
とありますし、
既存顧客からのリピート受注と保守で占める割合は９割で、新規顧客からの受注は１割
のようです。利益は安定的にあげられそうですね。
あのブログで吠えることにより、採用力を上げて→優秀な人材を確保→顧客に良いサービスを提供→リピート率を上げる→安定した利益なんだと理解しました。感情的というより、むしろ合理的です。
請負開発者はもっと合理的に吠えた方がいいですね！
*1:QCDとはQuality（品質）、Cost（費用）、Delivery（納期）の略で、それぞれに相関関係があります。例えば品質を上げれば費用がかかり納期も延びます。納期を短くしたら費用がかかり、教育を怠れば品質が下がるかもしれません。このバランスを保つことはプロジェクトマネージャの大事な仕事です。
コミュニケーションコストを下げる、技術・方法論についてのまとめ
私は転職が多いのと、ひとつの会社でもたくさんのプロジェクトに関わることが多かったので、様々な人と様々な現場で仕事をしてきました。
で、やっぱりあるわけですよ、無駄な会議や効率の悪いメールが！
前の記事でも書いたのですが、
コミュニケーションはコスト
会議も成果物が必要
だと考えています。
私は人一倍人見知りで合理主義なのでやっぱりコミュニケーションコストが気になります。 今回はコミュニケーションコストを下げ、成果物を効率的にアウトプットするための技術、方法論についてまとめてみようと思います。
ロジカルシンキング：建設的で論理的な議論の入り口
頭のいい人って教えられなくても、たぶんこれ出来ていると思います。
私が初めて「ロジカルシンキング」という考え方に出会ったのは、その当時在籍していた会社が行かせてくれた、セミナーだったと思います。 たしかトーマツのセミナーだったかな。
そう、私が学んだのはコンサル由来の「ロジカルシンキング」です。
Wikipediaを見るとそれ以外の意味もあるらしいのですが、ここではコンサル由来の「ロジカルシンキング」に限定します。 そしてロジカルシンキングについて詳しく語るのは有用な本にお任せして、「ロジカルシンキング」の触りだけ紹介します。
演繹法（えんえきほう）：「AだからXである」
これは結論を導き出すための方法論です。議論が収束しないときに、いろんな条件、前提をもって結論を導きだします。 議論が収束しないということは、実際はこんなにシンプルではなくて、事象が複雑な場合が多いので、実際使うときは「Aもあるし、Bという状況もあるし、Cが足りないし、だからXにしよう」という言い方になるかもしれません。
「こんなの当たり前じゃないか！」と思われる方は恐らく最初から演繹法が身についています。説明責任をしっかり果たす人は好きです。
しかし、議論において自分の主観だけを語り、要因の説明が乏しい人も残念ながら存在します。 どちらかと言うと、このテクニックは議論にならない人を説得する場合に使えるかもしれません。
「Xという結論にもっていきたいので、A、B、Cという材料で肉付けする」
こちらがXという結論を出すためにA,B,Cとい要因を説明しているわけですから、相手も自分の希望を通すためには説明責任が発生します。
三段論法に近いというか、ほぼ三段論法ですね。
三段論法のプロと言えば弁護士さんです。
弁護士の裁判もクライアントの希望ありきで戦うわけですからね。
ロジカルシンキングはそのほかにも帰納法、ロジックツリー、MECEなどなどの方法論があります。
ぜひ書籍を読んでみることをお勧めします。
クリティカルシンキング：目的に立ち返る
ロジカルな人が集まれば議論が収束するかというと、そう簡単にいかないこと多いですよね。 むしろ頭がいい分、いろんな粗が見えてしまって、批判だらけになってしまうケースは多いと思います。
「クリティカルシンキング」は「ロジカルシンキング」を前提としていて、考え方が近い部分も多いんですが、大きな違いとしてクリティカルシンキングは「目的に立ち返る、その目的を達成するための課題を設定する」ための考え方になります。
「そもそも達成したいのは〇〇ですよね、△△の課題の方が重要で■■のご指摘は大きな問題ではないのでは？」
細かい粗探しに終始するようなケースで、こんな風に言えれば議論が収束すると思います。
クリティカルシンキングもビジネスマンには覚えて欲しい重要な技術だと思います。
ぜひ書籍を読んでみることをお勧めします。
ファシリテーション
「ロジカルシンキング」や「クリティカルシンキング」は考え方の技術だとすれば「ファシリテーション」は会議の技術そのものです。
ファシリテーションでは「ファシリテーター」という会議の段取りを行う人を設定します。 この段取りが非常に重要で、会議が始まる前の準備からファシリテーションは定義しています。
会議の前の段取り
- 会議の議題・目的を設定する。→クリティカルシンキングが生きてきます！
- 議題を議論するのに必要な情報を集める。→ロジカルシンキングの演繹法そのものですね！
- 会議のタイムテーブルを決める。→時間内に結論を出すようになります。
- 会議の参加者を設定する。→発言する必要のない人は参加する必要がありません。
この段取りがしっかり出来ていれば議論は発散しにくくなります。 もちろんファシリテーションは会議中のことも定義していますが、それは有用な本にお任せします。
あなたがもしチームのリーダーであればこの「ファシリテーション」の技術は非常に役に立つはずです。
ぜひ書籍を読んでみることをお勧めします。
最後に
ここまでコミュニケーションを下げる技術を取り上げましたが、一番下げる方法があります！ それはコミュニケーションを取らない、合意形成さえ取らないという方法です。
“許可を求めるな、謝罪せよ”
許可というか合意を取る作業というのは結構大変です。 しかも私が属しているIT業界の仕事というのは複雑で巨大なものも多いわけで、全ての作業について合意を取るのはそもそも無理があると思います。
何かあったときにお客さんに多大な迷惑がかかるようなことは合意を取るべきですが、目的から外れていなければ、作っちゃって問題があったら謝る、というスタンスは全然アリです。 これはコミュニケーションの技術というより、実行力の方が重要になりますが、実行力のある方ならきっと上司の信頼も得ているでしょう。
コミュニケーションコストを下げて、どんどん作っちゃいましょう！
紙からWebのデザインを始めるデザイナーさんに知っておいて欲しいこと
今までたくさんのWebデザイナーさんと一緒に仕事をしてきましたが、中には紙のデザインしか経験が無い・Webデザインの経験が薄い方もいました。 その経験をもとに、ノンデザイナーの私が偉そうに書いてみますね！
- Webは紙と違い、デバイスが複数あることを認識する
- Webはクリックされて始めて見られる
- コーダーの仕事、HTML・CSSを理解する
- Webは更新できる
- 広告のサイズを頭に入れておく
- 納品物がいろいろある
- 見る・読むのは人間だけではない
- Webはすぐ参考にできる、マネできる
- Webは計測できる！
- Web業界、IT業界のコミュニケーションを理解する
- 最後に
Webは紙と違い、デバイスが複数あることを認識する
WebはPC、スマートフォン、タブレットという形で複数のデバイスで表示することが前提です。 なので紙で言う台割にあたるワイヤーフレームもPC、スマートフォンで2種類作るケースが多いわけです。 これはたぶん頭ではわかっているとは思いますが、実際にどんなところに影響してくるかというと、
- 各デバイスのデザインで画像の縦横比はなるべく揃える
これをやっておかないと、画像の加工の手間が半端なく増えます。 もちろんクリエイティブに拘るサイトは手間をかても良いと思いますが、 どんどんコンテンツを増やしていくようなサイトだと運用の手間も増えてしまいます。
- 今の時代の主流はスマホ、「スマホファースト」
BtoBのサイトは除外しますが、スマートフォンの流入の方が多いサイトが主流となっています。 Googleの検索数も2015年にはスマートフォンがPCを上回っています。
Yahoo Japanは「スマホファースト」を数年前にうたい、今では業界の常識となっています。 でも我々は普段PCで仕事をしますから、この常識を忘れてしまうことが多々あります。 実際、PCのワイヤーフレームから書き始めてそれをスマートフォンにした際に、要素が多くなりすぎて入りきらない、ゴミゴミしてしまうことがまだ見受けられますよね。
Webはクリックされて始めて見られる
書店に置いてある雑誌はお客さんが手に取って見てくれますし、電車の中吊り広告もたくさんの通勤者に見てもらえますし、会社案内のパンフレットは営業が配ってくれます。
ただしWebの場合は
Googleの検索をクリックする。
Facebook、Twitterのシェアをクリックする。
広告文、バナーをクリックする。
だいたいこのクリックを経由して始めてサイトが見られるわけです。
また紙であれば、その紙媒体を買った人はページをめくってくれることを期待できますが、サイトに来た人にいろんなページを見てもらうには、やはりクリックしてもらわなければいけません。
何が言いたいかというと、クリエイティブのこだわりがこのクリックと喧嘩しちゃダメってことです。 「格好良い！」けど「わかりにくい」ナビゲーションやUIを作ってしまうとクリックを促がせない、サイトを回遊させられません。
コーダーの仕事、HTML・CSSを理解する
まさかIllustratorでデザインを渡しているデザイナーはいませんよね！？ まさかレイヤーがぐちゃぐちゃなまま渡してないですよね！？ これはどんな仕事でもそうですが、チームの他メンバーの仕事を理解していないと良い仕事は出来ません。
そしてデザイナーのデザインをWebの形にするのがコーダーです。デザインを構造化してコードにするとも言い換えられます。
これは見出しなのか、小見出しなのか、ナビゲーションなのか、コーダーが一目でわからないデザインはユーザにとっても優しくありませんし。 私がデザイナーさんを探すときにも、これかなり重要視しています。
Webは更新できる
これは本当大きいですよね。 コンテンツの量も無限大に足すことができますし。 更新出来るメリットとして他には、例えば納期がもし厳しい場合、フェーズ１のデザイン、フェーズ２のデザインみたいな形で分割して納品することも可能です。
あとサイトを作ったら終わりではなく、むしろ始まりという考え方なんですよね。 デザインも更新出来る前提が求められます。
広告のサイズを頭に入れておく
サイトによっては広告エリアを設けるサイトがあると思います。また広告を出稿してサイトに集客する場合もあると思います。 どちらの場合でもこの広告のサイズにならってサイトをデザインしておくと運用が楽になります。 広告はたくさんのクリエイティブを作ってパフォーマンスを上げていくものですからね。
あと、この広告のサイズには名前が付いていて「レクタングル」とか「スカイクレイパー」とか言えるようになると、ちょっと格好良くなれます。 ぜひ「おれ、わかってる感」を演出してください。
納品物がいろいろある
どんなものがあるかというと、
サイトのデザインデータはpsd形式で。
ピクトグラムなどはsvg形式で。
PCサイトのfavicon、スマホのアイコン
FacebookやTwitterのアイコン、カバー写真。
などなど。これ、頼んでもないのに納品してくれるデザイナーさんは惚れちゃいます。
見る・読むのは人間だけではない
紙媒体を見るのはほぼ人間ですが、Webの場合はクローラもサイトを見ます。Googleで検索したときに該当するページを結果として返すことが出来るのはこのクローラがサイトを巡回しているからです。
そしてこのクローラと人間の大きな違いは画像に対する認識です。クローラは画像を理解する力がどうしても人間よりも弱いわけです。 SEO対策という言葉を聞いたことがあると思いますが、言い換えるとクローラにサイトを理解しやすくするということです。
例えばファッション雑誌の場合はタイトルと写真だけで成立するものが、Webの場合はクローラが画像の認識が弱いため、説明するための文章が必要になります。
誰かの言葉を借りて私はよく「Webは紙より説明的に」という話をしますが、その理由のひとつにこのクローラの存在があります。 SEO対策的にクリエイティブがNGということもありますので、そのときはディレクターやマーケッターと相談してデザインを作ると良いと思います。 クリエイティブのためにSEOを捨てて良いというサイトはほとんどないですからね。
私もSEOの仕事をしていて、たまに意見が割れることがあるので「デザインとSEO」については深堀したいなーと思うところです。 アンカーリンクのテキストは英語の方が格好良いけど、SEO的には日本語の方が良いことが多いよーとか、h1はなるべく上にもっていきたいよーとか、デザインに絡むことって結構あるんですよね。
Webはすぐ参考にできる、マネできる
もちろん紙でもマネが出来ると思いますが、Webはこのコストがすごく低いです。 競合のチェック、デザインの方向性の詰め、サイトの構成、すぐ参考に出来ます。
「僕らのターゲットはこんな属性だけど、競合がこんなテイストだから、我々はこのテイストでいこうか。」
みたいな伝えるのが難しいことが、PCでいろんなWebサイト見ながら会話が成立します。 これ、当たり前みたいに聞こえるかもしれませんが、デザインのディレクションで出来ている人は意外と少ないです。
Webは計測できる！
Webの良いところとしてWebは計測出来るという大きなメリットがあります。
やはり結果が数字として出てくるのはモチベーションんにつながります。
Webのアクセス解析と言えばGoogle Analyticsがデファクトスタンダードですが、ぜひ基本的な使い方を覚えていただきたいです。
例えばどんなシチュエーションがあるかと言うと、
- 直帰率の高いページがデザインの力で低くなった！
- バナーのCTRが倍になって広告の流入が増えた！
これ、感動しますよ！「より多くのターゲットの心が掴めた」ってことですから。
Web業界、IT業界のコミュニケーションを理解する
それなりの規模のサイトを作るとなると、スキルの異なるメンバー間でコミュニケーションが多数発生します。そしてこのコミュニケーションはコストという考え方をします。
コミュニケーションコストについては当記事でも書いています。
そのコストをなるべく減らすためにBacklogやRedmineなどのタスク管理ツールや、チャットワークやSlackなどのチャットツールが存在し、チームの中でルールを決めてそのツールを使います。 それも効率的に良い成果物をアウトプットするためです
会議の考え方も異なります。会議も成果物をOutputする場として考え、無意味な定例会議みたいなものを嫌います。 意思決定、成果物の定義、設計のFixなどなど、これらは非常に大事な成果物です。 そのせいか、他の業界と比べてIT業界は会議の技術であるファシリテーションやロジカルシンキングを理解している人が多いと思います。
あと心に留めた方がよいことは、
会議中の内職、チャットが結構許される。
電話嫌いが多い。
メールの件名がわかりにくい、メールが検索しにくい人はキレられる。
「さん」付けが結構許される。お客様に対しても。
こんなところでしょうか。礼儀よりも合理性を重視する文化だと思えば理解しやすいと思います。
最後に
ここまで読んでて、もしかしたら「Webは表現の制約が多いなー」とか「ルールが多くて覚えるのが面倒だなー」と感じたかもしれません。
ただ一方でインターネットがなぜここまで普及したかというと、情報を流通するコストがすごく低い、伝えやすいわけでです。
デザインも人に見られてナンボです。 ぜひこの制約を武器に変えていただけたらと思います。
あとこの文章を書いていて思ったのは、これはデザインをレビューしてもらう際にレビュアーにも知っておいて欲しいことだなと思いました。レビューアーは経営陣だったり、営業さんだったりWebを知らない人も多いですからね。
編集さん向けにも書きました！
