falchionz’s diary

おもに音楽、読書、ゲームについて感じたことや日々の仕事で感じたことをつらつらと記載します。

JASRACもNHKも一緒?

ついにJASRACを追い込むか? ファンキー末吉と江川ほーじんの闘いに決定的な新兵器が登場(松沢呉一) -2,388文字-[無料記事] | 松沢呉一のビバノン・ライフ

この記事を見て、構造的な不公平感はJASRACの問題もNHKの受信料も同じかなと思った。
細かく実績をカウントできないからドンブリで徴収して、収益の分配は曖昧なままスルー。
とても似ていると思う。

JASRAC概論―音楽著作権の法と管理

JASRAC概論―音楽著作権の法と管理

JASRACに告ぐ(晋遊舎ブラック新書 5)

JASRACに告ぐ(晋遊舎ブラック新書 5)

著作権法要説[第2版]―実務と理論

著作権法要説[第2版]―実務と理論

苦しいときこそ、真摯に向き合う姿勢が必要

請負プロジェクト開発のマネージャーという仕事をしていると、
往々にして納期、コストといった面で顧客と社内の狭間で
葛藤する状況に陥ることがある。
そういったときに大切なのは「バランス感覚」だと思う。
顧客に寄り添いすぎてもだめだし、自社の事情を押し付けてばかりでもだめ。
バランスを欠くと、視野狭窄となり、無茶なスケジュールや、
品質を担保することが難しい進め方(五月雨リリース、段階リリースなど)
といった案を考えがちだが、要件定義を経て開発ボリュームが
増えた場合などは、まずしっかり、

・何が増えたのか
・それは当初要件から追加なのか?深さ(難易度)が増えたのか?
・それは、現行ある運用なのか?新規追加なのか?

といった点を要件ごとに分析し、増えた要因を整理する必要がある。
その上で、顧客のプロジェクトの目的から、
要件の優先度を大胆に整理、提案する必要がある。

そう、開発ベンダーのマネージャーという立場であれば、
プロジェクトが立ち行かなくなる、開発規模が肥大化しすぎて、
品質面のリスクがあるといった、言いにくいことも言う義務があるということを
以下の本を読んで改めて認識した。

なぜ、システム開発は必ずモメるのか?  49のトラブルから学ぶプロジェクト管理術

なぜ、システム開発は必ずモメるのか? 49のトラブルから学ぶプロジェクト管理術

本書は、実際のシステム開発のトラブル事例を元に、
それを避けるために必要なプロジェクトマネジメント上の心構えや
必要な備えについてわかりやすく紹介している。
小説風に記載されており読みやすく、内容もよく頭に入ってくる。
長年開発業務に携わっているとちょっと偏りがちになってくる考え方を
ニュートラルな位置にリセットしたいときなど、折に触れて
読み返したい本である。

どうすれば、部下のモチベーションをあげれるか? ~ 一人ブレスト ~

やらされ仕事から脱却して欲しい。

けど、本人から仕事に対する情熱を感じない、、、
頼んだ以上のクオリティは出せないのでだんだん頼めなくなる悪循環…
これをどう打開するか?
 
そもそも何故情熱を持って仕事に取り組む姿勢を示せないのか?
そこには「あきらめ」と「無目標」があるような気がする。

何をやってもあまりぱっとしない自分、
いい年なのにうまく仕事さばけないことからくる劣等感
言いたいことがあるのにうまく言語化できないことからくるもどかしさ
それらが八方塞がりでどうしようもないと思わせてしまい、
やがてあきらめることに慣れていくのかと。

新入社員の時には目標って何かあったのだろうか?
まずは仕事を覚えることで精一杯でとりあえず目の前のことに
無我夢中で取り組んでいて、中長期的な視点なんて持つ余裕もないまま
3年くらいがあっという間に過ぎていったような気がする。
明確に何かゴール設定してどうのというのは無いけど、
システムの受託開発は相手の要望ありきで話が始まるので、
いかに満足してもらえるようにシステムを組むか、
相手の意図をできるだけ汲み取ることを心がけていたように思う。
実際、汲み取れてるかといったら、網目の大きいざるで水をすくってるよなもので
なかなか真意を推し量ることができていなかったと思うけど、
でも、そういった姿勢は持っていたと思う。

