patorashのブログ

方向性はまだない

カラムだけでなく、テーブルにもコメントを追加する

DBのカラムにコメントを追加するシリーズ、いよいよ最後。 テーブルにもコメントを付けていきます。

今までの記事はこちら。

patorash.hatenablog.com

patorash.hatenablog.com

patorash.hatenablog.com

patorash.hatenablog.com

テーブルを抽出する

テーブルの抽出は今までもやっていたので簡単ですが、とりあえずbin/rails consoleから。

tables = ApplicationRecord.connection.tables

次に、このデータを元に、マイグレーション用のコードを書かせます。

tables.each { |table| puts "change_table_comment(:#{table}, from: nil, to: '')" }; nil

上記を実行すると、以下のような文字列が出力されます。(テーブル名はダミーです)

change_table_comment(:users, from: nil, to: '')
change_table_comment(:posts, from: nil, to: '')
change_table_comment(:tags, from: nil, to: '')
change_table_comment(:post_tags, from: nil, to: '')
# 以降、テーブル・ビューの数だけズラズラと…

出力された文字列をコピーしておきます。

マイグレーションファイルを作る

とりあえず生成。

bin/rails g migration AddTableComments

書いていく

さきほどrails consoleで出力させたコードをペーストします。

class AddTableComments < ActiveRecord::Migration[6.0]
  def change
    change_table_comment(:users, from: nil, to: '')
    change_table_comment(:posts, from: nil, to: '')
    change_table_comment(:tags, from: nil, to: '')
    change_table_comment(:post_tags, from: nil, to: '')
    # 以降、テーブル・ビューの数だけズラズラと…    
  end
end

あとは、上記のコードのto: ''のところに、コメントを書いていくだけ!!👍

実行する

いざ、実験

bin/rails db:migrate

確認するには、bin/rails dbconsolepsqlを起動します(PostgreSQLの場合)。そして\dt+を実行してみてください。

f:id:patorash:20210305073945p:plain

バッチリ、テーブルにもコメントが追加されていきました😁

まとめ

今回も、コードにコードを書かせることで楽ができました。また、テーブルにもコメントを付けることで、なんのために追加されたテーブルなのかがわかりやすくなりました。Railsを触る人にとってはモデルを見ればわかる内容であっても、DBしか触る機会がない人にとっては、有用な情報だと思います。

開発メンバーには、「とりあえずこれで一旦、データベースにコメントを追加するのは終わり」と伝えて、現状のコメントでは意味がよくわからないものがあったら、質問してもらって都度コメントを更新するようにしていく、という方針にしました。

プロジェクトに関わるメンバーの情報格差をなくしていくぞ!💪

コメントのないカラムを抽出してマイグレーション処理を生成する

データベースのカラムにコメントを追加していくシリーズ。

今までの経緯はこちら。

patorash.hatenablog.com

patorash.hatenablog.com

patorash.hatenablog.com

ここまでで、I18nを使ってデータを突っ込んだので、残りはそれらで漏れたテーブル・カラム群となります。

コメントのないカラムを抽出する

まずはbin/rails consoleでやっていきます。

tables = ApplicationRecord.connection.tables + ApplicationRecord.connection.views
table_with_columns = tables.each_with_object({}) { |table, hash| hash[table] = ApplicationRecord.connection.columns(table) }
table_with_columns = table_with_columns.select {|table_name, columns| columns.any?{ |column| column.comment.nil?} }
table_with_columns.transform_values! {|columns| columns.select {|column| column.comment.nil?}}

これで、table_with_columnsには、カラムにコメントのないテーブルとカラムのHashが出来上がります。

次に、このデータを元に、マイグレーション用のコードを書かせましょう。

table_with_columns.each { |table, columns| columns.each { |column| puts "change_column_comment(:#{table}, :#{column.name}, from: nil, to: '')" }}; nil

上記を実行すると、以下のような文字列が出力されます。(テーブル名、カラム名はダミーです)

change_column_comment(:posts, :id, from: nil, to: '')
change_column_comment(:posts, :title, from: nil, to: '')
change_column_comment(:posts, :content, from: nil, to: '')
change_column_comment(:tags, :id, from: nil, to: '')
change_column_comment(:tags, :name, from: nil, to: '')
# 以降、コメントのないカラムの数だけズラズラと…

出力された文字列をコピーしておきましょう。

マイグレーションファイルを作る

とりあえず生成。

bin/rails g migration AddColumnCommentsToEmptyColumn

書いていく

