読者です 読者をやめる 読者になる 読者になる

ツナワタリマイライフ

日常ネタから技術ネタ、音楽ネタまで何でも書きます。

「アジャイルコーチング」を読んだ

Programming

はじめに

現在4人チームのチーム運営に取り組んでいまして、いろいろあってアジャイルプラクティスの1つ、カンバンボードを各自のタスク割りに使うようにしました。

take-she12.hatenablog.com

導入前の課題

  • あらゆる情報をGitlabに一元化しており、個人の作業状況も個人のWORK/name/README.mdに集約していた
    • 結果、報告の粒度や問題点の提起が個人任せになっており、周囲が気づきづらい
    • 頼んだ仕事が本当にそのひとに認識されているかがわかりづらい

まずはチケット化しよう。ということでgitlabのissueを導入しました。

issueを導入した結果

  • どのタスクが誰が担当しているかわかるようになった
  • タスクの状況も1日1回更新してもらうことで1日1回のペースでupdateされるようになった

課題と改善 * タスク粒度が不適当 * ラインをbacklog,todo,doing,review,doneとし、reviewを追加することで、「これ以上自分のやることは終わった(誰かの待ち状態)になったものをreviewにすることにした * 結果、タスクはreviewが入るまでが1タスクになることになった

というわけでこれからはタスクがどれだけ追加されるか、消化されるかの数値をはかって生産性を可視化しよう、ということですが、なぜこのアジャイルコーチングを手にとったかというと

  • カンバンボードを導入した結果、メンバーが指示待ち(タスクを振られるのを待つ)になってしまった
    • これは僕が最初振っていたので当たり前です。自己組織化にはほど遠い。
  • タスクの期待値がうまく伝わらない
    • 説明不足もあるんですが、タスクの完了条件、背景(なぜやる必要があるのか)を記載することでだいぶ良くなりました

というわけで、カンバンボード自体は何なくみんなに使ってもらえたんですが、チーム全体でアジャイル式にタスクをまわしていくというときに、どうやったらみんなが自分ごととして、取り組んでくれるようになるのか?そのマインド変化をもたらすために何が大事か?を考えたときにこの本に出会いました。

アジャイルコーチング

アジャイルコーチング

アジャイルコーチン

自分がスクラムマスター、アジャイルチームをリードする立場になったときの心構えの本。中でもよかったところを紹介します。

1章 コーチングの基本

コーチの役目

気づく、フィードバックする、教育する、ファシリテートする、支援する、がアジャイルコーチの役目。

今は自分がプレイヤーかつマネジメントもやっている状況だったのでとっても良くない状況。そもそも自律的にチームが動いているところにアジャイルコーチが手助けする前提ですよね。

コーチングの態度

「模範を示す」というのがありました。僕自身の経験から、ひとにやってもらうためにはまず自分がやる、ということを心がけてまして、これは間違ってなかったなと実感しました。

もうひとつ、大切だなと思ったのは「言葉に気をつける」「私が」「あなたが」「彼らが」ではなく「私たちが」「私たちの」「私たちに」と置き換える。これは全然意識がたりていませんでした。「うちのチームが」とは言っていたかもしれませんが。(笑)

とはいえ「属人化を殺す」というポリシーで仕事をしているので、特定のひとに仕事を頼むことはあれど、誰のせいとか誰がやらないといけないということはない、はず。

PrOpERサイクル

Problem,Options,Experiment,Review。

PrOpERサイクルという言葉は本書でもたくさん出てくるんですが、でてくるたびに「何の略だったっけ?」と戻ることになってました。(笑)わかりづらい。

意識こそしてなかったですが、ほぼほぼこの通りに仕事を捉えていました。

「何が問題なの?(problem)」「解決するにはどうしたらいい?複数案あるならメリットデメリットを教えて。(Options)」「じゃあやってみて。(Experimtn)」「やってみてどうだった?(Review)」の方式で問題解決に取り組んでいますし、メンバー内でも上記の対話で話を進めています。

問題はExperimentの途中であらたなproblemが発生したり、時間がたてばproblemはproblemじゃなくなったりして、それがめまぐるしいことですね。あとは時間をかけてほしいところとかけてほしくないところの認識にメンバーとギャップがあったりしました。単にこれは対話がたりてないか事前の背景共有が不足してるんでしょうが。

