このすみノート

Webエンジニアが技術や趣味を書くブログです。

会社はオーケストラ、カンブリア宮殿のメトロールで人材登用術に感動した件

日曜の昼下がりに昼飯を食べながら、ネットもテレ東でカンブリア宮殿 を見ていたのですが、メトロールの人材登用術(人材活用術)に感動しました。

未視聴の人は、配信されている内に観たほうが良いくらいにはすごかったです。

www.tv-tokyo.co.jp

何に感動したのか?

役割の与え方がうまく、社員それぞれが活躍できるポジションで、活き活きと仕事されているのが素晴らしいです。

  • 定年なしのシニア採用: 体力は衰えても、培ってきた技術は衰えない。シニアの経験を活かして、若手リーダーを積極的にサポートする
  • 若手社員のリーダー登用: 失敗しても許される文化だから、若手も積極的にチャレンジできる。シニアの知恵袋によって、サポート体制が整っている
  • パート社員のセル生産: 1人で製品を作り上げるから、責任感を持って仕事に携われる。だんだん自分が作れる製品のバリエーションも増えていくから、成長も実感すできる

月曜朝礼の雑談

  • 憂鬱になりがちな月曜の朝を、心休まる雑談でスタートできるのは、かなり良さそうでした。
  • 面接の最初で相手の緊張をほぐす、アイスブレークのようなイメージです。

1対1の1時間雑談

  • 社員同士が1対1で雑談します。
  • 社員間の連携を高める目的で実施されているようですが、職場で誰にでも相談できる空気づくりに一役買っているようで、良い意味でアットホーム感が素晴らしい!

若手リーダーをシニアがサポートする

  • 若手を積極的にリーダー登用するのですが、若手社員は経験値が不足しがちです。
  • そこを人生経験豊富なシニアメンバーがサポートすることで、リーダーが積極的にチャレンジできる環境が生まれます
  • シニアが持つアナログ技術と、若手が持つデジタルやソフトウェアの技術を融合することで、より良いモノを作り上げる意図もあるようです。

セル生産

  • セル生産は分業制の逆で、一人で最初から最後まで製品を作り上げます。
  • 一般的には分業制のほうが効率的と言われることも多いですが、セル生産方式によって、パート社員も製品を自分で作り上げるやりがいを感じす。

まとめ、会社はオーケストラである

メトロールの何がすごいって、社員間の連携を高めようとしたり、アットホームかつハイモチベーションを作る努力がすごい。

最優秀経営者賞を受賞されたようで、それも納得の組織でした。 定年を廃止するのは勇気のいることだと思いますが、それによって次世代の若手リーダーが経験豊富なシニアのサポートで育つわけですから、そりゃあ良い会社になるわと終始感動です。

社員それぞれが違う楽器を持ち、オーケストラのように共創する組織、侮れません。

www.metrol.co.jp

video.tv-tokyo.co.jp

Parabolというアジャイル会議ツールでMad Glad Sad による振り返り

Parabolというツールを使って、ふりかえりをやってみました。 自分が発案者というわけではなく、参加者として参加したのですが、Mad Glad Sad(喜・怒・哀)というテンプレートで実施しました。

思いの外チーム内のコミュニケーションが活性化されたので、感想など記します。

www.parabol.co

Icebreak(雑談)

本題のふりかえりに入る前に、まずIcebreak(雑談)を実施しました。 参加者それぞれにバトンが渡され、ひとりずつ雑談的な内容をプレゼンします。

おもしかろかった動画の話や、趣味、最近の出来事など、なんでもありです。 場が和んだところで、本題のふりかえりにうつります。

Mad Glad Sad

雑談が終わったら、一定の時間を設けて、各自がMad Glad Sadを列挙していきます。 Parabolの場合は、ひとつのボードにみんなのMad Glad Sadが集約され、匿名で記載されます。

Glad

嬉しかったことや、良かったこと、感謝したいことなどが挙げられました。

  • Aさんが率先してインフラを整備してくださっている
  • コードレビューが丁寧でありがたい
  • 他のチームとうまくコミュニケーションできた

などなど。 誰かを感謝する文化にも繋がっています。

Sad

  • タスクのスケジュールが遅延してしまった
  • 情報が足りなくて設計に時間がかかってしまっている
  • リリースに失敗してコミットをリバーとした

などなど。 今週あったトラブルや、開発で詰まっていることなど、悲しい出来事が列挙されていきます。

Mad

喜怒哀楽の怒ですが、どちらか言うと驚いた出来事が挙げられました。 あと、中にはプライベートな出来事を挙げる人もいました。

  • AWSのコストが上がっている
  • いつも買っている食品が売り切れてた
  • キーボードが水没した

わりとMadはフリーダムで、なんでもありな気がします。

グルーピングと投票

みんながMad Glad Sadを列挙し終えたら、似たような項目をグルーピングし、最後に気になる項目へ投票します。 票の多かった項目をひとつずつディスカッションし、今後に向けた改善を話あったり、改善項目を具体的なタスク化していきます。

感想

Mad Glad Sad(喜・怒・哀)によるふりかえりは、おもしろかったです。 雰囲気で参加したので、正式なやり方から逸脱した部分はありそうですが、何よりチーム内の雰囲気が良くなりました。

ふりかえりはツール使うと、円滑に進めやすいこともわかったので、Parabolわりとオススメです。

www.parabol.co

受託開発のメリットを活かせ!失敗しないプロジェクト運営のコツを受託開発の極意で学

「受託開発の極意」という、岡島幸男さんの本を読みました。私はたまたま図書館で見かけたのですが、200ページに届かない文量で、ページ数こそ少ないものの、ノウハウがギュッと凝縮されている本です。