さきほどrails consoleで出力させたコードをペーストします。

class AddColumnCommentsToEmptyColumn < ActiveRecord::Migration[6.0]
  def change
    change_column_comment(:posts, :id, from: nil, to: '')
    change_column_comment(:posts, :title, from: nil, to: '')
    change_column_comment(:posts, :content, from: nil, to: '')
    change_column_comment(:tags, :id, from: nil, to: '')
    change_column_comment(:tags, :name, from: nil, to: '')
    # 以降、コメントのないカラムの数だけズラズラと…
  end
end

あとは、上記のコードのto: ''のところに、コメントを書いていくだけ!!👍

実行する

いざ、実験。

bin/rails db:migrate

どんどんコメントが追加されていきました。

確認するには、bin/rails dbconsolepsqlを起動します(PostgreSQLの場合)。そして、\d+ (テーブル名)を実行してみてください。例えば、\d+ posts等です。

f:id:patorash:20210303124346p:plain

バッチリ、コメントが追加されていました😀

まとめ

自力でコメントのないカラムを探してchange_column_commentを書いていくのは大変なので、コードにコードを書かせることで楽ができました。

メタプログラミングでActiveRecord::Enumの値についてカラムにコメントする

前回はI18nのデータを元にコメントを追加するというやつを書きました。

patorash.hatenablog.com

今回は、さらに踏み込んで、ActiveRecord::Enumの値が何を示しているのかを、メタプログラミングを使ってコメント化しました。

なお、プロジェクトではgem enum_helpを使っているため、それを前提とします。enum_helpは、enumの値からI18n対応した文言を取得するのを楽にするgemです。

github.com

マイグレーションファイルを作る

とりあえず生成。

bin/rails g migration AddColumnCommentFromEnum

書いていく

gistから貼り付けておきます。

肝は、I18nenumの定義のないテーブルはさっさとnextでスキップして、ある場合はカラムの定義毎にenumI18nの定義があるか確認して、なければnextでスキップして…というふうにしてループの回数を減らしてます。 enum_help用のI18nのデータがあるカラムが見つかったら、

  1. テーブル名からクラスを取得
  2. sendメソッドにカラムの複数形にしたものを渡して、enumの定義を取得(例えば、User.rolesを取りたくてUser.send("role".pluralize)する)
  3. enumの日本語の定義と数値の定義の配列を生成する。
  4. ハッシュに変換、キーと値の入れ替え後、文字列化

というのをしてます。後半のやつは普通に最初からそういうデータ作ってもよかったな…。simple_form対応しているコードからコピペしてきたからこうなっただけです。

Add column comment from ActiveRecord::Enum. with …

実行する

いざ、実験。

bin/rails db:migrate

プロジェクトでは、gem annotateを使っていて、モデルのファイルの先頭にテーブル定義がコメントで追加されています。それのコメントを見ていきます。

Before

どの値が何の状態を表すかわかりません…😢

#  status(ステータス)              :integer          default("accepted"), not null

After

どの値が何の状態を示すか、バッチリわかるようになりました👍

#  status(ステータス:{0=>"受付済", 1=>"処理中", 2=>"完了", 3=>"失敗"}) :integer          default("accepted"), not null

まとめ

enumを使っているカラムの説明を1つずつ書いていくのは大変そうだったので、メタプログラミングで解決できてよかったです😀

楽々ERDレッスンを読んだ

TLで良書だというのをチラホラと見かけていたのだけれど、結構古い本なので迷っていたのだが、今でも通用しそうな内容っぽいので買って読んでみた。

感想から書くと、これもまた「UNIXという考え方」と同じで、もっと若いうちに読みたい本だった…😇

この本の内容を知っていれば、データベース設計で悩むことも相当減っていたと思うし、プログラムで苦しむことも減っていたと思う。つまり、この本は「買い」です。かなりお薦めできる。もう読んでいる途中から社内のTeamsでは良書だと言いまくった。めちゃめちゃプッシュしたからか、後輩の何人かも買ってくれたみたいだった😋

ちなみに「UNIXという考え方」の感想はこちら。

patorash.hatenablog.com

DB設計総論

データベース設計をする際に見ていく手順がまとまっているのがよかった。特に、イベント系から洗い出して、イベント系の正規化をしてから、リソース系を洗い出す、というのは目から鱗だった。