14章 あなたの成長

飛んで一番よかったのはこの章ですね。

情報をキャッチアップしたり、ブログでアウトプット(まさにこのことですね)したりと、自分が成長し続けるための方法がのっています。ただ、中でも一番心にきたのは「優しく」という項目。

チームで仕事をしていれば、イラっとすることもあるし、「なんであんなに時間かかるんだ?」と不信に思ったり、意思疎通がうまくとれなくて「何を言っているかわからない。。。(きっとお互いに)」となったりすることがあるでしょう。(この本でもある通り、あなたを待ち構えてる苦難、ですね)

僕自身、怒りを表面に出したり、直接誰かを批判することはしません。それでも心に刻んでおきたいのがこの"優しく"かなと思います。

自分に優しくするように、他人にも優しくしましょう。厳しく責めたりしてはいけません。誰もが最善を尽くしており、すべてのことには何らかの理由があることを常に意識しましょう。その「最善」は素晴らしいものではないかもしれません。そして、そのように振る舞う理由をあなたが理解していないのかもしれません。だから見つけるのです。推測だけで終わらせて、判断したり陰口を叩いたりしてはいけません。話し合いましょう。情報を直接もらいましょう。驚くことがあるかもしれません。

「同じ立場になるまでは、他人を批判してはいけない」という言葉もあります。人が仕事をうまくできない理由はさまざまです。私生活に困難を抱えているのかもしれませんし、仕事を失い不安を感じているのかもしれません。自分の価値観を曲げなければいけないと感じていたり、コンフォートゾーンから追い出されていると感じていたりするのかもしれません。これまでに仕事で失敗したことがなければ、それは単に運がよかっただけです。適度にストレスのかかる状況にいたことがなかったのでしょう。

これは常に、心に持っておきたいです。

幸い今の僕の職場には失敗を責めたり声を荒げるひとはいません。

おわりに

今回、アジャイルチームを見る立場にとっての心構えを学びました。自分自身についてもPrOpERサイクルをまわして、改善をはかっていきます。

「今すぐ実践!カンバンによるアジャイルプロジェクトマネジメント」を読んだ

Programming

はじめに

久しぶりの投稿です。この本読みました。

今すぐ実践!  カンバンによるアジャイルプロジェクトマネジメント

今すぐ実践! カンバンによるアジャイルプロジェクトマネジメント

今どんな仕事してるの?

今はOSS開発にCIを導入する仕事です。今時CI、ビルド自動化やテスト自動化をやってないプロジェクトなんて世の中にあるかわかりませんが、大きい会社ですので、そのあたり専門チームを作ってフォローしていくという体制になっています。

やってる仕事が多岐に渡り、単純な開発をするわけではなく、テストプログラムを書くこともあればトラブル調査をしたり、開発者に以来したり関連部署と調整したり、いろいろあります。その中でタスクが見えづらくなり、まず見える化のためにgitlab issueを使いはじめました。

そしてちょうど隣にissue boardがあったので、実践してみているところです。ベストプラクティスを学ぶためにこの本を買いました。結論、買ってよかった。

第1章 経営陣の同意を得る

もちろん、新しいプラクティスを導入する際には経営陣の同意は必要でしょうね。インターネット上のカンバンボードシステムを使うにしろ、リアルなホワイトボードと付箋を使うにしろ、お金はかかります。

幸い、私の部署では既に社内システムとしてのGitlabを使っていたのでGitlab boardが何の手続きもなく使えるということ、管理職もこういった変化や新技術導入や取り組みに関しては絶対のNoと言わないひとなので、ここの障壁は一切ありませんでした。

ただ本書にとってのこの章のいいところは、経営陣の同意を得る、というていで、読者にカンバン導入時にどれだけ時間がかかって、どんなリスクがあるのか、同時に説明できるところですね、うまいなぁと思いました。

第2章 カンバンのクリックスタートガイド

この章ではカンバンの基本的な使い方を説明してくれます。大事な部分。

手順1 チームの大まかなルーチンを把握する

これはカンバンボードのリスト(フェーズ)を割り出すために、ある程度決まった形をあぶり出しておいたほうが良いということでしょうね。うちのチームは開発チームではなく、仕事はひとと話すことから技術的解決まで幅広くあるので特に定めていません。