極意は言い過ぎだと思いますが、ページ数も控え目で、サクッと読める良い本でした。

・・・というわけで、個人的な備忘録に加えて、自分の意見も織り交ぜつつ、受託開発について書いていきます。

目次

なぜ受託開発は嫌われるのか?

本書では、以下のような理由が挙げられています。

  • やらされている感
  • 顧客に振り回されている感
  • 自分の仕事が何の役に立っているのかわからない感

これらの原因は、受託開発が「受け身」という側面を持っていることが問題です。受託開発だから、下請けだから、お客様の言うことだから。こういった受け身の姿勢が、受託開発の失敗や、モチベーションの低下を招くのです。

受託開発を楽しむには

まず、受け身の姿勢を変える必要があります。人に振り回されて失敗するくらいであれば、こちらから攻めるのです。

  • 積極的に顧客からヒアリングをして、要件を引き出す
  • 顧客がITの専門知識に詳しいことは稀なので、要件定義を上手くサポートする
  • プロジェクトに積極的に関わることで、顧客からの信頼や満足を勝ち取る

顧客は受注者と発注者の関係ではなく、一緒にサービスを作り上げていくためのパートナーなのです。サービスを中心に物事を考えれば、開発しているプロジェクトに対しても愛着が湧いてきませんか?

受託開発では、既に顧客がいるというメリットを活かして、顧客を振り回すくらいの勢いで行きましょう。

なぜお客様に関心が持てないのか?

受託開発において、メンバーがやらされている感を抱くの理由の一つに、お客様の顔が見えないということが挙げられます。会議の議事録や、送られてきた仕様だけを見ても、そこに人はいないのです。

一番の解決方法は、やはりフェイス・トゥ・フェイスです。議事録役として、顧客との会議にメンバーを参加させる。もしくは、○○機能の開発担当として同席させる。手段は何でも構いません。

とにかく、使っている相手の顔が見えることが重要です。そうすることによって、どうしてもシステム目線で見がちなエンジニアに、顧客目線という視点が生まれてきます。

本来、システムを使うのは顧客なわけですから、顧客目線で見つめる事は当然なわけですが。受託開発だと、これがなかなか難しいのです。

f:id:konosumi:20180731030432j:plain

顧客が納得するための見積もり

見積もりにおいて、以下のようなことが重要点として挙げられます。

  • 見積もるための十分な情報を引き出す(もらえる)こと
  • 見積もりの根拠に納得感を与えること
  • ただ見積もるだけでなく、工数を抑えたり、価格を抑えるためのプラスアルファの提案(代替え案)が提示できること

見積もるための情報を引き出す

見積もりの正確性を高めるためのコツは、何と言っても情報量です。シャーロック・ホームズは、作中において「情報量が足りない間は推理しない」のような旨を語っていたと記憶していますが、私もそう思います。

そのためには、お客様からヒアリングをし、システムで実現したいことの要件を固めていきます。これの繰り返しです。

見積もりに向けたヒアリングのゴールは、例えば一般的なWebシステムであれば、必要な画面や帳票といった「モノ」を集めていくことです。見積もりには、対象物となるモノが必要です。

モノが出揃えば、後は画面毎に機能を検討しながら、見積もりへと進むことができます。

見積もりの根拠を高める

見積もりの根拠を高めるコツは、数値で計算できることです。なんとなくで弾き出した数値ではいけません。ユースケースポイント法、ファンクションポイント法、タスク分解法・・・といった方法論が、本書では列挙されています。

一定の方針に沿って算出された見積もりであれば、そこに自然と根拠が生まれます。

また、過去のプロジェクト実績があれば、大いに活用しましょう。見積もりの妥当性を検討する場合、やはり過去の実績は大きな基準となります。

要件定義

本書に、以下の興味深い一文が書いてありました。大きな要因は「要件の分析不足」と「ヒアリング不足」です。

要件は変わったのではなく、間違って定義されてしまっていることが多いのです

プログラマの仕事は問題解決である

開発者は、ただプログラミングの能力が高いだけでは不十分です。ここでは、お客様と一緒に(お客様視点で)物事を考えながら、整理していく問題解決能力が重要になってきます。

Ruby開発者で有名なMatz氏も、同様のことを述べているわけですから、意識しておいて損はありません。

プログラマの仕事は問題解決

引用:Matz氏講演会「学生エンジニアの生存戦略」 - Qiita

要件の変更は、後の工程になるほど影響が大きくなります。問題に気づくタイミングは、早ければ早いほど良いです。

目に見えない要件にも気をつける

システムの要件は、画面や帳票のような、何も目に見えるものだけとは限りません。

  • 信頼性要件: 復旧に要する時間や、システムの稼働率、など
  • 効率性要件: 3秒以内に応答は返す必要がある、などの性能面
  • 使用性要件: デザインの決まり事や方針、ガイドライン、など
  • 保守性要件: ソフトウェアの今後の変更や、修正のしやすさ、など
  • 移植性要件: 他のOSでも動作する必要がある、など

私は初めて知りましたが、これらの品質要件は「JIS X0129・ISO/IEC 926」として、国際規格にまとめられているらしいです。

f:id:konosumi:20180731031445j:plain

設計・実装・テスト

変更に強い設計を重視する

設計とは、定義された要件を満たすための実現手段を検討し、品質を作り込む作業です。

ここで、重要なことは、後の変更に強い設計(=保守性が高い)にすることです。なぜ変更に強いことが重要かといいますと、簡単に言ってしまえば、後々の修正や仕様変更に強くなるからです。

例えば、モジュール同士が疎結合になっている設計であれば、他の変更が他に影響する、いわゆるデグレのような問題は少なくなります。

テストコードを活用した実装