Railsに慣れているから、リソース系から洗い出そうとしてしまう癖があったので、ここはめっちゃ唸った。イベントという、事実を記録するところが大事。One fact in one place.(1つの事実を1つの場所に)。正直、これが今のプロダクトで出来ていない。1つのテーブルに2つのイベント系が含まれてしまっている。そのせいか、クエリも複雑になるし、カラム数は増えるしで、プログラムのハンドリングも難しくなっていたのだが、かといってこれを読むまでは特に疑問も抱いてなかった。あー、リファクタリングしたいー!!

また、よくRailsActiveRecordで批判される、テーブル毎にIDを振るという仕組みについても、このままでいいんじゃないかという自信になった。サロゲートキーを使うほうが、変更に強いシステムになり得る。コードを個別に作ることはいいことだが、そのコード体系に矛盾が生じた場合、外部キーに使っていたら大変なことになるというのは、確かにそうかも…と思った。サロゲートキーであれば、そういう問題は起きないので、コード体系は個別に仕様変更可能。

あとは状態の遷移をフラグで管理するか、個別のエンティティを作るかというところも面白かった。似ているけれども違うもの。フラグで管理しているとさも共通化出来ていそうにみえるけれど、状態が違うということはビジネスロジックが違うということになる。単純な状態だけならば、フラグでもいいかもしれないけれど。

この章で心強かった言葉を抜粋する。正規化について。

「いかに正しくするか」ではなく、「いかに無理なくムラなく無駄なくするか」というふうに考えればそれでよいと思い至ったときです。

RDBMS総論

データベースを使うことのメリットや、なぜデータベースが生まれたのか?という背景に話が移っていて興味深かった。RDBMSは極論いうと、レポート生成機である。レポートをいかに簡単に作り出せるか、そのために生まれてきたもの。昔はエンジニアが考えたフォーマットで蓄積されていたデータしかなかったので、いいレポートを作るアイデアを思いついても、エンジニアにお願いするしかなかったが、RDBMSができたことで、SQLさえわかればすぐに試すことができるようになった。RDBMSはエンジニアという特権階級からのデータの解放。と書いてあったが、十分難しいぞ、SQL…。しかし、SQLが分かればすぐレポート作れるのは確かにそうである。

データは活用されてナンボで、使われなければただのゴミ…。それはこの前のOSO2020の話に通じるものがある。

patorash.hatenablog.com

データ中心アプローチ(DOA)

DOAの本質についての話は面白かった。データという客観的なものを通じて、業務プロセスのムダ・ムラに切り込んで企業を変えていくという壮大な話だった。単なるデータ設計の話ではない。

DLC(データライフサイクル)から考えて、データの正規化から、さらに踏み込んでトランザクションの正規化、そこからUIの無駄を省き、ユーザの役割の正規化、組織の正規化へ…。設計はワークフローを変えて、組織を変える力もある。

数学的正規化と業務的正規化

教科書的な正規化では、実際の業務に沿った正規化にならないケースが殆ど。想像力を働かせてヒアリングをして業務的正規化に落とし込んでいく。ERDとは、ビジネスの写像という表現にグッと来た。

論理設計と物理設計

非正規化についての話があった。本当に非正規化は必要なのだろうか?非正規化は時代遅れ。ハードウェア性能は目覚ましく良くなっている(この本は2006年の本だけれど)。なぜ非正規化が大事と言われていたかを考えてみると、1980年代はハードウェアが遅いし高価で容量も少なかったため、少しでも容量を節約したり高速化するために必要な手段であった。しかし、その手法を未だに引きずっているのはナンセンスではないか?というのが筆者の意見だった。これもまためっちゃ唸った。正規化した後、「でもまぁどこか非正規化したりせんといかんのかな…?」とか気にしていた自分がいたが、もう基本的に気にしないことにする。非正規化は、せっかくやった論理設計を無駄にする作業になる。

現代においては、インデックス設計が物理設計といっても過言ではない、とあった。なぜインデックスを使うのか?の説明があったが、まぁそのあたりは知っているのでサラッと流した。ただ、検索が優先か、更新が優先かという話もあるが、更新においても検索が重要な意味を持つので、インデックスが必ずしも更新性能を落とすわけではない、というふうに書いてあったのは気付きがあってよかった。

SQLバッチ処理

SQLバッチ処理であるということを知らずにプログラミングすると、N+1問題が発生するようなコードを書きがち、という話が書いてあった。めっちゃわかる…。特にActiveRecordに頼っていてSQLを全然意識しない人はそういうのやりがち…。