手順2 壁の模様替えをする

これはアナログのカンバンボードを作るという章ですね。私がgitlab boardを使ってますが、まぁアナログのほうが動かす感覚があってメンバーが乗り気になるメリットはあるのかもしれません。

手順3 混乱を抑制する

WIPの上限の設定方法について書かれています。この算出方法は普段の仕事が全て同じルーチンであるときにだけ使える方法ですね。手順1でも言った通りうちのチームでの採用は難しい。

手順4 完了を定義する

各タスクの完了基準を定めないと次のステップへ移動できない、当然のことのようにも思えますが、これはうちはできていませんでした。issueの本文に何ができたら完了か、ということを書いておくと良いと思いました。導入します。

手順5 デイリースタンドアップミーティングを行う

これも各フェーズのWIP制限が決まった上での話ですね。カードをいつ誰でも動かしていいのか、デイリースタンドアップミーティングのときだけ動かすのか、迷っています。WIP上限が決まっていれば、空いたときbacklogから必要分を移動させられる点が良いと思いました。

トラブルシューティング

充実した内容でした。フェーズごとに担当が分かれている場合は作業がブロックされることがあるようですね。そのときはその原因となるフェーズを手伝うことが有効とのこと。多分重要なのはいかにタスクを留まらせないか、だと思いました。Doingに動きがない状態が一番まずいというのは体感しています。

第3章 納期を守る

納期を守るために必要なコツが記載されています。MVP(Minimam-Viable Product)最低限顧客に渡すもの、機能を定義したり、完了予定日の追跡、それに付随するパラメータの計測。

  • TCR(Task Comletion Rate) / タスク達成率。毎日どれだけ達成しているか、もしくはタスクが移動しているか
  • CTE(Current Task Estimate)/ 現在のタスクの見積もり。
  • TAR(Task Add Rate) / タスク追加率。月初のタスク総数を月末のタスク総数から引けばどれだけ追加されたかがわかりますね。

これらをgitlab issueで簡単に取得できたらいいんですが。issueをopenした日とcloseした日がわかればいけるか。rssだとupdateした日しか取れないんですよね。。。

4章〜7章 組織ごとのカンバン導入方法

ウォーターフォール開発、スクラム、アプリケーションのデプロイメント、大規模組織、サステインドエンジニアリング(サービス継続のための欠陥対処)といったシーン、業務の種類に応じてどうカンバンを適用できるかを個別に紹介しています。徹底した現場目線がすごい。

9章 さらなる方策とカンバンを超えて

この章はカンバンがなぜうまくいくのか、その理論的解説をしています。この章めっちゃ大事ですね。

見える化はもちろんのこと、カンバンフローを運用すると自然のタスクには「完了条件」が決められます。そしてWIP制限によって、そのときそのときに最も必要なタスクが順にとられるので、最小限の作業をするようになります。

特にリーン開発の「7つの無駄」をどれも効果的に解決することに気づきます。個人的には「手持ちのムダ」が適切なスイムレーン設定によってなくなること、チケット化+チャットでの通知によって「伝搬のムダ」が大きいと感じています

おわりに

実際に導入してみて、この本を読んで、毎週使い方を改善していっています。ほぼどんなプロジェクトにも適用できるのではないでしょうか。

本書にあるプラクティスを全部実践する必要はないですが、今うちが実践してるルールはこんなところ。

  • WIP制限(Doingのところだけ制限をかけています )
  • レーンを一方通行にすること
    • うちはBacklog→TODO→Doing→Review→Doneにしています
  • 完了条件を明記すること
    • レーンを一方通行にするためには「Review」が一度くるとそのissueは終わるようにしなければなりません。
    • つまり「機能Aの開発」だとして、作業見積もり、コード作成、テスト実行のそれぞれにReviewが入るなら、その単位にissueは分割されます
  • TODO〜Review間は個人が自由に動かして良い。
  • Doneに移動するとき、BacklogからTODOへはデイリースタンドアップミーティングで実施
    • 最初と最後は優先度つけもしくは完了したかの共有のためにメンバー全員の前で実施するようにしています。

自然とタスク粒度が決まってくること、WIP制限によって今やってる仕事と残りの仕事が明になること、フローが流れることで今何に詰まっているのかがわかるようになること。自分でやれるところまでやったらすぐにReviewにすることで待ちのムダがなくなることに効果を感じています。