変更に強くなるためには、変更によって生じるバグ(デグレ)を、早期に検知できる仕組みづくりが必要になります。そこで登場するのが、「テスト駆動」や「テストコード」といった考え方です。

本書には、ほとんどの問題は単体テストで発見できると書いてあります。個々のモジュールの段階で、潰せるバグは潰しておきましょう。

テスト計画による品質の画一化

テストを実施するにしても、統一した基準がなければ、メンバーによって品質はバラバラになってしまいます。品質を保証するためには、予め「どういうポイントで、どこま細かくテストするのか」を策定しておきましょう。

出来れば、テスト基準はお客様とも合意しておくことが望ましいです。

ドキュメントは運用のためにある

ドキュメントはメンテナンスされないとはよく言いますが、ドキュメントは何のためにあるかって、納品するためではなく、運用するためにあるのです。

たとえ、ドキュメントが納品物ではなかったとしても、運用フェーズにおいてドキュメントがあるとないでは、大きく変わってきます。何せ、人は読んだ本の内容を、1週間後には90%も忘れてしまうような生き物なのです。

ソースコードのコメントでも良いので、とにかくドキュメントは積極的に残しましょう。また、適切にメンテナンスされるドキュメントを維持するための、仕組みづくりも重要になってきます。

進捗は細かくブレークダウンする

進捗管理は、全体進捗のような大枠ではなく、細かいタスクレベルで管理するようにしましょう。

私見では、最近はタスクは長くても1日以内に終わるように細分化するといった取り組みが、流行っているように見受けられます。細かくすればするほど、進捗は正確性を増していくのです。

タスクの粒度が大きいと「このタスク、進捗がずっと90%だけど?」といった事態が発生します。あるあるです。私も経験があります。

プロジェクトの成功を掴むためには、まずは自分から変わろう

多くの人が、自分は変わりたいと思っています。特に、IT業界は優れたエンジニアが際立って目立つような世界です。「私もああなりたい」と思うことは、往々にしてあります。

KIML(Know,Imagine,Move,Love)サイクル

これは著者が考案した用語だと思うのですが、KIMLが興味深かったので紹介します。

  • Know: 今の自分を知る
  • Imagine: 変わったあとの姿を思い描く
  • Move: 行動する
  • Love: 変われた自分を好きになる

私なりに要約するならば、まずは現状を分析し、改善後の理想形を思い描きます。次に現状と理想のギャップを埋めるために行動します。行動した自分は、素直に褒めてあげましょう。

これは、確か7つの習慣にも書いてあったと記憶していますが、人はすぐには変わりません。まずは、自分から変わるしかないのです。自分が変われば、それに影響を受けた周りにも変化が生まれてきます。

仲間を増やそう

プログラミングは、結局は個々の作業にまで落とし込まれることが多いです。プログラマーが孤独を感じやすい理由はそこにあるのですが、何も一人で全てを頑張る必要はありません。

開発を楽しむには、仲間を作りましょう。社内で勉強会を開催しても良いですし、試しにペアプログラミングをやってみるのも面白いです。

さいごに

本書を読んだ感想として、受託開発を成功に導くコツは「顧客やメンバーをはじめとして、プロジェクトに関わる人たちを、如何に巻き込むかが重要である」と感じました。

こうやって考えてみると、受託開発も自社開発も、求められる素養はそこまで変わりないのです。もちろん、ビジネス上のメリットで言えば、受託開発では自社開発と違って、入金額の見通しが立ちやすいなどの違いがあります。

かのアジャイルサムライに「アジャイルな顧客」という一文がありますが、本書が求めていることは、それと似ています。主体的に顧客(や元請け)が関わってくれるような関係を築き上げることこそ、受託開発の極意なのではないでしょうか?

補足

本記事に書いてある内容には、私見が大いに含まれています。そのため、興味を持たれた方は、ぜひとも原著を読まれることをオススメします。

少ないページ数ではありますが、ノウハウが凝縮された良書です。

Habiticaによるゲーム感覚のTODO管理と習慣化の維持

「Habitica - Gamify Your Life」は、RPGの主人公を育てるようなゲーム感覚で、TODO管理と習慣化の維持を目指すサービスです。

habitica.com

さらにOSSなので、GitHubにソースコードも公開されてます。気になったので試してみました。

まず最初にキャラクターを作る

Habiticaではじめにやることは、キャラクター制作です。RPGでいう主人公のキャラクターメイキングです。

なお、最初の段階ではパーツも少ないのですが、ゲームを進めていくと増えていくみたいです。そして、キャラクターに名前を付けたらゲームスタートです。

初期画面

Habiticaの初期画面です。大きく分けて「習慣」「日課」「To-Do」「ごほうび」があります。

f:id:konosumi:20190122233448p:plain

習慣

習慣として定着させたいことを入力します。

f:id:konosumi:20190122234111p:plain

良い行ないをしたら「+」をクリックします。ゴールドや経験を獲得します。

f:id:konosumi:20190122234055p:plain

悪い行ないをしなら「-」をクリックします。体力が減ります。

f:id:konosumi:20190122234215p:plain

たとえば飲み会であれば、飲みすぎなければ良い習慣となり、飲みすぎたら悪い習慣になります。自分の分身であるキャラクターがダメージを受けるので、悪い行ないは控えましょう。

日課

表題は日課となっていますが、曜日や繰り返し頻度が選べます。使い勝手の感覚は、Googleカレンダーの定期スケジュールと似ていました。

f:id:konosumi:20190122234503p:plain

日課をチェックすると灰色に変わり、プレイヤーは経験値・ゴールド・マナ、落とし物のチャンスを得ます。つまり、日課をこなすほど主人公が成長します。

To-Do

