規程文書を Google ドキュメント から GitHub に移行する - KAYAC engineers' blog
人事部の小池です。 この記事は KAYAC Advent Calendar 2022 の16日目の記事です。 カヤックの規程文書管理の仕組みを Google ドキュメント から GitHub に移行した取り組みについて紹介します。 これまでの文書管理 カヤックでは長年規程文書を Google ドキュメント で管理していました。Google ドキュメント は多くの従業員にとって親しみやすいものの、文書を管理する上でいくつかつらい点がありました。 改訂内容の差分が追いにくい・改訂の背景がわからない Google ドキュメント なので変更履歴から過去の版を閲覧することは可能ですが手軽とはいえません。改訂の際は内容以外にも改訂に至った経緯、議論といった背景も重要ですが、これらの背景は成果物である Google ドキュメント の版の履歴からは伺うことはできません。「ある時までは確かこういった規程内容
PostgreSQLのER図をコマンド一発で生成したい
概要 ガツガツ開発してみたけど ER図とか特に管理してなかったから俯瞰した図はねえぜ。 みたいなケースってありますよね・・・ そんな時いい感じにER図自動で生成されてほしいなぁ。というそれだけのお話。 方法 以前MySQL使ってた時はdbdiagram.ioにペコっと貼り付けて生成とかさせてたけど 今回PostgreSQL使うことになり コマンドラインでDDL出力->dbdiagram.ioにコピペでER図出力しようとしたら 結構syntax対応されてなくてたくさんエラー出てきた・・・・ ので、ちょろちょろっとググってみるとschemaspyなるものが良さそうだったので使ってみた やり方 DBにアクセスできる状態で以下コマンド打つだけ docker run -v "$PWD/schema:/output" --net="host" schemaspy/schemaspy:6.1.0 -t
サイトリニューアルの提案書を社内で通すためのポイント！予算を獲得するコツとは
サイトをリニューアルするには提案書が必須ですが、作成方法が分からず悩んでいる方も少なくありません。また、せっかく時間をかけて作成しても、社内で通らなければ無意味なものになってしまいます。 そこでこの記事では、サイトリニューアルの提案書の作り方や社内で通すためのポイントなどについて紹介します。 目次 サイトリニューアル提案書が必要な理由 サイトリニューアル提案書の作り方 サイトリニューアルの提案書を通すコツ サイトリニューアル提案書の作成に便利なサービス ポイントを押さえて、効果的なサイトリニューアル提案書を作成しよう ▼ サイトリニューアルの提案書テンプレート サイトリニューアル提案書が必要な理由 サイトをリニューアルするにあたり提案書が必要な理由は、なぜサイトをリニューアルするのか、リニューアルによってどんな効果があるのかを明確にするためです。 また、目的や概要などをしっかりと書き出し、
CodeBuildで執筆原稿データをまとめた - ヤマムギ
今書いている原稿に対して編集者さんから、「できればで構わないのですが、章ごとにマージしたデータでいただけますと助かります…！」とのリクエストがありまたので、CodeBuildでまとめました。 執筆環境(PyCharm, CodeCommit, CodePipeline, S3, Lambda, 署名付きURL)の環境で執筆をしています。 PCだけでなく、iPhone、iPadからも執筆しますのでマークダウンファイルは細かくわかれているほうがやりやすかったりします。 今書いている原稿は節ごとに分けています。 ですが、この場合編集者さんは1ファイルづつの校正や作業が必要になるのでしょう。 とはいえ、私は執筆の原稿単位を変えたくありません。 ということでCodeBuildにまとめてもらうことにしました。 CodeBuildの設定 ビルドプロジェクトを作成しました。 任意のプロジェクト名を入力しま
伝わる文章 | 基本要素 | SmartHR Design System
相手に誠実に、わかりやすい文章を書くための心がけをまとめました。 どういう思考プロセスからどんな表現が生まれるのか、参考として実例を紹介しています。実際に読み比べ、SmartHRの従業員として何かを伝えようとするときの、参考にしてください。 伝わる文章のガイドライン何を伝えるかによって、必要な情報の量や説明の粒度は異なります。 情報が不足していたり、逆に情報が多すぎたりすると、読者が意図を読み取れないことがあります。 読み手となる相手の状況（読む場面、事前知識など）を踏まえ、言葉にする内容や表現を厳選することが大切です。 目的に合わせて情報を取捨選択する読者の目線に立ち、コンテンツの目的に合わせて情報を取捨選択しましょう。 実例1：法律や業務に関わる記事目的業務に関係する「厚生年金保険」について正確に知りたいと思っている人に、わかりやすく内容を伝える。 Before日本の年金制度は、全国民
納品ドキュメントの作成にMarkdown+Vivliostyleを採用した話 - Qiita
こんにちは、製造業でソフト開発エンジニアをやっているとみー(@tommyecguitar)です。 会社で納品物の説明ドキュメントを作ることがあり、その時にMarkdownでの組版をやってみたので、どう運用したか、困ったところ、いい点、悪い点をまとめてみようと思います。 Vivliostyleで組版したブログはたくさんあるので、見た目がどんな感じにできるかなどはそちらを見ていただくか、Vivliostyleのサイトをご覧ください。 Wordじゃだめなのか。 製造業で何かしら長大なドキュメントを作るとなったら、大抵はWordを複数人数で編集するという運用をしているところが多いと思います。 しかし、Wordにはいろいろと悪いところがあります。 チーム内で共同編集すると、編集したところが消えたり、フォントやデザインがなぜか統一されなかったりする。 セクションごとに担当を分けても、マージが手作業にな
Vivliostyle：とにかくCreate Bookのサンプルをビルドしてみる（中編その1）
この記事は4つの記事で構成されています。（注意：中編が膨れ上がってしまったので、2つに分割しています） 前編：Vivliostyleで今度こそはじめる「Markdownで技術同人誌」 Vivliostyle、Create Book、Vivliostyle Flavored Markdown（VFM）の概要を紹介 中編その1：とにかくCreate Bookのサンプルをビルドしてみる ← いまここ インストール Create Bookのサンプルをビルドしてみる 中編その2：VFMの紹介 VFMを「GFMの記法」「GFMを拡張する記法」に分けて紹介 後編：技術同人誌を作って入稿用PDFをビルドする 同人印刷所の入稿要件を満たしてみる インストール まず必要なソフトウェアをインストールしていきます。 公式チュートリアルガイドによると、Create Bookの動作環境として次が挙げられています。 m
僕が考えた最強の作業手順書 - Qiita
某所で見かけたシステム運用作業手順書の記事に、「作業直前に作業手順書の変更はしない」「手順書に無い作業をしない」といった事が書かれていました。 いや、それはあくまで心掛けの話であって、それも大事だけど、そもそも作業手順書はどうあるべきかという話が抜けおちているのではないか？それは世間ではあまり明文化されていないのではないか？と思いました。 不遜ながら、私が思う作業手順書のあり方を書いてみます。 1. 存在している まさか、本番作業を勘とノリでやっちゃうなんて。まさかね… 2. 保存されている Githubでも、Google Driveでも、Notionでも、Wikiでもいいですが、作業手順書は保管されていますね？えっ？保存していなかったら、同じような作業をもう１回することになったらどうなるんですか？障害が起きて、デプロイ手順に問題がないか調査したい時にどうするんですか？ なお、保存するなら
見積・提案書に書いておくと不幸を減らせる前提条件
はじめに ちょっとつぶやいたら思いのほか需要がありそうだったので、簡単にまとめておきます。 おことわり これを書いておけば、すべての不幸を避けられるというものではありません 提出先との関係性次第では、書かないほうがいいこともあるかも 私自身が普段提案している内容が、すべて記載されているわけでもありません（うろ覚えで書いてたり、大人の事情） これを流用しておこったすべての事項について、何らかの責任をとることはできません 本稿では請負による開発を想定しています でも共有することで、この業界の不幸が減ればいいなということでつらつら書いてみます。 他にもあるようなら、Twitterなりコメントなりで提案してもらえると嬉しいです。 前提条件を書く目的 見積・提案書通りに、実施するために必要な条件を明確にする 条件を逸脱したときに、どうなるのかハッキリさせる 上記は概ねつぎのとおり 実現が不可能になる
開発者が考える提案書テンプレート markdown版 - Qiita
概要 定型的な システム開発 では以下のような設計書が使われる。 システム要件定義 システム方式定義 ソフトウェア要件定義 ソフトウェア方式設計 ソフトウェア詳細設計 しかしそれ以前に 開発者目線、開発者発信で顧客に提案する概要資料を作りたい ケースがある。あるいは就職活動時の自身のポートフォリオを採用担当に説明することも同様かもしれません。 オードリー・タンがコード書く前にまずreadme.txtを書く話、Yahoo!がプロダクト開発の最初にプレスリリースから作る話、自分が前職で商品企画する際にまず広告から考えていた話、どれも明確なゴールイメージをまず確定させて必要要件を定義していくという意味で全部共通の考え方 — 菅俊一 / Syunichi SUGE (@ssuge) February 2, 2021 なんて話も。 技術とマーケティングのちょうど中間、開発者と顧客との意思疎通の橋渡し
組織開発の意思決定透明化のために ODDR を試すことにしました | DevelopersIO
こんにちわ。てぃーびーです。 最近システム開発界隈でたまに話題をみかける「ADR」。 ADR は Architectural Decision Records の略で、アーキテクチャーの意思決定を決まったフォーマットで記録し続ける手法です。アーキテクチャーの意思決定後、時間の経過とともに当時のアーキテクチャーを設計した人が異動や退職で不在になり、後任が現在の設計を検討する上で、なぜ現状のアーキテクチャーになっているか確認したい、といったときがこの記録が活用される典型的なケースです。それ以外にも人の記憶は不確かなため、意思決定をした本人にとっても記録は便利です。 そういった必要性に関して niku さんの以下の記事が参考になります。 2020-05-19 ADR(Architectural Decision Records)を書くと決めた理由を自分の言葉で書き出した｜ヽ（´・肉・｀）ノ｜no
Hello World – React
この記事は古くなっており、今後更新されません。新しい React 日本語ドキュメントである ja.react.dev をご利用ください。 React の導入については新しいクイックスタートを参照してください。 const root = ReactDOM.createRoot(document.getElementById('root')); root.render(<h1>Hello, world!</h1>); これは “Hello, world!” という見出しをページに表示します。 Try it on CodePen 上記のリンクをクリックしてオンラインエディタを開いてください。好きなように書き換えて、出力にどう影響するのかを確認してみてください。このガイドのほとんどのページにはこのような編集可能な例が出てきます。 このガイドの読み方 このガイドでは、React アプリケーションの構
アーキテクチャの「なぜ？」を記録する！ADRってなんぞや？ - Qiita
5月のThoughtWorksのTechnology RadarでもADOPTされたADRという手法について、面白かったので、ざっくり自分なりに調べたメモです。 Technology Radarでは以下のように述べられています。 多くのドキュメントは、読みやすいコードとテストに置き換えることができます。しかし、進化的アーキテクチャでは、将来のチームメンバーの利益と外部の監督のために、特定の設計上の決定を記録することが重要です。Lightweight Architecture Decision Recordsは、重要なアーキテクチャー決定を、そのコンテキストおよび結果と共に取り込むための技法です。これらの詳細は、WikiやWebサイトではなくソース管理に格納することをお勧めします。そうすれば、コードと同期したままのレコードを提供できるからです。ほとんどのプロジェクトでは、この手法を使いたくな
なぜ私が議事録を書くのか？あなたが議事録を書く理由について解説 | DevelopersIO
データアナリティクス事業本部＠札幌の佐藤です。 議事録を書くこと好きですか？ 私がまだ入社間もないころによく指示されていた議事録を書くというタスクについて、昔は面白くなく、うまくできない作業で好きではありませんでした。 いまだに好きではありませんが、議事録を書くというタスクの意味についてなんとなく自分の中で腹落ちできていたのがひとつの要因だと思います。 今回は議事録の「書き方」について言及せず、なぜ議事録を自分が書かなきゃいけないのかという側面で明文化していきたいと思います。 あくまで私の経験によるものとなりますので、本来のあるべきからそれている可能性や、違うということもあるかと思いますがご了承いただければと思います。 また、当内容は議事録を取るという仕事をされている方を否定している記事ではありません。 あなたがなぜ議事録を取るのか 議事録を取る人というのは往々にして、その会議に参加してい
オープンソースドキュメント翻訳プラットフォームとしての GitHub (React 日本語ドキュメントの例)
はじめに ひょんなことから React 公式ドキュメント日本語版のメンテナをやらせていただいています smikitky です。 この記事は、React 公式ドキュメントの翻訳作業が GitHub ベースでどのように行われているのかを解説したものです。ドキュメントの翻訳には色々な方法がありますが、React の現アプローチは非常に上手く行っていると個人的に考えています。部分的には似たアプローチを説明している既存記事も探せばありますが、少し詳しめに書くことで事前の不安を取り除き、「思ったより簡単そうだから、自分もあのライブラリのドキュメント翻訳をやってオープンソースに貢献してみよう」と思えるようになることを目標にしています。 想定読者は Git、GitHub、Markdown（ないし類似の軽量マークアップ言語）、および基本的な HTML の仕組みがわかる開発者です。何らかの静的サイトジェネレー
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
proofdict
テクニカルライティングの基本
DMSF - Plugins - Redmine
GitHub - danmunn/redmine_dmsf: Fork of svn repository for redmine_dmsf
https://t.co/GyyZK5ds95