Gitlab issueに特化した記事をそのうち書こうと思います。物理でもソフトウェアでも、カンバンボードはあらゆるタスク管理に使えると思います!おすすめ!

2017年1月目標振り返り&2月目標

生活

はじめに

今年の年間目標に毎月目標を立てて振り返りする、としたわけですが。。。

take-she12.hatenablog.com

目標を立てたのが1/18っていうのが終わってますよね。(笑)この目標を立てて振り返る難しさを実感しています。とはいえ最初からうまくいきっこないので毎月頑張っていきましょう。

振り返り

楽曲制作

  • [○] とけてなくなる、消えて くなるベース録音して公開
  • [○] こりーセッション曲、1曲自自パート録音完
  • [△] 千秋さんコラボ曲、ベース、ドラム、キーボード、ガイドボーカルいれて公開
  • [×] なのは、月の光に歌うよ 作詞作曲完
  • [○] とけてなくなる、曖昧に揺れる15cm ベース録音して公開追加

とけてなくなるのモチベーションがあがっているようで、前倒しで作業できました。こういう心の変化はとても良いことだと思います。

千秋さんとのコラボはキーボード入れまでできてないのと、公開もできてないですね。この前ミーティングしたんですがまずこの1曲のアレンジを2月中に詰めることになりました。

作詞は出るとき出ないときの差があって、なかなか難しい。ただ目標にしないほうがいいかというとそういうわけでもなく、時間に迫られて出そうとする行為は意味がある。

英語

  • site reliability engeenear 1. Introduction読んでブログ書く
  • Grammer in use Unit10〜20
  • amazon english 5作品

まさかの全部×ですね。英語とまるで向き合っていない(笑)量を減らして確実に英語に向き合う時間を増やすところからやりましょう。

ソフトウェア

振り返ると今月音楽とカレーしかしてないですわ。キャパシティがそんなもんってことなんでしょうねー。どうしたもんかな。

読書

1月に読んだのは5冊ですね。

池上彰の宗教がわかれば世界が見える (文春新書)

池上彰の宗教がわかれば世界が見える (文春新書)

風の歌を聴け (講談社文庫)

風の歌を聴け (講談社文庫)

うち小説は1冊でした。最初の目標がよくなかったですね。(積ん読を読むってのが。)ジャンル別にもれなくダブりなく数字をあげよう。にしても月5だと年60冊なのでもうちょっと読みたいな。勤務地移動で電車に乗ることが増えるのでその分本を読めたらいいな。

健康

  • 30days plank完了
  • run 月50km

どっちも未達。やばい。やる気なさすぎる。ちなみに17.14kmでした。月50kmってかなりハードル下げたのになぁ。。。

振り返りと2月の目標

1月、まぁ目標立てたのが遅いというのもありますが、ほぼほぼ土日は音楽に費やしました。音楽以外の達成度が0っていうところから、今のままだとこの程度のキャパシティしかないことになります。

時間そのものを増やす必要があるので、会社の昼休み1時間はまるまる自分のことをすること、読書なんかがいいですね。(今は会社の仕事をしてしまっている)あとは朝の時間を確保しないといけない。ラン+1workできればいいですね。

平日夜は不確定要素が大きいですが、週2は自分の時間として3hほど取れるようにしようと思います。これはカレンダーにいれます。

それを踏まえて2月の目標。

楽曲制作

  • とけてなくなる-おかえりなさい をベース録音して公開
  • とけてなくなるリリース曲にメロディを打ち込む
  • とけてなくなる-シロップをmix整えて公開
  • なのは ドラムRec
  • なのは ベースRec
  • なのは 月の光に歌うよ 作詞編曲完
  • 千明さんコラボ曲のアレンジ完成

ちょっときつきつですが、なのはのレコーディングで後半はいっぱいいっぱいになりそうなので前半でとけてなくなるのほうを片付けたい。

読書

  • 小説を3冊読む
  • 小説以外を5冊読む の合計8冊を木曜に。1月よりは通勤時間が増えるのでいけるのではないかと思ってます。昼休みも読もう。

英語

  • site reliability engeenear 1. Introduction読んでブログ書く
  • Grammer in use Unit10〜20
  • radwimpsの君の名は英語詞の聞き取りを何か1曲やってブログに書く