To-Doは「タイトル」「メモ」「チェックリスト」「難易度」「期限」「タグ」が設定できます。高機能ではないですが、及第点の内容です。

f:id:konosumi:20190122234923p:plain

To-Doも他と同じく、達成すると経験やゴールドを得られます。

ごほうび

ゴールドを消費して、ごほうびを得ることができます。主人公の装備品であったり、自分でごほうびを作成することも可能です。

f:id:konosumi:20190122235258p:plain

習慣やTo-Doをこなすことでゴールドを得て、それを消費することでごほうびを得るというライフサイクルです。

ソーシャル機能

パーティーを組んだり、ギルドに所属するなどといった、Habiticaユーザーが連携するソーシャル機能があります。

ただし、ギルドやキャンプ上でのやりとりはほとんど英語なので、私はまだ所属できておりません。

ペットを飼う

私はまだ始めたばかりでレベルが低いため、アンロックできてないのですが。レベル3を超えるとペットが飼えるようになります。

たまごを手に入れて、ペットをたまごがえしの薬でかえして、えさを与えて・・・という流れです。

クラス・システム

初期状態では戦士ですが、レベルが10を超えると、ジョブチェンジのシステムが解放されます。「戦士」「魔道士」「治療師」「盗賊」になれます。

f:id:konosumi:20190123001217p:plain

習慣化の維持とは?

色々と検索をして調べてみたのですが、Habiticaは人生をRPGのようにタスク管理することで、レベルアップするためのツールみたいです。

たとえば習慣であれば、普通に習慣を達成しても何も反応がなければ、モチベーションが保ちづらいです。そこで、Habiticaは主人公の成長やごほうびといった要素を加えることで、習慣の継続を目指してします。

習慣の例は色々あるみたいですが、一例を上げると以下のような習慣です。

  • 健康:早起きする
  • 家事:食後は必ず皿を洗う
  • 勉強:宿題を1つやる

Habiticaユーザー

人生fmのきりみんさんは、Habiticaユーザーです。普通に生活しているだけで達成感を得る事ができるという感想は、確かにその通りかもしれません。

自然に習慣をこなしているだけで、経験やゴールドが貯まっていきキャラクターが豊かになっていくので、ポジティブな反応が得られます。

kirimin.hatenablog.com

HabiticaはOSS

ITエンジニア的におもしろい点で言えば、HabiticaはOSSとしてソースコードが公開されています。Web版に加えて、iOSとAndroidのモバイルアプリ版もあります。

github.com

さいごに

自分で難易度が調整できてしまう側面があるので、最終的には自分自身の継続力に委ねられる点があります。ただ、ゲーム要素を取り入れるというアイデアは、とてもおもしろいです。

習慣を根付かせたいと考えている人であれば、試してみてはいかがでしょうか?

habitica.com

ワンストップ見積もり本で、プロジェクト見積もりの勉強を始めよう - おやかた.amに寄せて

昨日徹夜をしまして、ワンストップ見積もり本の原稿を書き上げました。

note.mu

ワンストップ見積もり本は、C95(2018冬コミ)の親方Projectにて頒布される予定の技術同人誌です。「おやかた.am」という技術同人誌を紹介するポッドキャストと、私が技術書典で頒布した、エンジニアアンチパターンのコラボによって誕生しました。

anchor.fm

誕生のきっかけは、ぜひともポッドキャストを聞いていただければと思います。ワンストップ見積もり本は、見積もりについてひたすら言及する、稀有な本です。10名以上の著者によって執筆される予定です。

宣伝も兼ねまして、見積もりについて少し語っていきたいと思います。

見積もりの難しさ

エンジニアアンチパターンには、「過小見積もりで炎上するプロジェクト」という、見積もりに失敗した話があります。

booth.pm

「おやかた.am」を聞いていて感じたことは、やはり見積もりは難しいということです。IT業界には、徹夜や帰れないといったイメージが、どうしても付きまといます。それらは大抵、無茶な見積もりや仕様変更、想定外の作業による工数の膨らみなどによって、引き起こされます。

  • 予算が足りないので、増員できません。残業でカバーしましょう
  • 納期はずらせませんが、機能は削れませんし、品質も妥協できません
  • ...etc

炎上しうるプロジェクトでは、さまざまな悲劇が起こります。兎にも角にも、プロジェクトは炎上すると辛い目に合います。見積もりは、慎重にやる必要があります。

そこで、見積もりに関する経験、知恵や知識を結集しようという想いで誕生したのが、「ワンストップ見積もり本」です。

SHIROBAKOで感じる、見積もったスケジュールを守ることの難しさ

プロジェクトの炎上はどのようなものかと申しますと、アニメのSHIROBAKOを見てもらうと分かりやすいです。

f:id:konosumi:20181124141034j:plain

「SHIROBAKO」で描かれるのは、アニメ制作の現場です。主人公である宮森あおい(みゃーもり)は、制作進行というポジションのため、スケジュールを管理しています。

アニメ制作には「監督」「原画」「アニメーター」「CGクリエイター」「サウンド」をはじめ、さまざまな役割の人たちが関わっています。そこで、それぞれのスケジュールを調整するために制作進行というポジションが必要です。

しかしながら、このスケジュール管理はとても難儀です。さまざまな要因によって、オンスケから少しずつスケジュールが遅延します。

  • 監督がいつまでも絵コンテに迷っている
  • 制作陣の仲違いが発生して、チームがバラバラになってしまった
  • 少しずつスケジュールが遅れていき、ついには当日ギリギリ納品になってしまう

アニメの制作が間に合わなくても、アニメは枠がありますので放映されます。その場合、すでにできあがっている話を結集した、総集編などが放映されます。実際に、そのような事態に陥ってしまったアニメも、世の中にはいくつもあるそうです。

