サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
ブックレビュー
devtab.jp
2018年お世話になったVue.jsリンク集 これはギルドワークスイベントカレンダー 4日目の記事となります。 2018年に私が関わらせていただいたギルドワークスのプロジェクトでは、フロントのフレームワークにVue.jsを利用する機会が多かったので、そのときに参考にしたリンクなどを書いていこうと思います。 公式ドキュメント 全体像を把握するときや、ソースコードを読んでいて出くわした知らない機能について、調べものをするときに最初に参照しています。 Vuex Vuexアプリケーションの構造 最初、Vuexのフォルダ構成について調べていたときに参考にした資料です。 アプリケーションの構造(公式) Large-scale Vuex application structures igeligel/vuex-simple-structure igeligel/vuex-namespaced-modul
これはギルドワークスイベントカレンダー 3日目の記事となります。 ギルドワークスでは、プロジェクトを開始したときに、多かれ少なかれ、継続的インテグレーションや継続的デリバリの仕組みを組みます。 今日は改めて、なぜそのような仕組みをととのえているのか、整理して見たいと思います。 継続的インテグレーションと継続的デリバリ その前に、改めて用語を整理しておきましょう。 継続的インテグレーション(CI)とは、ソースコードを継続的に結合(Integrate)することです。 JavaやC#などコンパイルを行う言語では、「継続的ビルド」とも言います。ビルドすることそのものが、結合に当たるからですね。 一方、Rubyなどの動的言語では、簡単な単体テストを使って、結合を確認することが多いでしょう。(もちろん、Javaなどでも単体テストを含めることはあります) 継続的デリバリ(CD)とは、CIによって結合され
状況 アジェンダがない会議。 困り事 その会議の目的が果たせない。 果たすまでに余計な時間がかかったりする。 こう考えて、やってみる まず、その会議をやる必要があるか考える。情報を共有するだけであれば集まらなくてもいい。 また決めることが目的なのに、決めることができる人が参加できない場合なども集まっても意味がない。 (「そもそも集まらなくてもいいよね」という観点での確認は終わっている前提) 「この会議の目的は?誰がいればいいんだろう?」というのを考えるために以下のようなアジェンダに沿って考えてみる。 【目的】 この場がなんのためにあるのか? 例:次のイベントのテーマと候補日を決める。 【ゴール】 この場が終わった時にどうなっているのか? 例: ・ 次のイベントのテーマが決まっている。 ・候補日が複数出ている。 【コンテンツ】 ゴールにたどり着くためにやることと所要時間。 例: ・テーマの案
この記事は、ギルドワークス アドベントカレンダーの18日目の記事です。 今回は、「色つき星取表」を紹介します。 「色つき星取表」ってなに? 結城浩さんが紹介されている自分の活動を見える化するやり方の1つです。 最近の自分がどんな活動に力を入れているのかを簡単に把握する方法(「色つき星取表」を使う) - 結城浩のはてな日記 放置プロジェクトをなくすために「色つき星取表」を使ってみよう|結城浩 この「色つき星取表」を1年半近く運用したお話です。 どんな運用をやっているの? 結城さんがブログで紹介されているほぼそのままですが、私は以下のような運用をやっています。 毎日記入する。所要時間は3分かからないくらい 数字は3段階(1〜3)で表現。定量的よりも、自分がどうだったか?的な感覚を大事にしている(時間は別に計測しているので) 1:なんらかの活動をした 2:ちょっとリソースを使って活動した 3:が
ギルドワークスで、フルリモートワークを日常とする仕事の進め方を丸3年行ってきて、分かったことを「原則」という形で、まとめてみました。 リモートワーク (ここでの状況は、ごく一部がリモートワークというよりは大半の人が、もしくは全員がリモートという現場を想定している) で、「同席」と同じような前提で、仕事をしてもうまくいかない、ということは共通理解だと思います、 全員がほぼリモートの環境では、人と人のコミュニケーションは組織イメージとして「階層構造」を前提とするのではなく、 「ネットワーク」 を想定したほうが良いでしょう。 つまり、「リモートワークを上手くやるには」は言い換えると、 「ネットワーク的な集合体で仕事を上手くやるには、どんな条件が必要か?」 ということになります。 以下は、「リモートメンバーがネットワークに参加する際に確認すること」としてまとめてみました。 (ちなみに、「ネットワー
はじめに Photo credit: RUDEWORKS via VisualHunt.com / CC BY 現在MVPアワードを開催中です。毎年50以上の応募をいただき、ほぼすべての事業アイデア・事業解説に目を通している中で、いくつかアンチパターンとなってしまっているものがあります。 この記事では、そんなアンチパターンのうち、よく見るものを紹介します。 参考にすると良い記事や書籍 今回の応募者の皆さんには仮説キャンバスの記載をお勧めしています。仮説キャンバスの基本的な記載方法については、シン・ゴジラの仮説を仮説キャンバスで立てるをご覧ください。 アイデアを磨いていく際の心構えは、千葉工大の安藤昌也教授の安藤研鬼の十則が参考になるかと思います。 馬田さんが書いた逆説のスタートアップ思考も非常に参考になります。 黒田さんのLEAN STARTUPアンチパターンと少し被っているところがありま
ギルドワークスの佐々木です。 ユーザー視点に立つということ 「ユーザー視点に立つ」と言った際に、何が大事なのかについては、様々なことが紹介されています。 私の解釈では、「ユーザー視点に立つ」ということは、そのユーザーが使う「言葉」を知ることだと考えています。もう少し言うと、「そのユーザーにとって近しい言葉の間にある微妙な違いが分かる」ということです。 認知言語学とは 弊社の増田から紹介され、認知言語学というものを知りました。それまでの言語額では、言語知識とは生まれつき獲得しているものと捉えていました。認知言語学とは、人間の一般的な認知能力をとっかかりとして捉え直す言語学の一派です。言葉の意味を静的なものではなく、ダイナミックな概念として捉え、言語の運用面から捉え直すことに特徴があります。 例えば、「肉眼」と「裸眼」は、意味としては近しいですが、異なります。「飛行機を裸眼で確認」はしませんし
クライアントの現場と共に、課題を解決し、あるべき姿に向かうために活動している現場コーチでは、ほぼ必ず自分達チームのやり方を改善していくプロセスとして「ふりかえり」を導入しています。 ふりかえりのやり方は(まずは)オーソドックスにKPTを用いることがほとんどです。このブログではいくつかのTipsを書いているので良かったらそちらも読んで読んでくださいね。 #Tipsその1:「根本的な帰属の誤り」 #Tipsその2:Problemの深堀りの質問 #Tipsその3:安全な場を作るためのグランドルール そのような「ふりかえり」ですが、何度も行っているうちにやり方に慣れてきて安定してKPTが出てくるようになるのですが、一方でふりかえりのやり方に対して「もっと上手くできるのではないか?」「何かしっくり来ていない」という感覚を持つこともあります。 このような時には「自分達が行っているふりかえり自体をテーマ
ギルドワークスの増田です。 ソフトウェア設計の目的は「変更コスト」を下げることです。 変更が容易なソフトウェアは、発展性に富み、生き生きとした活力を保ち続けます。変更がやりやすいソフトウェアは、事業やサービスの成功をもたらす原動力になります。 変更がたいへんなソフトウェアは、しだいに活力を失っていきます。誰もさわることができなくなり、しだいに、事業やサービスの足かせになっていきます。 変更コストの大きな違いを生むのは、プログラミング言語/フレームワーク/開発ツールの違いでありません。ちょっとしたコードの書き方の違いの積み重ねが、ソフトウェアの変更コストに大きく影響します。 ※注意:この記事は2014年9月9日にGuildWorks Blogで公開したエントリを移行したものです。 変更がたいへんになりそうなコード if(date.isBefore(SUMMER_START)||date.is
ギルドワークスの佐々木です。 私は、2010年度に産業技術大学院大学の履修証明プログラム「人間中心デザイン」を履修していました。デザインとはなんぞや?も分からぬまま、デザイナーやディレクターの方々に混じってエンジニアという立場で参加していました。 ※注意:この記事は2014年9月19日にGuildWorks Blogで公開したエントリをリライトしたものです。 参加した動機は「もっとユーザーに使われるソフトウェアを作りたい」といったものでしたが、人間中心デザイン(HCD)やユーザー体験のためのデザイン(UXD)に触れられたことは、私にとってソフトウェアに向き合う考え方が変わる転機になりました。 そんな中で、どうにかこの学びを実践に結びつけたく、しかしながらデザインとエンジニアリングの距離感(※後述)について悩んでいたのですが、先日ギルドワークスメンバーと話していて、自分が思ったよりも近しい考
ギルドワークスの佐々木です。 今回はIT業界に出回っている様々な「キャンバス」や「マップ」をまとめてみたいと思います。その前半として◯◯キャンパスをまとめてみたいと思います。 目次 ビジネスモデルキャンバス パーソナルキャンバス バリュー・プロポジションキャンバス リーンキャンバス MVPキャンバス 以下は次回の後半でまとめたいと思います。 マインドマップ カスタマージャーニーマップ 共感マップ ブレインマップ ユーザーストーリーマッピング 各キャンバスの紹介 1. ビジネスモデルキャンバス 「ビジネスモデルキャンバス」は、名前の通りビジネスモデル・ビジネスの仕組みを可視化したもので、様々な「キャンバス」が出回るキッカケとなりました。「ビジネスモデルジェネレーション」という書籍で提唱されました。キャンバスが提唱されるまでに、様々なビジネスモデルのモデリングツールがあったのですが、それらにあ
ギルドワークスの増田です。 河上さんが書いていたヘキサゴナルアーキテクチャに関連して、ドメインモデル中心のアーキテクチャについて考えてみます。 「ドメイン駆動設計」本のアーキテクチャへの疑問 私の設計の考え方は、6年ほど前に出会ったエリック・エバンスの「ドメイン駆動設計」が基本になっています。しかしドメイン駆動設計を実践するためのアーキテクチャについては、エバンスが「ドメイン駆動設計」本の中で描いているアーキテクチャの図が、どうもしっくりきませんでした。 4章のレイヤ化アーキテクチャの説明そのものは、すっきりしています。 プレゼンテーション層 ユーザ向けの情報の表示。ユーザからのコマンドを受け取って解釈。 アプリケーション層 ソフトウェアが行うべき仕事を定義。実際の処理はドメイン層に委譲する。ドメイン層(モデル層) ビジネスの概念、ルールの記述。業務アプリケーションの核心。 インフラストラ
増田です。 最近、いろいろな会社の社内の開発チームの方と話す機会が増えました。その中で、感じることが多いのが「現場の開発チームの設計力」の弱さです。5年以上の経験がある方でも、ご自身の設計力に悩んでいる。チームを引きいる立ち場になると、チームとして設計力の不足を痛感される方が多いようです。 チームの設計力を改善するには、どうすればよいか。それが今日のテーマです。 ※注意:この記事は2014年9月4日にGuildWorks Blogで公開したエントリをリライトしたものです。 設計の目的と効果をメンバーで共通理解にする ソフトウェア設計の目的は「変更コスト」を下げることです。 変更が容易なプログラムもあれば、手を加えることが現実的には不可能なプログラムもあります。この違いを生むのが「設計」です。変更が楽で安全になるように、コードの書き方やコードの整理の仕方を工夫する。それがソフトウェアの設計で
ギルドワークスの増田です。 最近、ある分野(株価)に特化した SNS サービスのドメインモデルを設計する機会がありました。 設計で悩ましいのはクラス名やパッケージ名に良い「名前」を見つけることです。 今回は、モデリングの初期の段階で、私がどのようにクラス名やパッケージ名の候補を探したか、そのやり方を紹介します。 ※注意:この記事は2014年10月27日にGuildWorks Blogで公開したエントリをリライトしたものです。 オンラインマニュアル モデリングにあたって、最初に参考にしたのが twitter と facebook のヘルプ画面です。 twitter の用語集 facebook のプロファイルとタイムラインの利用ガイド この情報がありがたいのは、同じ内容を日本語でも英語でも見ることができる「多言語対応」になっていることです。この日本語は英語だとなんていうんだ、という疑問のほと
ギルドワークスの増田です。 以前に書いたリファクタリングのエッセンスの続編です。 場合ごとのロジックの書き分け(条件分岐)は、プログラミングの基本ですね。 if-then-else 構文は、良く使われる「場合分け」の記述方法です。 今回は、この「場合分け」の書き方のバリエーションを考えてみます。 「場合分け」の書き方の違いは、ソフトウェアの変更コストに大きく影響します。 ※注意:この記事は2014年10月14日にGuildWorks Blogで公開したエントリをリライトしたものです。 if-then-elseを使った書き方の例 double getPayAmount(){ double result; if(isDead()){ result = deadAmount(); } else if(isRetired()){ result = retiredAmount(); } else {
巨大不明生物の仮説をキャンバスで描いてみる 皆さんはシンゴジラをご覧になられたでしょうか。私は9月19日現在で、7回鑑賞しました。 観るたびに何か発見があるのが面白い、作品です。さて、この映画を鑑賞していて私の中で引っかかったのは、 巨大不明 生物の呼称が示すとおり、このような全く先が読めない不確実性の高い事案に対して、どうやって仮説検証ができるだろうかということでした。 対象は極めてファンタジーですが、リアリティあふれる作品だけに、仮説を立て方を示すには良い素材になるかもしれないと、いつも仕事で使っている 仮説キャンバス で巨大不明生物の撃退のための仮説を立ててみました。 設定は、相模トラフトに潜伏〜再上陸あたりの時期とします。仮説立案者の視点は、巨大不明生物統合対策本部副本部長とします。 なお、一応ネタバレを含みますので、まだ作品をご覧になっていない方は、まずは早々に鑑賞しましょう。
パフォーマンスが高いチームの特徴の1つに、それぞれの得意なことや価値観、またお互いに期待していることがわかっているということがあります。 今回はこのお互いのことを知り、期待をすり合わせるための道具として「ドラッカー風エクササイズ」を紹介します。 ※注意:この記事は2014年8月27日にGuildWorks Blogで公開したエントリをリライトしたものです。 「チームにおける期待」を合わせる 困難なプロジェクトをより成功に近づけるためには「2つの期待」をマネジメントする必要があります。 1つ目は「チームにおける期待」です。 プロジェクトを進めていくチームには様々なメンバーが集っています。そのメンバーそれぞれの得意なことや期待されていると思うことを共有して、それぞれが持っている期待をすり合わせていく必要があります。この「チームにおける期待」を「内側の期待」と呼びます。 2つ目は「プロジェクト関
ミッション、ビジョンの点検から始める 先日、ギルドワークスの創業メンバーで集まって、この2年半分の 事業ふりかえり 合宿を行いました。シンプルな進め方ですが、なかなかスムーズにアウトプットまで辿りつけたので、ご紹介したいと思います。事業だけではなく、プロダクトやチームのふりかえりにも利用できそうです。後で上げる評価軸について、対象に適したものを選びましょう。 プロセスの中で、外したくなかったのは3点。 ・目の前の課題にとらわれ過ぎず あるべき姿 から議論ができること。 ・思いつきではなく 評価軸 を定めた上で具体的なバックログ(施策)を洗いたい。 ・洗いだしたバックログを いつ実行するのか 期限まで明確にしたい。 この3点を満たしながら、 事業をふりかえって、行きたい方向へとむきなおる ことが今回の合宿の狙いでした。ただふりかえるだけではなく、あるべき姿との差から、今後の方向性を決めること
ソースのdiffを取るように、キャリアのdiffを取る 数年に1度は改訂する個人ドキュメントに、職務経歴書があると思います。ドキュメントとしては書くのにたいへん面倒な部類に入りますが、1回作っておくと後は更新で済むので、便利ですね。私が改訂したのは、もう何年も前で、すっかり放置しております。人生が安定してきたのかもしれません。 職歴すなわちキャリアのログをweb上に記録し、他の人と見せ合うことができるサービスがあります。ヒューマンリソシアさまの依頼の下、ギルドワークスで開発した「キャリアログ」です。コンセプトは、 「ソースのdiffを取るように、キャリアのdiffを取ることができる」。 先輩や自分とは異なる境遇の方がどんなキャリアを積んできて、これから先どう行こうと考えているのか、他の人の考えを知ることで自分のキャリアを見つめなおす機会にしようというのが狙いのサービスです。 増田さんの職人
「チームが自律的になって欲しい」というマネージャーの声 現場コーチのヒアリングをしていると、経営者、マネージャーなど現場チームの外から「自分達で自発的に考えて動いたり、チャレンジする自律的なチームにして欲しい」という声をよく聞きます。 そういう声をもとに現場支援を開始すると「この環境ではチームが自律的になりたくても、すぐに壁にぶち当たるだろうなぁ」と感じることがあります。 現場チームは「自分たちで色々やりたい」という希望や意思を持っている一方「やっていいかわからないし、やってうまくいかなかった時にどうなるかわからない」という不安を抱えていることが多くあります。 現場チームが自律的になることができない原因の1つに「自律的になる環境がない、整っていない」ということがあります。 狼と羊飼いがいないこと チームが新しいことをやろうとすると、やたらと反対したり、自分の意見を押し通そうとする、まさに羊
カスタマージャーニーマップとは、ウェブサイトやサービスを利用する顧客がどのようなプロセスで、どのようなタッチポイントをもって、どのような感情と思考をもってどのような体験をするのかを1枚絵のように視覚化したものです。その名の通り、「顧客(カスタマー)の旅(ジャーニー)をしるした地図(マップ)」です。 メジャーな手法ですので、ここで詳細な説明は行いませんが、ユーザーの感情や行動が全体像として図解されていることや、図解ゆえに関係者が集まって議論しやすいなどの利点があるため、サービス企画やウェブサイト制作時によく使われる手法です。 私たちギルドワークスでもユーザーの動きを見立てる方法として、カスタマージャーニーマップを利用しています。 ユーザーストーリーマッピング、サービスブループリントなども利用していますが、カスタマージャーニーマップはユーザーの感情や思考やモチベーションも関連させられるところが
ギルドワークスに参加して、プロダクトづくりの価値観が変わりました 〜 ギルドメンバーインタビュー Vol.1 ソフトウェアエンジニア兼プロダクトオーナー見習い Takahashi Toshiaki 〜 ギルドワークス ギルドワークスのなかにはいったいどんな人がいて、いま何を考えているのか…メンバーのリアルな姿をインタビューを通してお伝えします。 第一回目は、ソフトウェアエンジニア兼プロダクトオーナー見習いTakahashi Toshiakiが登場。時節柄、リモートでじっくり語ってもらいました。(2020年6月取材) 犬の散歩から運命の出会い --まずはかんたんに自己紹介をお願いします。 Takahashi To…
このページを最初にブックマークしてみませんか?
『DevTab - 成長しつづけるデベロッパーのための情報タブロイド』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く