最近は要件定義フェーズをきっちり設け、要件を整理したうえでシステム開発に進む。
自分はパッケージに対するカスタマイズを前提としたシステム構築プロジェクトの
プロジェクトマネージャを行っている。
最近は要件のヒアリング、業務フロー、データフローの整理などを顧客とコミュニケーションしながら
パッケージのいいところと過去の事例踏まえてのカスタマイズ提案などを盛り込み、
顧客の目標に寄り添ったシステム構築を行うことを心がけている。

相手の言わんとすることを読んだり、相手の目線に立って説明したり、
相手に合わせて仕事をできるようになったのは、ごく最近だと思う。

そうか、部下に接するときも同じだ。。。

部下の気持ちにどう寄り添っていけば良いのか、考えてみたいと思う。


 

目からウロコのコーチング―なぜ、あの人には部下がついてくるのか? (PHP文庫 は 46-1)

目からウロコのコーチング―なぜ、あの人には部下がついてくるのか? (PHP文庫 は 46-1)

 
アドラーに学ぶ部下育成の心理学

アドラーに学ぶ部下育成の心理学

 
「ついていきたい」と思われるリーダーになる51の考え方

「ついていきたい」と思われるリーダーになる51の考え方

 
部下を定時に帰す仕事術 ~「最短距離」で「成果」を出すリーダーの知恵~

部下を定時に帰す仕事術 ~「最短距離」で「成果」を出すリーダーの知恵~

 

 

 

twitter良い話しからのナポレオンヒル「思考は現実化する」流し(締めはKEMURI)

twitter創業時の良い話。

 

ツイッター創業者ビズ「僕がツイッターのコードに人間味を付け加えた。」|リーディング&カンパニー株式会社

 
なんと何人ものツイッターファンがオフィスにピザを届けてくれ、サイトがダウンしているのを責めるのではなく、頑張れと励ましてくれていたのでした。ビズはその時のことを次のように述べています。

「僕たちを応援してくれていた。僕たちはバグや欠陥で彼をいらいらさせている名もないロボットではなかった。誠実であろうとしたことで僕たちの人間らしさが伝わって、ユーザーが善意で応えてくれたのだ。」(P139)4020698960_c4d297e0be_z

 すごいなぁ。
 
ビズ・ストーンはプログラミングのスキルもお金もありませんでしたが、「社会貢献をしない会社は競争面でも不利になる」とコミュニケーションを通じて数式に人間味を吹き込んだことがツイッターの成功の大きな要因だと言われています。
 技術も金も無くても、「人間性」とか「情熱」とか、「誠実さ」とかというものも立派な武器になり得るという話。
見習いたい。
今読んでいる本にも通じる話かも。

 

思考は現実化する〈上〉

思考は現実化する〈上〉

 

 自分はこの本に書かれているような明確な目標を持てるところまではいたれていないけど、この本に書かれている、

という考え方にはとても共感する。

やっぱ、事業を始めるような人たちってのはとんでもなく前向きでポジティブなメンタルを保ち続けるべく努力している人たちなんだろう。

自分はまだそこまでいたれていないけど、この本を読んで、すくなくともそういった考え方を持っていない限りは成功できないという点については納得した。

あと、

  • エジソンは1万回以上失敗して電球を発明した
  • リンカーンは40台まで何をやってもぜんぜんだめな人だった

あきらめない限りは失敗は成功の糧となり得るという考えもとてもすばらしい。

PMA:Positive Mental Attitude

って、昔KEMURIスカパンクバンドが言ってたのを思い出した。

ナポレオンヒルからだったのかな?

 

