日本のリーダーはソフトウエアの本質を理解していない
ITには大いなる可能性と危険性があるが、結局はソフトウエアの問題に尽きる。ソフトウエアの構想、企画、設計、開発、保守のやり方をどう良くしていくのか。ソフトウエア人材の将来像はどのようなものになるのか。日本製ソフトウエアを輸出できないのか。 ソフトウエアについて様々な人が論じ合える場を用意し、多くの人に考えるきっかけを提供したい。そこで「ソフトウエア、それが問題だ～Software Matters」と題した本連載を始め、この中で、ソフトウエアの諸問題と対策を日本や世界の論客の方々、そしてITpro読者の皆様と考えていく。ソフトウエアに関するご意見をお寄せいただきたい。 第1回として米カリフォルニア大学バークレー校のRobert E.Cole（ロバート・コール）名誉教授に寄稿いただいた。コール氏は、日本の作業組織の研究で知られる。ミシガン大学社会学及び経営学の教授を務め、日米自動車の製品品質の
【社内資料公開】運用手順書を作る時のポイントについて書いてみた | DevelopersIO
はじめに こんにちは植木和樹＠上越妙高オフィスです。本日は私がここ10年くらい意識している運用手順書を書くときのポイントについてまとめてみました。 対象読者 開発・構築したシステムを別の人に引き継ぐ予定のある人 他の人が作ったシステムを引き継ぐ担当の人 半年後の自分でも分かる手順書の書き方に困っている人 （この記事を読むのにかかる時間の目安：5分） 1. ドキュメントの冒頭に書くこと まず個々の詳細手順の前に、ドキュメント自体について記載してもらいたいことです。 1.1. ドキュメントに書かれていることを3行で書く ドキュメントの最初には、このドキュメントに何が書かれているのかを100文字くらいで書いておくと良いでしょう。 システムが増えれば増えるほど手順書も増えていくものです。見つけたドキュメントに自分の期待するものが書かれているのか、冒頭数行でわかるようになっているとうれしいです。 1
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