1つ減らして、2つkeep、もう1つはやろうと思っていることです。nandemonaiyaをやろうと思ってます。

健康

  • 30days plank完了
  • run 月50km

継続。朝活やるしか道がないらしい。夜はダメだ。

おわりに

達成度はともかく、振り返りのプロセスが大事ということで、続けてみます。

「チラシ・勧誘印刷物の無断投函は一切お断り! 高耐候性ステッカー」がマジで効く

生活

はじめに

「チラシ・勧誘印刷物の無断投函は一切お断り! 高耐候性ステッカー」がマジで効く。

以上です。

マジで効きます。

f:id:take_she12:20170204163448p:plain:w500

ゴミ箱直行だったので手間が省けます。資源も有効活用できることでしょう。

以上です。

javascriptでファイルリストに書かれているファイルを動的に読み込む

Programming

はじめに

音楽を作っているソロプロジェクトのHPを作っています。

とけてなくなる

AWSのS3上において、https対応、circleCIで自動アップロード対応等やりました。

  • レガシーな静的webサイトを一新!軽量cssフレームワークSkelton導入
  • レガシーな静的Webサイトを一新!その② 独自ドメインを使ってAWS S3に静的Webサイト公開
  • レガシーな静的Webサイトを一新!その③ CircleCIとGithub連携でDevOps!
  • レガシーな静的Webサイトを一新!その④ AWS CloudFrontとCertificate Managerでhttps対応する
  • レガシーな静的Webサイトを一新!その⑤ httpsサイトで承認されてないscriptの警告が出てしまう
  • なお、私は本業サーバサイドなのでhtml/javascriptの知識は皆無であり、本質的な解決方法ではないことも、ナンセンスなこともたくさんしているかと思いますが、趣味のHPでなんとかやりたいことをやるために奮闘した記録となっていますので温かい目で見守ってください。

    informationの更新問題

    更新情報を記載するinformationですが私の要望は以下。

    • 更新日ごとにinfo/170101(日付).htmlを追加する
    • index.htmlからinfoフォルダ以下のディレクトリを自動で読み込んで表示する
    • index.htmlでは最新3記事のみ表示する
    • read moreのlinkから全部のinformationをinfoフォルダ以下のディレクトリから自動で読みこんで表示する

    これをやる前の状況は

    • loadするファイルパスがベタ書き
    • 表示部分も記事の分だけベタ書き

    となっており、更新をするたびにindex.htmlに追記するという地獄のような状況になってました。記事数が3,4のうちはいいにしても、早めに対策を打たないといけない。

    こういうことは一気にしてはいけないので、1つずつゆっくり問題を解決していきました。

    記事の読み込みと表示をloopとinnerHTMLを使う

    まずベタ書きの部分をせめて繰り返し可能にします。

    rails(ruby)でいうところのerbみたいにhtmlで書きたかったわけです。これはjqueryのloopを使いました。

    load infomation iterative · takeshe12/toketenakunaru@61fe64f · GitHub

    jqueryで外部htmlファイルをloadする部分

    var num = ["161203","161204","161231","170110","170122","170125"];
    jQuery.each(num,function() {
      var path = 'info/'+ this + '.html';
      $("#" + this).load(path);
    });
    

    表示部分はinnerHTMLを使いました。

    var hoge = ""
    var id = ["170125","170122","170110","161231","161204","161203"];
    $.each(id,function(i,value){
      hoge += "<section class='sec'><div id=\'" + value + "\'</div></section>";
    });
    var elem = document.getElementById("infomation");
    elem.innerHTML = hoge
    

    $(“#” + 170101).load(info/170101)とloadしたら、

    でloadした部分が表示されます。

    今回はinnerHTMLを使ってinformationというidがついた部分にtagを打ち込んでいます。

    昔はdocument.writeというものもあったみたいですが、HTML5では非推奨だそう。

    innerHTMLで注意すべき店はタグ内の要素はシングルクォートでくくらないといけないってことですね。タグ自体をダブルクォートでくくっているので。ところでこのコード閉じカッコがないな。。。なんで動いたんだ。

    参考

    HTML要素の中身を変えるinnerHTML | JavaScript入門編

    filelistが書かれている別ファイルからloadするpathを読み込む

    loadだpathだややこしい説明になってすみません。

    今回やりたかった、infoフォルダ以下の内容を動的に読み込むって、そもそもwebサーバ内のフォルダを除く行為なわけで、クライアントで動くjavascriptでできるわけもないんですね。

    代替案として以下のようなfilelistを用意します。

    • info/filelist
    170101
    170103
    170121

    javascriptでこのファイルを改行で区切って読み込み、配列として取得。あとはその配列を上の例でloopして表示とloadを行います。

    load file list from external file · takeshe12/toketenakunaru@a7053eb · GitHub

    ファイルリストを出すためにゴミシェルも書きました。

    // get early 3 file from info file list.
    var arr = [];
    $.ajax({
      url: 'infolist',
      async:false, //wait to finish ajax connection
      success: function(data){
        arr = data.split(/\r\n|\r|\n/);
        arr.pop(); //delete end value
        var infotag = ""
        $.each(arr,function(i,value){
          infotag += "<section class='sec'><div id=\'" + value + "\'></div></section>";
        });
        var elem = document.getElementById("infomation");
        elem.innerHTML = infotag
      }
    

    ここで謎にajaxを使っています。ちなみにajaxのことは何も知りません。(笑)

    確か非同期通信を実現するためのjavascriptを使った実装の1つ、ですかね。

    今回localhostのfilelistを取得して、取得に成功したら(success)、そのdataを改行でsplitし、arrayに代入。そのあとその値をtagに打ち込んでinnerHTMLとして更新しています。

    ajaxのキモが非同期なわけですが、ここではあえてasync falseとして同期処理としています。同期処理の場合、まだレスポンスが返ってきていないのでタグ生成時にはvalueがundefinedとなってしまいました。そのためasync falseとすることで解決しましたが、良いやりかたではない気もします。

    ちなみにここのarr変数はグローバル変数にしているのでpathをloadするほうでもそのまま使えました。javascriptの変数スコープについては以前勉強したので知っていて、むやみにグローバル変数にするのはよくないのは知っていますが今回はこのまま。

    read moreですべてのinformationを表示

    もっと良いやり方があるとは思ってますが、今回はinformaton.htmlを別ページを作成し、このページ用に全informationのfilelistを作成し、同じ方法で実現しました。全部読み込んでおいて、最初は3つだけ表示、linkをクリックしたら残りも表示、とjavascriptを使えばできるとは思いますが、まずは実現ということで今回は雑な方法で。重複コードができてしまうのでメンテナンス性はさがることからいずれ対処したいです。

    circleCIでfilelist生成を自動化

    さて、今回はfilelistにしたがってinformationを読み込んでいますが、そのfilelistの生成はシェルスクリプトであり、情報を追加するたびにこのシェルを叩いてから、ファイルリストを含めてコミットする必要があります。このひと手間はイケてない。

    exec getfile.sh · takeshe12/toketenakunaru@36a21d0 · GitHub

    circleCIでのbuildの前にこのシェルを叩かせればいいんじゃない?と安易に実行したところ、できました。まぁ、できるよね。gitからcheckoutして、シェル叩いて、それをS3と同期してるわけなので。

    このブログを書くに伴ってゴミシェルをちょっと書き直しました。

    結果的に行数増えとるわ。

    refactor script · takeshe12/toketenakunaru@f8d02c2 · GitHub

    おわりに

    趣味の音楽+仕事のプログラミングということで、楽しいですね。インフラまわりもAWSで整えられたので満足度高いです。肝心のコンテンツ更新も少しずつやっていきます。

    わかる!ドメイン駆動設計を読んでみた。

    はじめに

    なれる!SEみたいですね。あ、新刊出てる、読まないと。

    入社してからインフラよりのソフトウェア(Rails)担当からじわりとオープンソースクラウド基盤開発へ移りつつ、今はインフラの自動化(DevOps、Infrastructure as a Code、Continuous Integration、Continuous Delivery)あたりをやっています。

    ちょくちょくアプリ作りは片手間でやりつつ、あんまりがっつり業務アプリを作る経験はないのですが、この前勉強会でお会いした方が「今これ読んでるんですよー分厚いし難しいんですけどねー」とおっしゃっていて、そろそろ読まないとなーと感じているところ。

    エリック・エヴァンスのドメイン駆動設計 (IT Architects’Archive ソフトウェア開発の実践)

    エリック・エヴァンスのドメイン駆動設計 (IT Architects’Archive ソフトウェア開発の実践)

    とはいえこの分厚さ、とても読み通せる気がしない。

    まずは概要だけ押さえておくかということで以下を読んでみた。

    techbooster.booth.pm

    内容のボリュームに対して1000円は高い。。。と思いつつ、自分の興味が向いたときにその領域の第一のインプットはしておいたほうがいいな、と思い、読んでみました。

    わかる!ドメイン駆動設計

    Androidアプリ開発担当となった主人公が対話形式で、具体的な冷蔵庫の賞味期限管理アプリケーション構築という例を通してドメイン駆動設計を解説していく物語です。

    本書にも書かれてありますが、当然この本だけでドメイン駆動設計が押さえられるわけでもなく、おそらく表面のほんの少しを撫でた程度だと思います。

    ただ、ソフトウェア開発における「そのソフトウェアは何のために作るのか?」という根本的な疑問に答えるための大事な概念だと思います。世の中、作ったはいいけど使いづらかったり、本当にやりたいことはできなかったり、時間が経つにつれて使い物にならなくなるソフトウェアは多い。

    学習でもなんでもそうですけど、考え方ってどんどん抽象化されていきますよね。ソフトウェア設計もそう。単純な処理をするメソッドから、設計手法、設計思想、言語思想。。。こういったなかなか言葉にしづらいけど有用な概念を自分の中に落とし込むというのは非常に重要だと思います。

    今回読んだ内容だとユビキタス言語、そのドメイン内での共通言語を定義する、しかもそれはドキュメント化してはならないというのは非常に重要だと思いました。名前やコードのモデル名が実態とそぐわない例がどれほどあるか。。。

    おわりに

    本家に加えて、実践本もありますが、先に本家を読んだ方が良さそうですね。今年中に読めるといいな。。。

    エリック・エヴァンスのドメイン駆動設計 (IT Architects’Archive ソフトウェア開発の実践)

    エリック・エヴァンスのドメイン駆動設計 (IT Architects’Archive ソフトウェア開発の実践)

    実践ドメイン駆動設計 (Object Oriented SELECTION)

    実践ドメイン駆動設計 (Object Oriented SELECTION)

    2017年1月の目標

    考え方

    はじめに

    毎月目標を立てることを年間目標にあげた。

    take-she12.hatenablog.com

    いや本当ごめんなさいこのブログ更新されるの18日だけど?1月の半分すぎてるけど?初月からなしはまずいでしょね、

    言い訳すると目標自体はもう数日前から考えてたんですいろいろバタバタしてたんですーーーー書かせてください書きます。

    1月の目標

    いくつかカテゴリごとにあげてみます。やりながら数は調整していければと。今月は思いついただけ。きっと月末焦ることになるんだろうな。

    楽曲制作

    • とけてなくなる、消えて くなるベース録音して公開
    • こりーセッション曲、1曲自自パート録音完
    • 千秋さんコラボ曲、ベース、ドラム、キーボード、ガイドボーカルいれて公開
    • なのは、月の光に歌うよ 作詞作曲完

    今年は他者への提供含め、作曲の年。自分自身歌ったり演奏したりするよりは作曲のほうにスキル振っていこうと思っています。各プロジェクト全力で、ここは厳しくやっていきたい。守りたい。

    英語

    • site reliability engeenear 1. Introduction読んでブログ書く
    • Grammer in use Unit10〜20
    • amazon english 5作品

    英語に少しずつ触れる時間増やさないといけないですね。

    ソフトウェア

    rubyマンだったんですが最近はpython機械学習についてはゼロからはじめるディープラーニングはやってみたいな。これもpythonですけど。

    読書

    積ん読かつkindleの可能性もありますが、物理的積ん読と、kidle的積ん読はどちらも読む。どうも最近読む時間取れてないなあ

    健康

    • 30days plank完了
    • run 月50km

    腹筋とジョギング、あんまりがっつりやるつもりはないですが、最低限やっとかないと太りすぎるので

    おわりに

    ちょっと駆け足ですが明文化して振り返るためのエントリーということでご容赦いただきたい。