見積もりを守るためのチームワークとチームビルディング

ワンストップ見積もり本は、主に見積もりを対象とした本です。但し実際には、アニメの「SHIROBAKO」で描かれているように、見積もりその後の制作進行もとても重要です。

見積もった内容をオンスケで進めていくためには「プロジェクトをリードする技術」も大事になってきます。

kakakakakku.hatenablog.com

せっかく見積もりが上手くできたとしても、守れなければ意味がありません。そこで、プロジェクトを開始する段階での見積もり力と、その後のプロジェクトリードの技術が両方とも必要になってくるのです。

さいごに

C95(2018冬コミ)の親方Projectで頒布されるワンストップ見積もり本は、ひたすら見積もりについて語る稀有な技術同人誌です。

どんなにプロジェクトリードが上手かったとしても、最初の見積もりに失敗してしまっては、プロジェクトは炎上します。プロジェクト運営で重要なことは「適正な見積もり」と「プロジェクト進行(リード)」です。

見積もりは大変な作業ですが、その後のプロジェクト進行を左右する重要な工程です。ぜひとも、ワンストップ見積もり本で見積もりの勉強を始めてみませんか?

私も執筆に参加しまして「過⼩⾒積もりで炎上するプロジェクトから得られた学びと実践」という章を執筆させていただきました!

note.mu

MicroSoft To-Doによるプライベートのタスク管理

こんにちは。私のプライベートのタスク管理は、Trello、Todoistと試してきたのですが、「MicroSoft To-Do」についても試してみました。

プライベートをTrelloでタスク管理する - このすみろぐ

Todoistによるプライベート(個人)のタスク管理を始めてみた - このすみろぐ

利用イメージは以下のような感じでして、タスクが完了したらチェックを付けるという、いわゆるスタンダードなTo-Do管理になっています。

f:id:konosumi:20180503142019p:plain

それでは、個々の機能について詳しく書いていきます。

MicroSoft To-Doとは?

「MicroSoft To-Do」は、Wunderlistというタスク管理ツールが元になっています。それをMicroSoftが買収したことで「MicroSoft To-Do」として生まれ変わりました。

Wunderlistのここがすごい!山ほどあるタスク管理アプリの中からWunderlistをオススメしたい6つの理由 – OTTAN.XYZ

Wunderlistにかわるマイクロソフト「To Do」が提供開始 | Lifehacking.jp

位置付けとしては、MicroSoftオフィスシリーズの中の一つであると言っても過言ではありません(注釈:厳密に言うと違います)。

To Do リスト アプリ - Microsoft To-Do

利用料金は無料で、MicroSoftアカウントがあれば、すぐに利用を開始することができます。私は既にMciroSoftアカウントを持っていたので、アカウント登録が不要なのはとても楽でした。

MicroSoft To-Doの使用感

「MicroSoft To-Do」を使ってみた感想としては、とにかくシンプルで、動作がサクサクで、操作は直感的です。

f:id:konosumi:20180503110422p:plain

ここからは、細かい解説をしていきます。

リスト

左ナビに表示されているのは「リスト」です。リストは、タスク(To-Do)をカテゴリ分けするための機能です。

私の場合は「プライベート用のタスク一覧」「ブログ用のタスク一覧」「同人サークル用のタスク一覧」といった具合にリスト分けをしています。

f:id:konosumi:20180503110745p:plain

先にリストを作ってしまい、リストページでタスクを追加しても良いですし、各タスクはドラッグアンドドロップで、リスト間を移動させる事も可能です。

タスクの追加

タスクの追加は「+ To Do の追加」をクリックして、タスク名を入れてEnterを押すだけです。

細かく編集したい場合は、タスクをダブルクリックします。

f:id:konosumi:20180503111121p:plain

私の1日

「MicroSoft To-Do」は、溜まったタスクの中から、今日やるタスクを選んで私の1日に追加するというUIになっています。

f:id:konosumi:20180503111301p:plain

「私の1日」に追加すると、今日の予定リストにタスクが追加されます。

通知

通知によって「To Do」をやり忘れないようにリマインダを送信する事ができます。アプリ版を利用していれば、プッシュ通知として届きます。

ブラウザ通知でも使えますが、アプリ版での利用がメインとなるでしょう。

f:id:konosumi:20180503111713p:plain

期限と繰り返し

タスクには、期限と繰り返しを設定することができます。

f:id:konosumi:20180503112012p:plain

繰り返しを設定した場合は、タスクを完了すると、例えば「毎日」であれば「翌日」のタスクが自動的に作成されます。

メモ

メモは、いわゆるタスクの概要を入れます。Trelloなどと違い、コメントを何件も残すといったことは出来ません。あくまで、タスクの備考欄という位置付けになります。

ステップ

タスクには、ステップを追加することができます。いわゆるチェックリストのようなものです。

f:id:konosumi:20180503112506p:plain

例えば、引っ越しというタスクであれば「引越し業者に見積もりを依頼する」「引越し業者を選定する」「荷造りをする」・・・といったステップが必要になります。技術書を読むようなタスクであれば、章ごとにステップを設けるのも良いかもしれません。

さいごに

機能としては、そこまで凄い機能があるというわけではなく、単純な機能面で見ると、TrelloやTodoistの方が優れています。

ただ、Web版とアプリ版は備わっていて、操作はとても直感的であり、動作もサクサクです。高度なタスク管理をしようと思わないのであれば、とても快適なツールです。

MicroSoftアカウントをお持ちでしたら、アカウント登録も不要です。ぜひ試してみてはいかがでしょうか?

Welcome to Microsoft To-Do

補足:明日の風は明日吹く