SQLに詳しくない人のために、ストアドプロシージャでSQLを隠蔽した関数を作って、それを使わせることで効率の良い開発を行うという手法が紹介されていた。ActiveRecordで簡単にデータが取れる現代においては微妙な開発手法であるけれど、これは経験的にめっちゃわかる。

もう15年前くらいになるけれど、当時、自分含めて数人がSQLが全然わからなかったのだが、複雑なJOINをしなければならず、全く歯が立たなかった。そのため、データを取得する箇所はSQLを書ける人が担当して取得用メソッドを作るように分業をしていたことがあった。そのおかげでこちらはメソッドを呼び出すだけで必要なデータが取れた。ストアドではなかったけれど、同じようなことだ。これの何がいいかっていうと、SQLをよくわかってない人から、データを守ることができる。間違ってデータを壊すようなSQLを書かれなくて済む。DBAだけがストアドでカプセル化したSQLを関数として提供することで、安全かつ効率のよい処理ができるし、テストはそのストアドのテストを行えばいい。金融系や個人情報に厳しいシステムならば、この手法は良さそう。

ERDレッスン

レシートや予約受付、注文用紙を元にERDを書いていくというレッスンがあって、すごく頭の体操になってよかった。解説もわかりやすかったし、こういうケースも想定できるよというヒントもあった。ここは買って実際にやってみるのをお薦めしたい。

付録

付録では、EXPLAINの読み方がダイアグラム付きで書いてあってよかった。EXPLAINは最初はなんとなくとっつきにくくて思考停止してしまいがちなのだが、こういう図で示されるとわかりやすいのではないかと思う。そういう意味でも若い頃に読みたかったというのはある。

あとはボトルネックの原因と対策についてが書いてあったが、普通に気を付けることが書いてあったが、経験が浅いと知らないことかもしれないので、ここも若いうちに知っておくべきことだなぁと思う。

つまり、付録もすごく有用!!

全体を通して

この本自体は初心者向けというよりは中級者向けではある。正規化についての説明とかはほぼなくて、それは知っている前提なので、基本情報技術者試験に受かってるレベルの人が読むとすごくいいと思う。

なぜデータベースが生まれたのか?というところから遡って、故にデータベースはこういうものである、という話で進んだので、とても内容が腹落ちしやすかったし、時代に即した設計しようぜってのもウンウン頷きながら読めたし、非常に楽しめたし今後の仕事に活かせそう。

Webアプリケーションエンジニア全員にお薦めできるのではないだろうか?(主語が結構でかい…😅)

楽々ERDレッスン (CodeZine BOOKS)

楽々ERDレッスン (CodeZine BOOKS)

I18nのデータを基にDBのカラムにコメントを追加する

前回、こういう記事を書いてました。

patorash.hatenablog.com

Mackerelにテーブル数、カラム数、コメント数を表示できるようにしたわけですが、カラム数に対してコメント数が0でこれから全部やっていくの辛い〜😇と思っていたのですが、ふと、I18nから引っ張ってくれば、特別な経緯のないやつはコメント付けられるんじゃないか?と思いつき、早速やってみました。

マイグレーションファイルを作る

とりあえず生成します。

bin/rails g migration AddColumnCommentFromI18n

書いていく

gistから貼り付けておきます。I18nの定義が存在したら、それをコメントに設定するというふうにしてあります。

Add column comment from I18n

実行する

いざ、実験。

bin/rails db:migrate

結果

一気にコメントが入った👍

f:id:patorash:20210218105032p:plain

まとめ

とりあえず、とっかかりとしてカラムのコメントを埋めていくのにはいい方法だったかなと思います。残りは頑張って埋めていくぞ!😇

DBのテーブル数、カラム数、コメント数をMackerelに登録するrake task作った

先日のOSO2020で、はてなの吉田さん(id:syou6162)がカラムのコメント数をMackerelのサービスメトリックとして登録して可視化したという話をして感銘を受けたので早速rake taskを作ってみた。

なお、先日の記事。

patorash.hatenablog.com

言及されていたのは、スライドのここ。一番下に書いてありますね。

ところで私はMackerel初心者です

会社ではMackerel使っているし、私自身も一応恩恵は受けているのですが、Herokuを使っているから外形監視くらいなもんで、じゃあどうやって可視化したらええねん?っていうところで、早速家にあるMackerelサーバ監視入門を引っ張り出したわけです。1回は読んだんですよ!なかなか使う機会がないだけで!

Mackerel サーバ監視[実践]入門

Mackerel サーバ監視[実践]入門