our PMA

our PMA

 

 

 

 

 

new 3DSへの引越し

 

New ニンテンドー3DS LL メタリックブルー

New ニンテンドー3DS LL メタリックブルー

 

 先週、New 3DS LLを購入した。

まえは3DS LLを使っていたのだが、妻がどうぶつの森をやりたいそうで、

平日に会社に持っていかれたくないそうで、購入の許しが出た。

で、買ったはいいんだけど、古い3DSにはダウンロードソフトとかが入っているので

データの引越しがしたい。

やり方自体は以下のページを見ればわかるんだけど、引越し後の古い3DSのデータは消去されるという記載が気になってなかなか引越しできなかった。

ニンテンドー3DS|その他(ソフトとデータの引っ越しについて)|Nintendo

要は、古いほうのどうぶつの森のセーブデータも引っ越したら消えてしまうと

妻が大激怒するであろうと・・・

結論からするとこれは杞憂で、カートリッジ版であればソフト本体にセーブデータは

保存されているので、問題なく引越しすることができた。

QAとかかなりあさったけど、答えが見つからなかったので記載しておく。

結構迷うような気がする。


ニンテンドー3DS|ソフトとデータの引っ越しについて Q&A|Nintendo

あと、今回ダウンロード版じゃなかったから良かったが、ダウンロード版だったら3DSは二人で本体共有とかはしないほうがいいみたい。

もう少し融通の利く引越し仕様にしてほしいかな・・・

 

 

日本で割とCDが売れ続けてる理由

なぜ日本人は未だにCDを買い続けるのか | VICE Japan | The Definitive Guide to Enlightening Information

 

CD、自分は最近買わなくなって久しいですけど、

海外に比べるとまだ日本はCD売れてるんですね。

邦楽はまあ、握手券とかコアなファンとのふれあいとかの体験とセット売りでがんばってるのかもしれないけど、洋楽ってどうなんだろう?

自分は洋楽のCD買うときは必ず国内盤を買っていた。

値段高いんだけど、ライナーノーツとかボーナストラックがついてたりしたので。

海外盤はパッケージも大体適当だし、ライナーノーツついてないし、

音楽なんだから中身が大事でしょ!?

といった感じなんでしょうか?

国内盤のこういった丁寧な仕事ぶりがあるから、デジタルで楽曲だけダウンロードするのみというのと差別化できているのだろうか?

とはいえ、全体の売り上げボリュームはやっぱり下がってるんだろうな。

洋楽の国内盤と海外盤の売り上げ比を見るとわかるのかな?

 

 

課題管理表の書き方のコツ

議事録の書き方が好評なようなので、システム開発のもうひとつの生命線である、
「課題管理表」の書き方について記載してみたい。

後で見返したときに「えっとこれなんだっけ?」にならないように記述する

課題管理表を運用していくと良くありがちなのが、定例会などで皆でしばらく経ってしまった課題を見たときに、
具体的にどんなことが課題だったか、記載内容から思い出せないケースというのが割りと良くある。
これは
 ・どういった経緯から発生した課題か記載が無い
 ・主語や、指示語、目的語に不備があり、ターゲットが不明確
といった点から発生する。
これらを回避するためにも経緯や主語、指示語、目的語を意識した記述を心がける必要がある。

エクセルのセル内は降順で

これはエクセルで管理する場合のちょっとしたこつだが、
エクセルは印刷するとPC画面上表示されているけど下部が見切れてしまっているということが良く起きる。
各課題で大事なのは、「で、結局今どうなんだっけ?」なので、
もっとも確認したい最新の記述がセルの最上部になるように降順で記載するのがミソ。
課題は定例会などで毎週確認したりするので、ひとつのセルの中で

○○○という内容で確定。クローズ。
(2014/9/15 担当○○)
---
社内承認中。次週再確認。
(2014/9/8 担当○○)
---
次週までに確認する。
(2014/9/1 担当○○)