やりたいタスクを積んでいって、その中から今日やるタスクをピックアップして消化していくUIが、意外に気に入りました。「明日の風は明日吹く」スタイルで、明日のことは「今日の夜」か「明日の朝」に考えれば良いんです。

プライベートでは綿密なタスク管理はしたくないので、私にはこれくらいが丁度良いと感じました。

Todoistによるプライベート(個人)のタスク管理を始めてみた

こんにちは。私は今まで、タスク管理はTrelloを使ってきました。

www.konosumi.net

Trelloには満足しているのですが、ただ、最近一つ思うことがありまして、Trelloはタスク管理で言うとトヨタのカンバン方式なのです。

プライベートの細かいレベルのタスクを管理するとなりますと、全体を見通すよりも、今日何するといった情報が重要になります。そこで、より普通のタスク管理に近いTodoistも使ってみようと思ってみた次第です。

「エッジのたたないポッドキャスト」や「Rebuild.fm」のポッドキャストでも、Todoistの話題がありましたしね。

noedge.matchy.net

rebuild.fm

試しに使い始めているので、所感を書いていきます。

次の7日間という機能が非常に便利

Todoistは、日付で区切ることを重視したタスク管理ツールです。「今日は何をする、明日は何をする」を整理することに特化しています。

f:id:konosumi:20180427182954p:plain

特に「次の7日間」機能の使い勝手が非常に良いため、週ベースでのやること整理が非常にやりやすいです。

当然ですが、直近7日間だけではなく、翌月や翌々月のタスクを登録することもできます。無料版では使えないのですが、リマインダー機能を活用すれば、タスクを忘れないようにすることも可能です。

日付以外のタスク整理

Todoistでは、主に以下の分類でタスクを整理することができます。

プロジェクト

私の場合は、ブログ活動のためのプロジェクト、同人活動のためのプロジェクト、技術活動(技術力の強化等)のためのプロジェクト、といった具合に分けています。

他にも、趣味プロジェクトであったりとか、●●資格の取得プロジェクトなど、もちろん自由に追加することが可能です。

ラベル

プレミアム版の機能のため使えていないのですが、@メール、@保留、@15分のように、タスクに補足情報を追加するために使用するみたいです。

@(アットマーク)を付けるだけで補足情報を追加することが出来るので、お手軽ですね。Twitterのハッシュタグのような使い勝手と似ているかもしれません。

参考:https://support.todoist.com/hc/ja/articles/205195042

優先度

タスクに優先度を付けることができます。優先度は4段階でして、1〜4までを付けることができます。

f:id:konosumi:20180427184553p:plain

繰り返しタスクの登録が楽である

Todoistを使うと、毎日やる必要がある定型タスクを、簡単にタスク化することができます。予定に「毎日、毎週、毎月」と入れるだけです。お手軽ですね。

f:id:konosumi:20180427185643p:plain

繰り返しタスクは、今日のタスクを完了した時点で、(毎日の場合は)明日のタスクが自動的に作成されます。

使い勝手がとても良いため、これはTodoistで一番の機能だと思います。

カルマというモチベーションを高めるポイント機能

タスクを完了すると、カルマが上がります。カルマは、生産性を表すポイントのようなものです。

f:id:konosumi:20180427193121p:plain

私はそこまでではないのですが、人によってはカルマが積み上がっていくのが楽しくて、それがモチベーションを向上させます。

さいごに

Todoistを使ってみた印象としては、とても素直でシンプルなタスク管理であると感じました。Trelloは全体を俯瞰して見通すことに向いている一方で、Todoistはタスクを管理することに特化しています。

もし抱えているタスク数が少ないのであれば、Googleカレンダーにスケジュールを入れるだけでも十分かもしれませんが、タスク整理や繰り返しタスクの管理がやりやすいので、Todoistはおすすめです。

ラベルが使えなかったりと、プレミアム限定の機能も多いのですが、無料版でも十分管理はできそうです。しばらくの間は、Todoistでタスク管理をしてみようと思います。

認定スクラムマスター研修を受けて、認定スクラムマスターになるまでの感想と知見を共有する

Scrum Alliance(スクラムアライアンス)の認定を受けて、認定スクラムマスターになりました。

f:id:konosumi:20180324160954p:plain

認定スクラムマスター研修は、参加費用もそれなりである代わりに、内容も非常に濃い研修でした。忘れてしまう前に、内容をまとめていきます。

研修の進め方

認定スクラムマスター研修の進め方は、団体や年度によって異なります。「一律的にこれだ!」という決まりが、決まっているわけではありません。

逆に言えば、研修の内容は毎年ブラッシュアップされていくわけです。

私の場合は、唯一の日本人の認定スクラムトレーナー(CST)である江端一将氏が講師を勤め、課題を解いていく過程で知見を得ていく、実戦スタイルでの研修でした。

スクラムを知っている事は前提

研修といっても、スクラムについてゼロから学習していくわけではありません。予め、スクラムについて予習(もしくは実践)していることが前提となります。

そして、スクラムについての予習は絶対にしておいた方が良いです。

  • デイリースクラムとはどのような目的で開催されるのでしょうか?
  • スクラムでは「透明性」「検査」「適応」が3つの重要な柱になります。あなたは知っていましたか?

講義スタイルで進めるわけではなく、実戦スタイルでの研修になります。既に得ているスクラム知識を、補足したり実践するような場所であることを心掛けましょう。

研修は大変、でも実践はもっと大変

研修の間は、ずっと頭をフル回転し続けるような3日間になります。初日は疲れ果ててしまって、研修が終わった後はずっとお酒を飲んでました(笑)。

つらい側面もありますし、大変な研修でもありますが、合理性や論理性をとにかく追求し、チームを正しい方向に導いてくための3日間でした。

研修は「研修よりも、実務はもっと大変です」という一言で締めくくられます。