これによると、サービスメトリックを登録すればいいということがわかったのだけれど、実際にグラフを作る方法がいまいちよくわからなかったので、本にあるcurlのサンプルを見ながら、RubyMineのhttp clientでサービスメトリックを登録するAPIに投げてみました。

POST https://mackerel.io/api/v0/services/<サービス名>/tsdb
Content-Type: application/json
X-Api-Key: <MackerelのAPI Key>

[{"name": "Sample.bar", "time": {{$timestamp}}, "value": 30}]

すると、グラフができました。なるほど。時間をおいて、値を変えながら投げてみました。

f:id:patorash:20210216171207p:plain

とりあえず登録してしまえば、グラフができるっていうことですね。

rake taskを作る

グラフの作り方はわかったので、さっきのグラフは削除しておいて、あとはrake taskでデータを投げるだけです。 gistでコードを公開しておきます。

2021-02-17 追記

(追記ここから)

Viewのことを考慮できていなかったため、Viewも追加しました。gistのほうも修正済みです。 PostgreSQLが使っているシステムビューは除外しています。

(追記ここまで)

環境変数を設定した上で、 bin/rake mackerel:service_metric:database:post を実行すると、

  • テーブル数 + ビュー数
  • カラム数
  • コメント数

がグラフになります。

また、development環境でmigration系のタスクが実行されたら自動で実行されるようにしておきました。

