intellista

engineer's notes about application development, data analysis, and so on

幸せならうまくいく、という考え方

f:id:parupuntist:20210225202619p:plain
ハピネスプラネット代表の矢野氏のオンライン講演を聞きました。
happiness-planet.org

「うまくいっている人が幸せなのではなく、幸せな人がうまくいっている」
ということがデータに基づく研究結果から言えるそうです。
モバイルデバイスと研究データに基づき、幸せを定量化できるといいます。

生産的で幸せな集団には「信頼できる関係がある」という主張を踏まえて、

  • 実験と学習に基づく新しい組織に変わることで、自律的になり、変化へ適応できるようになる
  • 企業は人の心でできており、幸せが業績に直結する

ということでした。
理想としては共感でき、個人としてはつい自然とそういった行動を取ってしまいますが、組織もそう変わっていくといいと思いました。

また、他の講演者の方も含めたキーワードのひとつ「DX」とも関連させていると思います。
「DX」、つまりデジタルデータを利用したビジネスのトランスフォーメーションのことで、お客様の体験を通じた価値を重視し、プロダクトやサービスはその価値を生み出したり最大化するのための手段である、という点が重要だと思っています。

なお、アジャイル開発で良く聞く「心理的安全性」に通じるところがあると思いました。
また、計画よりも方針+やってみて学習、という姿勢も、アジャイルっぽいです。
なので、考え方としては共感できました。

こういう考え方が広まったり、実証されてくると嬉しいと思います。
社会人になった頃とは世の中の雰囲気がどんどん変わり、違和感が年々解消されてきているのも少し嬉しいです。

アイキャッチ画像


はてなブログアイキャッチ画像を簡単に作れるところがとても気に入っています。
この機能は、つい最近実装されたものなのですね。
(確かに、この機能あったっけ?と思いました。)
staff.hatenablog.com

余談ですが、アイキャッチ画像をそのまま英語風に「アイキャッチイメージ」と言うと「I catch image.」(意味は通らない)のように聞こえてしまう恐れがあるようです。
an/the eye-catching image(s)のようになるそうです。
eikaiwa.online

Vuetify


半年ほどVuetifyを使ったSPAをアジャイル開発したことがあります。

Vue.js向けにUIを簡単かつきれいに作るフレームワークです。
当初、Vuetifyは初めて知ったのですが、公式ドキュメントといくつかの情報でスムーズに習得できました。

はじめに、次のサイトで基本を学びました。
1. 基本的なUIを作成する。

2. 上記をベースに、ナビゲーションメニューを階層化する。

その後は、公式サイトのAPIドキュメントなど参照しながら機能追加、という感じです。
公式サイトのAPIドキュメントはサンプルコードがとても豊富で、役立ちました。

1年くらいVue.jsを使った開発経験があったのもよかったのか、2日くらいで一気にモックアップのメニュー付きの画面を作れました。
マテリアルデザインという考え方に基づいており、あまり深く考えなくてもきれいに仕上がるところが良かったです。
IE11には非対応の機能が散見されるので、その点は注意です。

デザイン思考


お昼に「デザイン思考」のセミナーをチェックしました。
ユーザが本当は何をしたがっているのか、ということを、ちゃんとユーザに聞こう、というメッセージを受け取りました。
本当に共感できます。

組織が大きい場合、ユーザとの距離が遠くてなかなか拾えない場合もあります。
この観点はずっと言われていることなので、理論よりもどうやって実施するのか、というところが悩みどころです。

POチーム


昨日、2日目の Developer Summit 2021 もいくつかチェックしました。
アジャイル開発のセッションに「POチーム」なるものが登場し、とても新鮮でした。

「POチーム」の役割はアジャイル開発におけるスクラムチームの「PO」(プロダクト・オーナー)で構成されたチームのようでした。一般的には、「PO」はチームでなく1名とするのが定石で、スクラムガイドの記載がわかりやすいです。
https://www.scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-Japanese.pdf

1名にとする理由には言及がないようなのですが、確か、意思決定のブレを廃したり、スピード感といったものだったと思います。

セッションでは実際にこの体制で進めた事例が紹介されていました。「PO」を敢えてチームにした理由は特に触れていなかったようです。プロジェクトの特性に合わせてうまくカスタマイズしたのかもしれません。または、もともとITが専門でない方々の混成チームのようでしたので、あまり意識されず新しいアイディアがうまく適合した可能性もあると思います。

プロジェクトの特性のひとつに「本体+子会社での開発で、それぞれにそれぞれの立場で意思決定者がいる」という事情があり、これが「PO」をチーム体制にした要因として大きいように見えました。

そして「POチームで週次で意思決定する」という方法で、うまく回せたみたいでした。コミュニケーションを含めたプロジェクト管理が上手だったのだと思います。

ただ「週次」という点については、スプリントが2週間位なのが一般的なので、少し不安に(少ないのではと)思いました。これについては「イテレーションの期間を機能単位で変える」という工夫でうまく回したそうです。こうなると、広義の反復型開発やウォーターフォールとのハイブリットなのかもしれません。実際、現場ではいろんなハイブリットの仕方があるのが現状なので、今後のストックが増えた気がします。

Developer Summit 2021 では、異業種の取り組みや考え方、トレンドをチェックでき、とても有意義でした。

NoCode開発、LowCode開発


昨日、Developer Summit 2021のとある公募講演で、NoCode開発、LowCode開発の潮流を感じました。観光業でシステムやアプリを自社開発している話でした。業務のわかる現場の方々が開発・保守できれば、もう最強だと思います。発表者の方々の真摯で前向きな姿勢にも共感しました。
「kintone」を活用しているそうです。

NoCodeといえば、少し前に「Jimbo」というWebサイト作成サービス(無料プランあり)の本に図書館で出会って試してみたのですが、紹介と予定くらいの機能なら本当に手軽にパパッと作れることを実感しました。

また、子供がしばしばScratchを使っていますが、あれもLowCodeだったんですね。

Firebase


今日、Firebase に関するオンラインのハンズオンに参加しました。
connpass という IT系エンジニアのための勉強会プラットフォームからの参加です。

Firebase単体については今年度、Vue.jsやVuetify.jsを使った開発の調査目的で個人的に簡易利用したことはあったのですが、今回のハンズオンではそのほかの機能 (Cloud Shell, Firestore, Authentication) の入り口も実機で確認でき、本当に為になりました。
こういった研修に、手軽に自宅で隙間時間に参加でき、主催者の方々には本当に感謝です。今回も視野を広げられ、嬉しい気持ちで熟睡できそうです。