私も、それはその通りだと感じました。実務では、不足の事態がもっとたくさん発生します。スクラムマスターは、スクラムの奴隷であってもならず、臨機応変に対応できる必要があります。

研修を経て、自分が不得意とする点も見えてきたので、そこは復習しつつ頑張っていきたいと思います。

アジャイルサムライとカイゼンジャーニーで予習する

私は、過去に「アジャイルサムライ」や「スクラム実践入門」を読んでいたのですが、それぞれ研修でも役に立ったように感じます。

www.konosumi.net

今であれば、カイゼンジャーニーを組み合わせてスクラムを学習されるのも良いかもしれません。

  • アジャイルサムライで、アジャイルについて知る(知識編)
  • カイゼンジャーニーで、スクラムの実践的なプラクティスについて知る(実践編)
  • スクラム実践入門で、他社のスクラム事例について知ってみる(事例編)

カイゼンジャーニーは読み物としての側面もあって、純粋に読んでいて面白いです。数時間あれば読めますので、一読されることをオススメしますよ!

(注釈:カイゼンジャーニーはエンジニアの間で話題の書で、私も読みました)

カイゼン・ジャーニー たった1人からはじめて、「越境」するチームをつくるまで

カイゼン・ジャーニー たった1人からはじめて、「越境」するチームをつくるまで

さいごに

研修で得た教訓や課題を整理して、実際のスクラム開発を円滑に進めるよう、頑張っていきたいです。カイゼンジャーニーじゃないですが、最初から円満にスクラムがまわるプロジェクトの方が少ないであろうことは、想像に難くありません。

ベースとなる知識があって、それを臨機応変に組み合わせて行けるスクラムマスター(スクラムチーム)は、やっぱり強いです。

・・・でも、「知識」「行動」「マインドセット」が伴ってこそスクラムマスターなのですが、私の場合は行動とマインドセットが鍵でした。

「より良いプロダクトや、スクラムチーム(チームメンバー)のために、スクラムマスターとして頑張ろう!」

そう強く思えるマインドセットこそ、スクラム開発の第一歩なのかもしれませんね。

おまけ:オンライン試験と合否について

認定スクラムマスターの合否は、研修が終わってから、後日メールアドレスに合格者のみ通知されるようです。合格者にはオンライン試験の案内があり、私はオンライン試験を受けました。

  • 制限時間はなく、じっくりと腰を据えて受験することができます。
  • オンライン試験のため、受験場所に決まりはありません。

オンライン試験では「スクラムについての知識」に加えて「こういう局面において、スクラムマスターのあなたはどう行動しますか?」といった実践的な問題も出題されます。

じっくり考えていけば、答えにたどり着ける問題ではあったので、集中できる場所で落ち着いて受験されることをオススメ致します。合格すると、無事に認定証が発行されます。

ちなみに、認定スクラムマスターの合格率は、他の参加者に聞いてみたところ55%程度らしいです。ただ、試験の内容は毎年アップデートされますし、参加者のレベルによってもマチマチでですので、一概には言えません。

生産性を下げないことが重要 - 夢とコーヒーと私(omoiyari.fm ep27)

omoiyari.fmの最新回(ep27)を聴きました。

lean-agile.fm

配信自体は久しぶりなのですが、実は「engineer meeting podcast」も聴いているので、あまり久しぶりな感覚はなかったりします。

www.konosumi.net

主に生産性について話している回です。感想を綴っていきます。

生産性の記事を読んでいる間は生産的じゃない

私はタスク管理に興味があって、生産性やプロダクティビティの話は好きなほうです。プライベートもタスク管理をしていて、その件は過去にブログで書いています。

www.konosumi.net

生産性の話はかなり面白かったです。「生産性の記事を読んでいる間は生産的じゃない」は、まさに名言だと思います。

なぜ名言だと思ったかと申しますと、生産性やプロダクティビティの上げ方は人によって様々なので、あまり参考にならないことが多いのです。

blog.tinect.jp

私の意見としては、生産性を上げる方法よりも、生産性を下げない方法のほうが議論する価値があると思ってます。

ただ生産性をあげたいのであれば、一心不乱に頑張れば良いのです。しかしながら、世の中には様々な進捗の阻害要因があります。「長時間の会議によって進捗が進まない」は有名な話ですが、細かい例だってたくさんあります。

例えば、私は以前に英語学習をパソコンで聴きながらやっていたのですが、それは辞めて、iPodで勉強することにしました。パソコンだと、休憩と称してネットサーフィンばかりやってしまうからです。インターネットに繋げていないiPodであれば、英語を聴く以外にできることはありません。

私の意見としては「生産性は低いと思ったら対策を考えるくらいが丁度良いのかなぁ」と、感じております。

余談ですが、生産性の記事を読んでいる間は生産的じゃないという話は「勉強会に行く時間があったら勉強しろ」という側面に似ていますね(苦笑)。

「うーん、勉強会に出るヒマがあるなら勉強しろって思います」
引用:https://codeiq.jp/magazine/2016/06/42239/

勉強会という言い方にも問題がある気がしていて、勉強会は勉強しに行くのではなく、新しい技術のトレンドを知ったり、交流を目的とする人もいると思います。どのような目的を持って参加するのかにもよりますので、一概には言えないですけどね。

コーヒーの話

私の場合、通勤時間は缶コーヒーを飲みながらポッドキャストを聴くのがほぼ日課です。

スーパーで安い缶コーヒーを買い込もうといつも決意するのに、つい駅の自販機で買ってしまいます。ぐぬぬ、節約しなければ。

会社でもバリスタで入れたブレンドコーヒーを、ほぼ毎日飲んでいます。現状、コーヒーなしの生活が考えられないくらいには、コーヒーにハマっている気がします。