といった記述をする。こうすることで、セルを小さくしても結論だけは見える。
大事なことは目に付くところに配置する。
あと、エクセルで日付入力は「Ctrl+;」でできる。
(ちなみに時刻は「Ctrl+:」)
打ち合わせの場で課題管理表記載する際に日付入力は
かなり便利なのでこのショートカットはお勧め。

担当はバイネームで履歴を残す

課題管理表あるあるでもうひとつあるのは、
「で、これって誰が対応するんだっけ?」という事態。
これも担当の確認からとなってしまうと時間の無駄、仕切りなおしになってしまうので
極力課題発生時点で担当者名を記載しておく。
課題が進捗して担当が変わったら、適宜担当を変更するなど、まめに調整すること。

課題管理表の管理はベンダー、ユーザーいずれかで行うこと

課題管理表のメンテナンスは基本必要としている側でメンテナンスするべき。
よく、お互いに更新しあうような事態になっているケースを見るが、マージする手間や、
管理者が本当に管理したい課題事項のピントがずれたりするので、基本的にメンテナンスは1組織内で
行うのが望ましい。
結構、課題管理表に記載するしないとか記載に対する結果の記述とか、戦略的に言い回しを意識したりしながら
記述しているので、その辺のコントロールができるようにしておく必要がある。

期日は超過したら即期日の再調整

課題管理表あるあるでさらにあるのが、期限切れ課題の期限設定を再設定していないで、
糸が切れた凧みたいになってしまっているケース。
期日を超過した課題は、担当者に詰め寄って、いつなら対応可能なのかを宣言させる。
担当者が課題解決に対して必要なプロセスが見えていないようであれば、
必要と思われるプロセスをわかる範囲で提示、さらに期限を超過した場合のプロジェクトに
与えるインパクトについてもあわせて共有し、期限を守ることに対する意識付けを行う。
とはいっても、約束を守ってくれないユーザーの多いこと多いこと・・・
忙しいのはわかるんですけどね。

クローズした課題は定例会でクローズ宣言したら非表示に

課題管理表は意識的にクローズにしていかないと、加速度的に課題がつみあがっていく。
なので何が解決したらクローズできるのかを意識して課題立てするのと、いったんクローズした
課題は定例会の場で関係者に対してクローズする旨を伝えOKであれば非表示にしていき、
現在生きている課題と、直近でクローズした課題だけ表示するようにする。
この辺の見易さ、何を確認すればいいのかを明確にすることを課題管理表の管理者は意識する必要がある。

その場で確認が取れたことも重要事項はあえて記載、即クローズする

これは戦略的に行う上級テクニックかもしれないが、口頭で確認、即回答もらえた課題事項は
課題管理表に記載されないケースが多い。
しかし実はプロジェクトの方向性や、費用、納期といった重要事項に関連する内容であれば、
議事録だけではなく課題管理表にも記載しておくのが有効。
忙しくなると議事録の作成にタイムラグが起きたりするケースが良くあるが、とりあえず課題管理表は
逐一メンテナンスするようにしていれば何とか回るケースが多い。
課題管理表に記載しておけば、いつ、だれが、どんな内容を決定したのか、のログが記録できるので
後々役に立つ場合があるので、記載しておくのが吉。

以上、課題管理表の書き方のコツでした。
結局、どんなにきれいに課題管理表を記載したとしても
課題が消化されなければ意味が無いわけだが、少なくともどんな課題だったか、誰の担当か、いつまでに回答必要か
がはっきりしていればいちいち思い出したり、たなざらしになってたりということが少なくなり、
プロジェクトを円滑に進めるのではないでしょうか。
課題管理表をメンテナンスする人は、自分の記載の仕方ひとつでプロジェクトを迷走させてしまう可能性があること、
うまくやればスムーズなプロジェクト運営に貢献できることを意識してもらいたい。
非常に意義深い、やりがいのある作業だと思う。(大変だけどね。)