Post custom metrics(table count, column count, an…

苦労した点は、db:migrateが行われたら自動で実行されるようにしたのですが、テストを流すとdb:migrateがないと言われて落ちました。db:migrate後に実行されるgem のannotateはどうしてるんだ?と思って調べてみたら、id:onk さんが出しているPRが出てきて、対応方法がわかったので丸々拝借しました。

参考にしたコードはこれ。

annotate_models/annotate_models_migrate.rake at 516ed58e5662e32fca5114c6dbe20be93a4e5507 · ctran/annotate_models · GitHub

結果

こんな感じでグラフが出るようになりました!ちなみにコメントは0です。こ、これから追加していくぞ!😇

f:id:patorash:20210216172105p:plain

2021-02-18 追記

楽にコメントを追加したかったので、I18nを利用して追加する方法を記事にしました。

patorash.hatenablog.com

オープンセミナー岡山2020に参加した

オープンセミナー岡山2020は新型コロナウィルスの影響で延期となり、2021年になってしまいましたが、オンライン開催ということになっていました。運営委員会の皆様、ありがとうございます。

oso.connpass.com

今年のテーマは「エンジニアリング x ○○(なんか)」ということで、異業種とのコラボ話のような感じかな?と思っていたのですが、もっとエンジニアリングした話でめっちゃよかったです。まさに、○○(なんか)の部分が様々で、枠にとらわれないセッションの数々でした。

今年はオンライン開催ということもあり、セッションの動画も公開されています。気になる方はセッションの動画を見ながらトゥギャッターを見るのがお薦めです。

togetter.com

講演内容の特徴

今回のオープンセミナーの講演は、全体的に「どう課題と向き合うか」というテーマになっていたかと思います。エンジニアリングで課題を解決していくので、必然的にそうなったという感じではあります。

エンジニアリング、上から見るか、下から見るか、それとも中から見るか

上から見る(トップダウン

今回は経営者としてのセッションは藤田さんの「エンジニアリング x 家業」のみかなと思いますが、その経営課題をエンジニアリングと経営者としてのトップダウンでスピード感を持って対処していったのが面白かったです。経営の課題である

  1. 新規開拓(営業)
  2. 利益率の改善(商品開発)
  3. 外的要因による売上減(コロナショック)

について、どうエンジニアリングしていったかは、経営のヒントが詰まっています。他所でやっていることを取り込むのはよくある手ではありますが、それを改善するサイクルを早く回すことができるのは、経営者がITに強いという点だと思いました。

また、藤田さんもまた、藤田さんのお父さんとは違う形ですが、エンジニアリングから縁から縁が生まれ、その縁から事業が生まれていくというのを見ると、やはり縁が大事。そして困っていることに相談に乗ると縁が生まれていくのだなぁと感じました。

下から見る(ボトムアップ

はてなの吉田さんの「エンジニアリング x データ活用」と前田さんの「医療現場で働くシステム担当者として伝えたいこと」は内容が非常にリンクしていました。

現場を尊重しつつ、いかに課題に気付いてもらうか、現場の人たち自身でエンジニアリングできるように導くか(お手伝いするか)が、ボトムアップで重要なことだなぁと改めて思いました。

現地・現場にはデータではわからないことがたくさんあるし、かといってデータがなければ検証できない…。まさにそうなのですが、自分がそれをできているかというと、まだまだ全然足りないなぁと思わされました。特にログの収集とか。ログ設計などについても勉強していかなければと強く思いましたし、蓄積しても活用されなければただのゴミになってしまうというのも、本当にそうなので、現場にいかによい形でフィードバックを返して、モチベーションを高めていくかが重要だなと感じました。

前田さんのスライドの中にでてきた「大切なこと」は印刷してノートに貼り付けておきたい…。現時点で動画は公開されているけれど、スライドがアップされていなかったので、アップしてもらいたいです。そして印刷したい。

エンジニアだと、ゴールが見えてしまうとすぐにそこに持っていきたくなるけれど、そこは現場との調整が必要だし、今困っていない人たちにいきなりゴールの説明をしても響かない。戦略性をもって、如何に課題に気付いてもらうか、ということをセッション後のやりとりで言われてたけれど、それってめちゃくちゃ時間のかかること。そこを丁寧すぎるくらい伴走するって言われていたけれど、これは新人育成でも同じだろうなと思えたので、今後に活かしていこうと思います。

中から見る

末田さんの発表の「フォーク、ナイフ、ものづくり」は、エンジニアリングとは?を問う内容でした。

ITはトレンドが発生しやすく、しかも短命であったり、似たような技術スタック同士で争っていたり(いい表現だと切磋琢磨しているとも言える)するので、そのトレンドに振り回されない振舞い方として、まず俯瞰的に捉えるというのは大事だなと再認識しました。 鳥の目(俯瞰的に見る)、虫の目(近くで多様な視点で見る)、魚の目(トレンドを見る)という比喩がぴったりだなと思いました。

最近は近視眼的になりがちだったので、自分を顧みたくなるとてもよいセッションでした。なぜこの技術は生まれたか?以前はどうやっていたか?を遡って、なぜ最先端のこれに優位性があるのか?まで調べていくのは、大変そうだけれど、知的欲求を満たせて楽しそうです。

GMOペパボの田中さんの発表からは、SUZURIのこだわりが伝わってきました。物販サービスの中からの、こだわりポイントの披露なので、セッションを見ていて楽しく、すごい!と思うところが多々ありました。服のしわの歪み方とか、ステッカーを貼ったシーンを想像させるとか、もう既に物が出来上がっているようなワクワクがあるなと思いました。SUZURIで商品を買ったことは、RubyKaigi2020 TakeOutのTシャツを買った時くらいかもしれません。しかし気になって見てみると、さまざまなクリエイターさんとコラボしていて、見ているだけでも楽しいですね。

suzuri.jp

ヨシオリさんのセッションは、最先端のリモートワーク事情という感じで、すごかったです。会社がそもそもリモート前提の組織で、非同期コミュニケーション前提でドキュメント化が徹底されているところが凄かったのですが、やはりそのバックボーンとなる組織の文化を醸成していくための方針が凄かったです。それぞれの役割の明確化と責任の明確化をはっきりしていること。これがしっかりしている組織はスピード感もあるし、尊重しあえるのだろうなと思います。

ドキュメントのツールがアトラシアンのツールを使われているという話で、創業者が元アトラシアンの方という話だったのですが、前回のオープンセミナー岡山2019で聞いたヌーラボの橋本さんが言われていた「ツールを導入するということは、そのツールを作っている会社の哲学を導入するのと一緒」というのを思い出しました。ちゃんとアトラシアンの哲学を適用できれば、めちゃくちゃいいということなのだろうか…。

patorash.hatenablog.com

Confluenceの評価が180度変わったという話だったので、アトラシアン製品の哲学についても調べてみたいと思いました。随所で出てくるキーワードは、アトラシアン由来のようでした。DACIとか。

www.atlassian.com

通しての感想

課題を解決することの楽しさと共に、課題を設定することの難しさ、巻き込むことの難しさ、しかし、巻き込めた時にこそ効果が最大化できて、エンジニアリングの可能性は無限大だなぁと感じました。エンジニアリングの力を改めて感じることができて、来週からも頑張ろう!という気持ちになれました。多分、参加された皆さんがモチベーションかなりアップしたんじゃないかと思います。

素晴らしいオープンセミナー岡山でした。実行委員長の id:a-know さん、ありがとうございました。そして、お疲れ様でした。実行委員の皆様もありがとうございました。