コーヒーを飲んでいる時の、一息つく感じのリラックス感が好きなんですよね。

f:id:konosumi:20171229030419j:plain

夢の話

私も、夢が明確な人には憧れます。改めて「夢は何だろう?」と自問自答してみると、なかなかに迷いますね。

このブログがもっと流行って欲しいとか、早く中間管理職というポジションから脱出したいとか、細かい目標はたくさんありますが、夢と言えるほど壮大ではないです(滝汗)。

子供の頃は電車の運転士になるのが夢だったのですが、完全に夢の彼方に消えて、今は普通にITエンジニアをやっています。

「夢を忘れた大人たち」で、歌詞が書けそうな気がしてきましたよ(苦笑)。

さいごに

新しい機材ですが、音質もクリアで良さげでした。積みゲストにも期待しております!

全く関係ないのですが、私も数年愛用していたイヤホンが断線しまして、つい先日から新しいイヤホンで聴いております。

ただ、ポッドキャストの視聴がメインですと音質にこだわる意味もあまりないため、普通のイヤホンですけどね。

プロダクトマネージャーとプロジェクトマネージャーの違い(engineer meeting podcast vol103)

みなさんは、プロダクトマネージャーという職種をご存じでしょうか?

最近では、プロダクトマネージャーカンファレンスといったイベントも開催されており、プロダクトマネージャーの知名度も向上してきました。

2017.pmconf.jp

一方で、IT業界では昔からプロジェクトマネージャーという職種があります。プロジェクトマネージャーは、情報処理技術者試験にも存在し歴史のある職種です。

www.jitec.ipa.go.jp

実は私も、過去にプロジェクトマネージャ試験を受けたことがあります。

さて、このプロダクトマネージャーとプロジェクトマネージャーなのですが、響きが似ているため大変ややこしいのです。何せ、両方とも略すと「プロマネ」ないし「PM」になります。

私も混乱しているので、ここで整理していきます。

違いをざっと整理する

非常にざっくり整理すると、以下のような特性があります。

プロダクトマネージャー プロジェクトマネージャー
自社開発向け 受託開発向け
プロダクトに責任を持つ プロジェクトに責任を持つ
プロダクトを成功させる プロジェクトを成功させる

これだけだと誤解を生むかもしれませんので、それぞれ解説していきます。

f:id:konosumi:20171208005906j:plain

プロジェクトに責任を持つプロジェクトマネージャー

プロジェクトマネージャーは、QCDを守ってプロジェクトを成功させることが目的になります。具体的には、以下の指標が重要です。

  • Quality(品質)
  • Cost(費用)
  • Delivery(納期)

つまり、開発費用を予算内に納め、期日までに開発し、品質の良いプロダクトをリリースすることが目標になります。

仕様が確定しているような受託開発では、プロジェクトマネージャーが活躍します。何故かと言うと、受託開発には以下の特性があるからです。

  • 受託開発では貰えるお金が決まっているため、費用を超過すれば赤字になってしまいます。
  • 納期や品質を守らないと、会社としての信用を失うどころか、最悪訴訟問題に発展する可能性もあります。

プロダクトに責任を持つプロジェクトマネージャー

プロダクトマネージャーは、プロダクトを管理します。具体的には、プロダクトをより良いモノに改善し、売れるプロダクトを目指すことが目的になります。

ビジネススキルは当然必要ですが、商品を売るためのマーケティングスキル、より良いユーザー体験を提供するためのUI/UXスキル、デジタルサービスであれば、基本的なテクノロジー知識も必要になってきます。

もちろん、プロジェクト内にマーケティング担当者や、UI/UXデザイナー、エンジニアがいることも多いのですが、彼らと会話しながらプロダクトを成功させるためには、幅広い知識が必要になってきます。

しかし、現実問題そんなに幅広い知識を持ったスーパースターみたいな人は、世の中にそうそう居ないと思います。結局のところ、うまくチームをマネージメントしながら、トータルで力を発揮してプロダクトを成功に導くことが使命になります。

マネージメントスキルは、当然ですがプロジェクトマネージャーでも必要です。だからこそ、どちらも○○マネージャーという職種なのです。

スタートアップや自社プロダクトの開発では、プロダクトマネージャーの手腕が試されます。プロダクトが生命線であり、最も重要であるからです。

さいごに

ざっくりとまとめてみましたが、私はプロダクトマネージャーとはミニCEOであると思っています。

会社の利益をあげることがCEOの役割ならば、プロダクトで利益をあげることがプロダクトマネージャーの役割です。そのためには、プロダクトを実際に使っているユーザーの声を聞いたり、UXを改善して顧客満足度をあげたりと、色々なことにチャンレジする必要があります。

正直に申し上げますと、プロダクトマネージャーというのはかなり凄い職種です。

「プロマネはいてもプロダクトマネージャーがいない新規事業の問題点」という記事がありますが、それはある種必然です。プロダクトマネージャーは要求レベルが高いので、簡単になれるものではありません。

diamond.jp

結局のところ、プロダクトマネージャーは多少未熟であっても、会社が育てていくしかないと思ってます。

ようやく日本でも定着してきた職種です。私も経験を積んで、プロダクトマネージャーになりたいですなぁ。

補足:engineer meeting podcast

本記事を書こうと思った理由は、エンジニアミーティングポッドキャストの「vol.103 プロダクトマネージャー・カンファレンス」を聞いたからです。

音声で聞いただけだと忘れそうなので、備忘録という意味も含めてまとめてみました。本記事は、私なりの見解も多分に含んでおりますので、ぜひオリジナルも聞いてみてください。おすすめです。

engineer-meeting.tumblr.com

soundcloud.com