疲労がヤバイです
PCしてる体を支えられない
休憩しながらコーディングできないてますかね？
頭も働かないんですが
受託新規開発と、内製継続開発の体制の差
観測数が少ないんですが、私の見た限りこういうのが多かった。というものと、その課題について。少し考えたこと。
受託・新規開発
だいたいこんなだと思います。
受託・新規開発で社会人デビューしたので、こちらが一般的だと信じ込んでいました。
PM、あるいはPMとディレクターがPO（プロダクトオーナー、つまりお客さん）との間に入って調整してくれます。
内製・継続開発
内製・継続開発的な会社に入った時、下図のような感じで割りと面食らいました。
案件はチケット単位で走ります。1チケットは軽いものだと1日で、重いものだと2ヶ月くらいです。
重くても新規開発の1プロジェクトの大きさには満たないので、エンジニアが割りと全面に出ることを求められます。
結果的に「エンジニア＝ディレクター＋PG」的な動きとなります。
PO側も非常に奇妙に感じました。お客さんに相当する人は部門であることが多いです。例えばQA、企画、広報、法務部など。いろんなところからいろんな要望が出て、それに対応するのがメイン業務となります（6割位？）
もちろんサービス自体の改善もあります。それが残りの業務です。
この体制の問題点
図を見ればわかると思いますが、情報の導線がカオスです。
これがどういう問題の顕在化に繋がるかというと。
- 全体を把握しづらい、戦略的に動きづらい
- 一貫した方針でプロダクトを作りづらくなる
- 質の担保がエンジニアの感覚値になる
- 無限に仕事が発生する
- 無限に複雑度が上がる
- エンジニア負担が大きい
- ディレクションまでできるエンジニアが必要
- 誰の認識している仕様が正しいのか迷子に成りがち
もっとある気がしますが、こんな感じでしょうか。
「よくわからない」状態になります。
もっと良い体制はないものか？
プログラムの設計に似ています。
誰に何を担わせるのか、どことどこを分けるのか。
まだ考え中ですが、こんな体制だとどうでしょう。
結局一般的なスクラム体制なんですが。やはりPMとSMをどう設計するか次第で良し悪しが決まりそうです。
正直物量を考えると、この中間層が2人でいいか自体疑問です。
3、4人はほしくないですか？
数値を計測する人、情報の流れを管理する人も欲しいです。
またそのうち書きます。
サービスアイディア思いついちゃった時どうすればいいか
まるで時間もないし金もないんですが
思いついてしまった時は苦しいですね
しかも実現可能性が高かったりすると
まあ大抵どこかでコケるんでしょうけど（その時点でサービスが存在していない時点で何かしら見えていない罠があるはず）
裁量労働制って結局何なの？ 時間で給料を払うのは悪なのか？
裁量労働制について、多くの人の意見を見てきましたが、どうにもまだ混乱が多い気がします。かと言って自分が正しく認識しているかと言えば、少しふわっとしている部分もあると思うのでちょっとまとめてみたいと思います。
そう言えば「時間で価値を測る」という点にはIT業界においても批判が多いです。いわゆる「人月」というやつです。「人月商売」で検索するといっぱいでてきます。
いろんな視点がありますね。
ITエンジニアの価値を貶める『人月商売』の功罪 - paiza開発日誌
人月商売はもうやめた方がよいと思う４つの理由 - 株式会社アクシア
ござ先輩はまた違う支店で語っています
人月商売が悪だと思っている、イノセントなあなたへ - GoTheDistance
会社間の見積もりと、個人のお給料は必ずしも同じとは言えませんが、どちらも時間で値段をつけています。要は時間給です。
その時間給を辞める理由とは何なのでしょうか？
時間と労働が比例する状態
こんな仕事があるとします。
例えば１時間に１個商品を製造できる職業はこれでしょう。
これは時間給であることに異論はないはずです。
「いや、自分の仕事は頑張れば単位時間あたりの成果を上げられる！！」
「能率の低いやつが居る！！」
と主張される方がたまに居ますが、それなら報酬を変えればいいだけですよね？
賞与という調整弁
「その時々で成果は変わる！」とか
「必ずしも時間に比例した成果は出ない！」という意見もあると思います。
そのために多くの会社はボーナスというものを用意しています。
「おおよそ時間に比例する」程度ならまったく問題ありません。
裁量労働制はどういう状況か？
Wikipediaにこうあります。
労働時間と成果・業績が必ずしも連動しない職種において適用される
労働時間と成果が連動しない。つまり上図のような状況ではありません。
当事者の能力の大小にも関係ないはずです。
連動しない、ということはつまりこんな感じです。
成果が出るまで長い時間がかかったり、下手したら成果が出なかったり、成果が出ると早かったりするタイプですね。
確かに現在既に対象となっている職業を見ると、時間に対するブレが大きそうです。
- 新商品若しくは新技術の研究開発又は人文科学若しくは自然科学に関する研究の業務
- 情報処理システム（電子計算機を使用して行う情報処理を目的として複数の要素が組み合わされた体系であつてプログラムの設計の基本となるものをいう。(7)において同じ。）の分析又は設計の業務
- 新聞若しくは出版の事業における記事の取材若しくは編集の業務又は放送法（昭和25年法律第132号）第2条第4号に規定する放送番組若しくは有線ラジオ放送業務の運用の規正に関する法律（昭和26年法律第135号）第2条に規定する有線ラジオ放送若しくは有線テレビジョン放送法（昭和47年法律第114号）第2条第1項に規定する有線テレビジョン放送の放送番組（以下「放送番組」と総称する。）の制作のための取材若しくは編集の業務
- 衣服、室内装飾、工業製品、広告等の新たなデザインの考案の業務
- 放送番組、映画等の制作の事業におけるプロデューサー又はディレクターの業務
- 広告、宣伝等における商品等の内容、特長等に係る文章の案の考案の業務（いわゆるコピーライターの業務）
- 事業運営において情報処理システムを活用するための問題点の把握又はそれを活用するための方法に関する考案若しくは助言の業務（いわゆるシステムコンサルタントの業務）
- 建築物内における照明器具、家具等の配置に関する考案、表現又は助言の業務（いわゆるインテリアコーディネーターの業務）
- ゲーム用ソフトウェアの創作の業務
- 有価証券市場における相場等の動向又は有価証券の価値等の分析、評価又はこれに基づく投資に関する助言の業務（いわゆる証券アナリストの業務）
- 金融工学等の知識を用いて行う金融商品の開発の業務
- 学校教育法（昭和22年法律第26号）に規定する大学における教授研究の業務（主として研究に従事するものに限る。）
- 公認会計士の業務
- 弁護士の業務
- 建築士（一級建築士、二級建築士及び木造建築士）の業務
- 不動産鑑定士の業務
- 弁理士の業務
- 税理士の業務
- 中小企業診断士の業務[1]
本当に時間に依らない？？
しかしこの話は罠です。
ほとんどの仕事には繰り返しがあります。
クリエイティブな仕事も、士業も、だいたい繰り返しです。
多くやってると収束していきます。
するとこういうグラフになります。
いわゆる「大数の法則」ですね。
本人の能力に依存して、掛けた時間に比例していきます。
当たり前ですよね？ ITでも何でもそうです。 じゃあ時間給でいいですよね。
もっと長期で掛かる仕事の場合
研究職などでは確かに一発当てるかどうか、みたいなケースもあるでしょう。
だとしたらこうなります。
ここで疑問ですが
最初の3年は給料を低く抑えられるのでしょうか？
答えはNOです。
低すぎると人が来ないので、ある程度の額になります。
そして唐突に成果が出たからと言って唐突に給料は上がりません。年俸制なので。
そして、成果が出た後も報酬がその分上がるわけではありません、だって最初の成果が出る前との整合性が取れないじゃないですか。
これ結局時間給じゃないですか？ あれ、成果主義ってなんでしたっけ？
成果が出た時に追加で報酬を出せばいいんだ
そうです。それが成果主義です。
つまり、それは賞与です。
一方、裁量労働制は賞与が無いことがほとんどなようです。
あれ、成果主義？
裁量労働制は別に成果主義じゃないですよ
そういえば、誰もそんなこと言ってません。
成果に必ずしも比例しない、というだけです。
そもそも一般的な給与制度の方がよっぽど成果主義的じゃないですか！
裁量労働制で生産性が上がるという勘違い
同じ仕事の量を、短時間で終わらせるようになるため生産性が上がる
という主張がります。
しかし残念ながら話はそう簡単ではありません。
「同じ量の仕事」である保証がどこにもないのです。
仕事は個人プレイではないので、個人の仕事の価値を決めるのはあくまで会社なのです。
これは分かりづらいかもしれません。
例えば
会社がAさんに求める成果の期待値が100、それに対して年俸を1000だとします。
この100と1000の間に明確なレートがありません。
その気になれば120に対し1000とか、200に対し1000というように柔軟に変更できてしまいます。
そんなこと無いと思うでしょうか。
今日やった仕事はいくら分の価値か、あるいは明確に「何を何個」という指標に落とし込めるでしょうか。
時間以外に比例する職業ならOK
時間以外に比例する職業なら、裁量労働制が生きてくると思います。
例えば、一瞬で終わるけどすごくツライ仕事なら、時間給じゃなくて回数がものを言ってきますよね。
でも上でも言いましたが、仕事は繰り返しです。
1年あたりそれが何回発生するかわかれば、時間給でいいじゃないですか。
時短にしたい場合は？
明確に100の価値を生み出したら帰る！
というような制度にしたい場合に使えるように思うかもしれません。
しかし残念ながらそれは現行の制度でも柔軟にできてしまうのです。
労働者に不利な理由
- できたよりできていないことの方が測りやすい
- 往々にして成果は期待値を下回る
そうすると労働者は期待値に達するように長時間働かなければなりません。
未達のときの責任が会社ではなく労働者に行くのです。
フリーランスはどうなっているか？
裁量労働制の思想をモロに反映しているはずのフリーランスですが、最近のITフリーランスは時間給ですし残業代もあります。（悪名高きSESですの話です）
これは語弊がありますが、例えば1ヶ月140時間〜180時間と定め、それを上下超えたら改めて再計算、という方式が取られていることが多いです。
つまりただの上限ありみなし残業制度です。
フリーになってすらこういう制度に落ち着いてる。というのは面白いと思います。
なぜこうなっているかと言えばやはり「労働者に不利」だからです。
成果は往々にして期待値を下回ります。すると安定させるには時間制のほうが良いのです。
裁量労働制は、つまり請負契約に近い
フリーランスでも請負契約をすることがあります。
こちらは未達の場合の責任がフリーランス（労働者）側となります。
瑕疵責任というやつです。
もちろん裁量労働制の場合に瑕疵責任とまでは行きませんが、状況としては似ているでしょう。
ちなみに時間給で働く準委任契約に比べて請負契約の場合は単価が数割高いです。（IT業界だと2,3割くらい違いますかね？）
これは責任の所在が請負側にあるための保険です。
しかし裁量労働制は社員が年俸を決められない状況にあるため非常に不利と言えるでしょう。
まとめ
この制度なんなの？（困惑）
もう忘れましょう。
時間給は悪だ、という論法は大抵間違いだと思います。
問題は大概の場合、成果をきちんと測れていないか、成果に対して賞与が不適切なだけだと思います。
時間給は大抵の場合労働者を守ってくれます。残業はもちろん減らしましょう。それは制度関係ないです。
Amazonアフィリエイト一旦手詰まり
※投稿先ブログ間違えましたｗ
ほんとうはこっちです→
Amazonアフィリエイト一旦手詰まり - ReachA 開発ブログ
＿＿＿
ちょっと混乱しているのでまとめ。
・公式の画像や情報がAPIから取れる
・収益化
・アプリの出口として
主に情報先としてAmazonは強いと思っていたんですが諦めます。だめっぽいです。
これちょっとちゃんとまとめないと破綻するかもですね。
情報が取れる先
Twitter、iTunes、Youtube、ニコ動、公式HP、Wiki、大百科、Pixiv、Yahoo、その他販売店
出口として（コンテンツ）
Youtube、ニコ動、iTunes、Pixiv（音楽は多いので後）
出口として（販売所）
（多いので後）
＿＿＿＿＿
所感
元同僚のアプリエンジニアなんかでもオリジナルアプリの収益化に悩んでる人がそこそこいます。
今回のAmazonMobileAdみたいに、対象商品を選択できないタイプの広告ばっかりなんですよね。そうすると対象商品に関連するアプリを作ってもミスマッチで詰んでしまいます。
逆に「とにかく人を集めればいい」みたいなアプリは強いですね。その最たる例がゲームとキュレーションサービスだと思います。
アプリメインのサービスの場合はアフィ便りの収益化には未だに限界がありそうです。
Amazonアソシエイトfor Appがよくわからない！（未解決）
絶賛混乱中です😥
アソシエイト・セントラル - Amazonアソシエイト・プログラム運営規約の更新履歴
>モバイル・アプリがAmazonアソシエイト・プログラムに参加可能になりました
これが2017年2月15日
該当するのがAmazon Mobile Adだと思いました。たぶんこれは合ってます。
Top
iOS向けモバイル広告 - Amazon Apps & Games Developer Portal
でもこれ違わない？ ってなりました。
Nendとかああいうバナータイプの広告じゃないですか。それじゃないんですよ。
商品リンク（Product Links）は貼れないんでしょうか？
貼れないのかもしれません。ただ確証がもてません。
Mobile Associates API というのがあるらしいです
Mobile Associates API Overview | Mobile Associates API
モバイルって、Webの話？ と思ったんですが
あれ、でもアプリ向けっぽいぞ？
調べると2013年くらいのAndroid向けの記事が出てきます。
ああ・・・
＞日本で使えない
そういうことですか？
2017年にアプリアフィ解禁という話、本家米国のページが見つからないなーと思ってたんですが、日本で解禁したってこと？
まだ調べます
続き
2014年にiOS向けができているそうです
Amazon、iOS向けMobile Associates APIを発表
が、よく見ると「利用不可」になってる模様
AndroidもAmazonアプリが入ってないと使用できないというかなり厳しい縛りがある模様
まあWebView+スマホサイトというゴリ押しは可能だと思いますが
機能を追加するリスク・コスト 継続開発がキツイ理由、詰む理由
若干わかりづらい話をします。半分メモ代わりに。
工数というものは機能単位で出すことが多いですが、実際は「対象×機能」が最も近い値だと考えています。
対象というのは基本的にモデルです。Classと捉えても良いと思います。
一つのClassにまとめられるのであれば（super classを作れるのであれば）、多数のClassがあっても機能追加は高コストではありません。
まとめられないClassが多いほど、また機能が多いほどやることが増えます。
これはスコープを変えて、マクロ的に見てもミクロ的に見ても成り立ちます。
例えばアプリケーション全体ででも考えられますし、一つの画面に対しても考えられます。
上の画像では、対象が３つ、機能が３つで「６個」と捉えたくなりますが、実際は「９個」と捉えるのが正しいです。
感覚値と実際の差が３個分出るので、見積もり漏れにつながります。
（正しく見積もった場合も、そんなにかかるの？と訝しがられます）
普通に考えるとこうです。
機能を追加するには、１個分の開発工数が必要な気がします。
そもそも、改善要求が上がってきたときには、対象ー機能の一つ分しか大抵は意識していません。
しかし、整合性が取れなかったり、あまりに不自然ということで、機能と対象は乗算されます。
そしてこれこそ、継続開発で詰む要因となります。
上の画像で考えます。
対象が５つ、機能が１つです。
機能を１つ増やす際のコストは５個分です。
そして、機能を１つ増やしたことで、将来対象を増やす際のコストが１個から２個に増えます。これが機能を追加するリスクです。
コスト１個と思っていたら、実際には５個で、更に次から全部１個分増える。
そんなことが継続開発の現場では起きています。
しかも、この対象ー機能のラインは保守運用対象であり、リリース時にはテストも必要です。対象と機能を増やすたびに、コストは想定の二乗のスピードで増大します。
この対象ー機能のラインが多くなるほど、整合性を取るのが大変になります。片方を直したらもう片方に影響するなど、密結合・ジェンガコードの状態になてしまいます。
最終的には、ちょっとした改修なのに２週間掛かるような自体に陥り、それはスピード低下につながり、競争力の低下につながります。
困ったことに、そういった場合傍からは大きな工数がかかるようには見えません。また、本当に重要な機能はごく一部であり、それ以外の追加された対象や機能に工数が奪われるような事態になります。
そのようなサービスは世の中にたくさんあります。
大企業や有名なプロダクトにおいても発生しています。
どうすればいいか
機能追加、対象追加のリスクの度合いを把握する。
仕様レベルで疎結合を心がける。（機能ー対象ラインを減らす）
さもないと、実装レベルでどれだけ疎結合を気をつけても複雑度が高くなってしまいます。
ただ、プロジェクト的にここらへんを制御できる立場にいるエンジニアはかなり少ないと思います。
じゃあどうすればいいか、というのは現状ではあまり思いつきません。
自分がPOになるくらいですかね。
参考
（追記）少し修正：対象のほうがコストが高い
機能というのは例えば「画面」「検索」「お気に入り」「保存」などがが考えられます。
対象というのは例えば「商品」「レビュアー」「色」「在庫数」などです。
工数はやはり「対象×機能」に比例して発生するので、「対象を増やすこと」と「機能を増やすこと」は同等に見えます。
しかしよく考えてみると、対象を増やすと自ずと機能が自然発生してしまうことが有ります。
例えば、「店舗」に「位置情報」という対象を追加すれば、「店舗の地図」のような機能が欲しくなるように。
もちろん機能をWANTにすることもできるでしょうが、ものによってはMUSTになってくるでしょう。
更に言えば、大きな対象（Class）を作ると、自ずとその子の対象が生まれることが有ります。
対象を増やす方が合計したリスクは大きくなるはずです。機能を増やすことより対象を増やすことに慎重になったほうが良いのかもしれません。特に大きな対象は覚悟が必要です。
機能そのものを増やすより、対象そのものを追加するほうが軽いように思えてしまう所も罠です。
ECサイトの例が分かりやすいかもしれませんね。商品に加える情報や、扱う商品のタイプを増やせば増やすほどしんどくなります。最初は5人程度で作っていたのが、やがて50人体制になり、それでも進捗がスローに感じてしまうやつです。
それで上手く成長すれば良いんですが、方針転換が迫られたり、新しい概念を導入しようとすると素早い対応ができなくなります。
これ、今回はざっくり抽象的に考えてみましたが、より詳細な分析もできそうですね。
対象のタイプとか、複数の対象が混ざるケース、更に保守運用のコストなど。
こういう戦略の話ってどこかで研究されていないんでしょうか？聞いたことが無いです。
追記：敢えて言えばファンクションポイント法？
