社内のドキュメンテーションの取り組みと、Kitenのご紹介 - Pepabo Tech Portal
はじめに 技術部の @june29 と申します。最近の趣味は「お散歩」で、よく晴れた休日には妻といっしょに2時間くらい歩き回ったりしています。この記事では、わたしが2020年から力を入れて取り組んでいる社内におけるドキュメンテーションの活動の一部を紹介したいと思います。 問題意識 もともと、ペパボで働く人々には「書く」という行為が定着しています。現在利用中のサービスを見渡してみると、GitHub、Slack、Google Docs、Scrapbox、Notionなどがあり、常に積極的な読み書きが行われています。 しかし、ドキュメンテーションという観点から見て、すべてが理想的にうまくいっているとは言えない状況であるとも思っていました。具体的には、下記のような課題があると感じていました。 書く場所が何種類もあり、どこになにが書かれているかがわかりにくい 場所ごとにアクセス制限が行われており、ど
Markdown と GitHub で社内規程を便利に管理 - クックパッド開発者ブログ
VP of Technology の星 (@kani_b) です。技術基盤や研究開発領域などを担当しつつ、社内の色々なことを技術の力でいい感じにする仕事をしています。セキュリティや AWS の話が好きです。 さて、みなさんは、ご自身が勤務する会社の就業規則を読んだことはあるでしょうか。 エンジニアに限らず、会社の全スタッフが仕事をする上で関わってくるのが、就業規則や情報セキュリティドキュメントなど、会社のルールや規程を記す文書です。 特にセキュリティやインフラに携わるエンジニアは、その改訂も含め携わったことがある方もいるのではと思います。 よくある文書管理 こうした文書は、以下のように管理されていることが多いようです。 ベースドキュメントは Word 保存時は PDF で保存 版管理は Word の編集履歴 + PDF に保存する際のファイル名 編集は担当部門, 担当者のみが行う かつての
技術文書を書くための７つのルール
技術文書を書くための７つのルール¶ さまざまな面から見て、良いドキュメントを書くことは、良いコードを書くよりも簡単です。多くの開発者はドキュメントを書くのはとても難しいことであると考えていますが、いくつかのシンプルなルールに従うだけで、本当に簡単になります。 ここでお話しするのは、ポエムの本を書くための方法ではなく、プログラムの設計やAPI、コードベースを作り上げる上で、必要となるものを理解するための包括的なテキストを書くための方法になります。 全ての開発者はそのようなテキストを書くことができます。本節ではあらゆる場面で適用できる7つのルールを提供します。 ２つのステップで書く: まずはアイディアにフォーカスし、その後レビューを行ってテキストの形を整えます。 読者のターゲットを明確にする: それを読むのはだれですか？ シンプルなスタイルを使用する: 分かり易くシンプルに保ちます。正しい文法
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
