nDiki : ソフトウェア開発
2013年9月7日 (土)
床屋: ゆっくり丁寧と品質は比例しない
9:30 いつものアドバンストヘアーナカタニで。2013年6月8日以来約3カ月ぶり。
今日はカットできるクラスの人が少なかったのか、しょっぱなから顔剃りという超レアな進行。いつもより、ゆっくり丁寧な感じに、何度も同じ箇所に刃をあてて、剃られた。でも家に帰って鏡を見たら鼻の下に剃り残しがあった。
ゆっくりやったからって、いい仕事になるとは限らない。ソフトウェア開発と同じだなあと。
2014年3月13日 (木)
今日のさえずり: <3 が屁にしか見えなくて辛い
- 08:33 #app道場 / “app道場(多機能携帯電話向けソフトウェア開発勉強会) : ATND” http://bit.ly/1nOMAlf
- 08:54 鼻の中の吹き出物から毛が出ていて「毛穴のところが吹き出物になったんかな」と良くみたら他のところの鼻毛が貫通していた。鼻毛相変わらず猛々しいな(たまに皮膚に刺さってる)。
- 11:07 Ruby 読み書きする気運が高まっている。1日で Ruby マスターできる本どれ。
- 11:36 <3 が屁にしか見えなくて辛い。
- 13:19 最近重いので試す。 / “Google Chromeを限界魔改造！ギリッギリまで高速化する裏ワザまとめ | BITA Blog - 株式会社ビットエー” http://bit.ly/1fsdpoL
- 19:28 curl -sSL https://get.rvm.io | bash -s stable したら勝手に .profile .bash_profile .bashrc 書き換えられてイラッとした。
- 20:49 雨やんでる。チャンス。 (@ 株式会社ミクシィ (mixi, Inc.)) http://4sq.com/1nS9S9X
2015年5月13日 (水)
レクサー・リサーチ開発同窓会
2月の Developers Summit 2015 で zakwa 氏と再会したのをきっかけに、当時一緒に仕事をしていた気が置けないソフトウェア開発者4人で同窓会をすることになった。セッティングしてくれた zakwa 氏ありがとう!
COGS DINING KAGURAZAKA (コグス ダイニング 神楽坂)
手配してくれたお店は「焼きたてパンとワインのお店」COGS DINING KAGURAZAKA。神楽坂から路地に入ったところにあるお店で、上品な味の料理で満足だった。店内もうるさくなくて話しやすかったし、たばこを吸っている人もいなかったので快適だった。
ソフトウェア開発
現職のまま続けている1人と、別の場所で働くことになった3人だけれどみなそれぞれソフトウェア開発現場に関わっていて、それぞれの開発スタイルなどについて情報交換したり。
大企業だからしっかりした開発をしているとか、スタートアップだからモダンな開発をしているとかでは必ずしも無いよねという話だった。例えばバージョン管理一つにしてもうまくできていない(やっていない)場合も多いとのこと。当時を振り返ってみると小規模かつ独学の状況ながら、今では普通になってきたプラクティスやツールをその時から実践/活用していたなと自画自賛した。
- プロジェクト
- ソフトウェアかんばん
- ITS (影舞・Redmine) の利用
- BTS やコミットメントリストとして。
- スタンドアップでの朝会
- すごい会議
- 成果物完成毎の記念撮影
- 情報共有
- 開発ツール
- バージョン管理 (CVS・Subversion・Git)
- pLaTeX2e を使ったドキュメンテーション
- その他
- 書けなくなったホワイトボードマーカーはその場で床に投げ捨て
「書けなくなったホワイトボードマーカーはその場で床に投げ捨て」に共感を持ってもらえていたのが、振り返って当時の自分の一番の成果だな。
退職時に使っていた社内 Wiki は Naney 謹製のものだったのでその後どうなったのかなとたまに気になっていたのだけれど、ビル管理会社の人に社内サーバの電源を切られたことによりサーバごと死んで闇に葬られたらしい。R.I.P.
その他
同窓会らしく「あのひとは今」的な話をしたり、当時フィルムカメラで撮っていた業務風景のアルバムを持ってきて盛り上がったり。あとはレーシックやドライアイ治療ひぇー的な話題が出たり。あとは展示会の時のレクサー・リサーチポロシャツ制作秘話とか。
そういえば出席はできなかった2013年2月開催の「LEXER設立20周年記念サロン・パーティ」で会社のるぐるロゴの立体置物が配られたと聞いて、あ、欲しかったなーと。
2015年7月14日 (火)
8年経っても色褪せない「サービスを超える瞬間」
ちょっと前からまた「サービス・ホスピタリティ」の本である「リッツ・カールトンが大切にする サービスを超える瞬間」を読んでいたんだけれど、前回読書ノートを書いたのがちょうど8年前の今日だった(その時のノート)。
当時はまだ CS 活動には携わっていなくて、 R & D 的なソフトウェア開発の仕事をしていた。この時は「クレド」について知りたくてこの本を手にした。しかし今はまさに「ホスピタリティ」について吸収したくて読んでいる。もしかしたら CS に関わることになったのも必然なのかもしれないな。
ホスピタリティ
ホスピタリティとは、心からのおもてなしをするということです。(中略)もう少しわかりやすく、ホスピタリティとは、お客様に愛情を示すことである、と言い換えてみます。 p.200
サービスを超える瞬間
本書ではサービスを超える瞬間について下記のように書いている。
サービスを超える瞬間というのは、お客様が言葉にされないニーズまでも十二分に満たされたときなのです。 p.41
言葉にされない願望やニーズを先読みしておこたえすることでお客様に感動を与えられる。 ユーザーコミュニケーションやユーザーサポートにおいては、常に意識していきたい。
「リッツ・カールトンが大切にする サービスを超える瞬間」は CS に関わっている人必読である。
- リッツ・カールトンが大切にする サービスを超える瞬間
- Amazon Kindle 版もあり。
2016年4月23日 (土)
Hour of Code ワークショップに参加
今日は株式会社ミクシィで開催された「プログラミングを学ぼう 〜『Hour of Code』ワークショップ ＠ミクシィ〜」にチューターとして参加してきました。
「Hour of Code」はコンピュータサイエンス/プログラミング教育活動を子供たちに普及させる運動で、 PC やタブレットから https://code.org/ で提供されている教材にアクセスして学ぶことができるようになっています。
今日はマインクラフトをテーマにした教材を使ったワークショップを開催しました。 Hour of Code の教材は、コマンドにあたるブロックを順に並べていって実行させるというビジュアルプログラミングの形なのでマウス/タッチ操作でプログラミングを学ぶことができます。先に進んでいくと繰り返し実行ブロックや条件付き実行ブロックも出てくるのでプログラミングの重要な概念も学べるようになっています。
冒頭に挨拶と説明があった後、参加者の子供たちが一斉にプログラミングに取り組み始めました。本日お越しいただいていた「一般社団法人みんなのコード」代表の利根川さんが「あまり教えすぎないようにしましょう」とおっしゃっていたのを心に留めてフォローに入ります。
小学生の時に初めてプログラミングに触れた自分自身の原体験、そしてその後のソフトウェア開発を振り返っても確かにプログラミングは「教わるのではなく試行錯誤を繰り返して気付いて」学んでいくものでした。子供たちが作ったブロックの並びが「あ、それだと違う……」と思ってもぐっと我慢。実際に実行すると何が起きるのかを試している間はそっと見守ります。
ただ完全に詰まってしまうとやはり楽しくなくなって諦めてしまったりするので、そうなる前には少しだけ手を差し伸べてあげる必要があります。このタイミングを外さないようにするのが難しいところですね。
どんどん問題を解いてクリアしていく子はもちろんですが、進みは遅くともいろいろ繰り返していく子こそ学びがあって今回参加して良かったんではないかと思います。挨拶をしたり手を振ったりしながら帰っていった子供たちが今日のワークショップでプログラミングを好きになってくれていれば嬉しい限りです。
チューターを担当した私自身も、教えながらあらためて学ばせてもらったので感謝です。
2016年11月8日 (火)
第3回 エッセンシャル スクラムを読む会
社内で「エッセンシャル スクラム」を読みたい人が集まる勉強会3回目。今日は第3章 アジャイルの原則。
原則を語るにしては計画駆動との対比が多く、ちょっと読後感がすっきりしませんでした。「アジャイルの原則」の章なのにスクラムの話しか出てこないのもちょっと残念でした。スクラムにおけるアジャイルの原則という章だったら気にならなかったんですけどね。
イテレーティブとインクリメンタルの話のところでは
スクラムでは、イテレーティブな開発とインクリメンタルな開発の両方の利点を活用する。そうすることで、両者を個別に用いる際の欠点を無視できるようになる。
とさらりと書いてあるのですが、これは参加者でも引っかかっている人がいましたし、私もちょっと釈然としませんでした。両方の利点を活用するという点は良いのですが、欠点を無視できるようになるというのは説明しきれていないなと。
「3.3 予見と適応」では
コミットメントを先延ばしにし、重要で後戻りのできない決定をしかるべき最後の瞬間まで行わないのである。
とし「判断することのコスト」曲線と「判断しないことのコスト曲線」が交わる最終責任時点がその瞬間であるとしています。主張は理解できますが、結局この曲線が明確になることは無いですし結局勘に頼らざるを得ないと感じました。
アジャイルの原則自体はしっかりしたものだと思っているのですが、この章ではそれがうまう伝わってこない気がしました。
WIP にまつわる話
作業者の手持ちではなく、作業の手持ちに注目せよ
は、あらためて思い返すことが出来て読んで良かった点です。この話はトム・デマルコの「ゆとりの法則」でも言われていることで再認識することができました。
「稼働率」と「フロータイム」「リードタイム」「WIP」のあたりは製造業だとメジャーな話ですがソフトウェア開発においては、それほどは話題にならない気がします。
勉強会でも、腑に落ちない人が多かったようです。空いた時間はもったいないので他の仕事を着手した方が無駄がないんじゃないかとつい考えてしまいますよね。
2017年1月22日 (日)
WIP を下げるために GTD でプロジェクトリストからバックログを分ける
スクラムでソフトウェア開発をしていて仕掛り(WIP)を減らすことのメリットを体感しています。そして考えてみるとプライベートを含め個人でやる事がどんどん増えてしまっている理由の一つに WIP が多すぎるのではと思えてきました。
GTD では次の行動を決めてリストに放り込み、あとはその時の状況で実行可能なものを選んでやっていきます。局所的には一番効率が良いように見えるのですが、気をつけないと WIP なプロジェクトがどんどん増えてしまいがちで、自分の場合、気がつくとあまり何もできていないなという状態になってしまいます。
Someday/Maybe リストが GTD にはあるので、すぐにやらないものはそこに入れておくという方法もあります。しかしこのリストはかなりぼんやりしたものも混ざっているので「既に ready だけれど WIP を上げないためにまだやらないプロジェクト」を一緒に入れておくのはかなり気持ち悪い。
ということでプロジェクトリストについて「(狭義のやっている/やる)プロジェクトリスト」と「バックログリスト」の2つに分けてみることにしました。タスク管理ツール Remember The Milk でバックログリストの方のタスクは拾わないようにスマートリストを修正。毎朝軽く眺めてバックログリストから今日仕掛ってもいいものをプロジェクトリストに移すようにします。
今日やり始めてみたところ前よりは集中して取り組めて捗りました。いいかも。
2019年11月13日 (水)
プロダクトマネージャーカンファレンス 2019 2日目 #pmconfjp
プロダクトマネージャーカンファレンス 2019 2日目。1日目の昨日に引き続き参加。
以下タイトルは公式サイト掲載のものより。
10:00 - 10:10 [MainRoom] Welcome Talk
横道稔氏。
10:20 - 11:10 [MainRoom] 今からはじめるデザインスプリント
株式会社シークレットラボ代表取締役 / エクスペリエンスデザイナー 佐藤 伸哉 氏
デザインスプリントの概論。実体験に基づくポイントの話が興味深かった。
- ステップのポイント
- Google 流では6ステップ。DEFINE が入った。
個人の力を重視し、声の大きさを排除する。
その他ポイント。
11:20 - 11:50 [MainRoom] 米国スタートアップ&グーグルを経て実践する、失敗し続けて学んだメルカリUSのプロダクトマネジメント
株式会社メルカリ Director of Product Management, Mercari US in Tokyo Brad Ellis 氏
フレンドリーで愉快なおじさん風なのだけれど、すごい経歴の Brad Ellis 氏。楽しくトークを聞くことができた。
グローバルな組織では「多様性」「共有」「期待の明確化」「Internal PR」などが大切とのこと。グローバルなプロダクトに対しては「各ローカル(国、都市と地方)に合わせていくこと」の重要性を話されていた。また優れたサービスを先行してる国(例えば日本)から他の国へ展開していく事例についても紹介されていた。
始めの方にあった「You are not the user」では昨日の増井氏の発表を思い出しておかしくなったよ。
12:00 - 12:30 [MainRoom] A day in the life of Silicon Valley PM
Smule, Inc Head of Product in AI (Principal Product Manager) 曽根原 春樹 氏
PM の考え方のシャープなセッション。「Think big」「上手に失敗する」。
13:30 - 14:00 [MainRoom] プロダクトアウトな新規事業立ち上げのリアル
株式会社プレイドプロダクトマネージャー 棚橋 寛文 氏
KARTE の事例。
14:10 - 14:40 [MainRoom] DXにおけるプロダクトマネジメント
- 株式会社三菱ケミカルホールディングス 先端技術・事業開発室 デジタルトランスフォーメーションGr Chief Digital Architect 伊東 武 氏
- 株式会社日本経済新聞社 デジタル編成ユニット CPO室 部長 重森 泰平 氏
- 株式会社デンソー 部長 成迫 剛志 氏
日経の方の話が一番しっくりくるし実践されている PM の話だった。他のお二方のは立場が違うのかちょっと雰囲気が違う感じ。
14:50 - 15:20 [MainRoom] プロダクトマネージャーが知っておくべき、「OKR」を通じたこれからのチームマネジメント
プロノイア・グループ株式会社 CEO(Chief Executive Officer） ピョートル・フェリクス・グジバチ 氏
「OKR っていう言葉は使わなくたっていいじゃん」
- B2B に比べて B2C はボトムアップが自然。
- Un-Learn。
- Google だって四半期で計画。
- OKR が人事考課につなげるかは YES も NO もありえる(ただしスコアを直接の評価にしない)。
「承認 x 感謝」が大切で、マネージャーとして次のような態度を常にもっている必要がある。
- Sympathy = 同情
- Empathy = 共感
- Compassion = 思いやり
15:30 - 16:00 [Room2-2] プロダクトの強い軸を作るプロダクトマネジメントフレームワーク
Tably株式会社 小城 久美子 氏
プロダクトの Core・Why・What を決めていくプロセスのフレームワークの紹介を実践を通じて説明。とてもわかりやすく参考になった。
キーワード: 「リーンキャンバス」「PRD」「インセプションデッキ」「バリュープロポジションキャンバス」「ユーザーストーリーマッピング」
16:00 - 16:20 [MainRoom] コネクティドカーにおけるプロダクトマネージメント
日産自動車株式会社 コネクティドカー＆サービス技術開発本部ソフトウェア＆ユーザーエクスペリエンス開発部アプリケーション＆サービス開発グループ主担（プロダクトマネージメント）海老澤 雅之 氏
ソフトウェア開発をウォーターフォール開発からアジャイル開発したよという話と、アプリの紹介。
今日はここで退散。
About
Naney (なにい) です。株式会社MIXIで SNS 事業の部長をしています。
※本サイトの内容は個人的見解であり所属組織とは関係ありません。