rochefort10

ITシステムソフトウェアエンジニア、ベルギービール、トランペット。

rochefort10

ITシステムソフトウェアエンジニア、ベルギービール、トランペット。

  • 父親のPTA活動奮闘記

    訳あってPTA活動を勤めざるを得なくなった父親。熱心な教職員や親切なママさんのお陰で、結果楽しく過ごせたんだけど、想定にない理解できないことは、やっぱり、たくさん起きた。そんな、三年間のPTA活動で起きたり知ったり気づいたりしたことをあれこれ、書いてみたい。

  • 「ソフトウェア開発 201の鉄則」の各鉄則を４行でまとめる

    ソフトウェア開発のバイブルと言える名著「ソフトウェア開発　２０１の鉄則」。30年以上のソフトウェア工学の知見をもとに出版。そして、その後著しく進化した現代でも全く色あせないそれぞれの教訓を、現代のソフトウェア開発のトレンドに照らし合わせながら「４行で」言い表してみることにします。

  • IoT (Internet of Things)

  • 海外渡航

    海外での体験、出来事を、つらつらと。

  • エンジニア

    ソフトウェア、 ITエンジニアあれこれ。

父親のPTA活動奮闘記 Vol #3 ~ ママさんのパソコン操作

PTA活動は、年に二度の会報作成と発行をやる「会報委員」の副委員長で始まった。ママさんメインのPTA活動で、自分の居所とか立ち位置あるんかな、と、ものすごく不安に思ってのスタートだったが、全くもって杞憂だった。それは、一瞬で決まった。 諸々のパソコン作業。 失礼な言い草なんだけど、ママさんたち、いわゆる「パソコン音痴」だらけ。断っておくが、決してけなしたり、バカにしているいる訳では、ない。普段使わないんだから、仕方ない。 おれは一応エンジニアで、業務で一日十時間くらいパ

rochefort10

    • 父親のPTA活動奮闘記 Vol #2 ~ 黒一点

      紅一点の反対語。あまりポピュラーな言葉ではないようだ。PTA活動は、典型的な「黒一点」の世界。 高校生になって以来三十年以上、男が圧倒的に多い集団で過ごしてきた。男が圧倒的に多い進学校で男子クラス。大学は工学部。そしてメーカーで研究開発部門。もう圧倒的に男性が多い環境で、職場なんかは男60人に秘書さん一人なんてこともあった。 PTAの集団は、それが一気に、逆。初の会合に行ったら、ママさん40人くらいに、男性は自分と、PTA会長（なぜか会長は男性なんですね）の、二人だけ。

      rochefort10

      • 父親のPTA活動奮闘記 ~ はじめに

        卒業した。長男が高校を。同時に、父親のオレがPTA活動を。 三年前。訳あって、ヤツの高校のPTA活動を勤めざるを得なくなった。ヤツが中学校を卒業するまで、授業参観や面談、学校の行事には積極的に参加していたけど、PTAだけは、逃げ回ってていた。 そりゃそうだろう。そもそもママさんの世界だし。そのママさんだって疲弊するくらいの面倒臭い世界らしいし。とにかく、いい話を聞いたことがない。だから、ヤツの高校でやらざるを得なくなった時は、ホンマに戦々恐々だった。 先に言ってしまうと

        rochefort10

        • ソフトウェア開発201の鉄則 原理109:コーディング:原理100:構造化されたコードは必ずしもよいコードではない

          要旨* 構造化プログラミングは、もともとは、プログラムの正しさをカンタンに確かめることができるように提唱されたものだ * 今では、そのときに定義された条件分岐やサブルーチンなどを使うこと自体が構造化プログラミングと呼ぶようになった * プログラムをわかりやすくする、という点で、構造化プログラミングは必要だ * しかし、それは「高品質なプログラミング」の一部の要素であって、十分条件ではない 解説1969 年に、ソフトウェア工学ではしばしば名前の出てくるDikstra さんが提

          rochefort10

        父親のPTA活動奮闘記 Vol #3 ~ ママさんのパソコン操作

        rochefort10

        マガジン

        • 父親のPTA活動奮闘記
          3本
        • 「ソフトウェア開発 201の鉄則」の各鉄則を４行でまとめる
          88本
        • IoT (Internet of Things)
          3本
        • 海外渡航
          3本
        • エンジニア
          4本

        記事

          ソフトウェア開発201の鉄則 原理109:テスティング:自分のソフトウェアを自分でテストするな

          要旨* デバッグやリグレッションテスト、確認のための単体テストといったもの以外の、本格的なテストをソフトウェア開発者は自分で行ってはならない * テストというのは、バグが見つかって欲しくないと願う開発者に対し、バグを見つける、という行為なので、自分で行ったら正しくできるはずもないからだ * そして、テスト担当者は、発見したバグを皆の前にさらして、開発者の面子を潰すようなことをしてはならない * テスティングというのは、バグがでないことを期待する開発者に対し、精神的に追い打ちを

          rochefort10

          ソフトウェア開発201の鉄則 原理109:テスティング:自分のソフトウェアを自分でテストするな

          rochefort10

          ソフトウェア開発201の鉄則 原理75:設計:保守が容易なように設計せよ

           要旨*ソフトウェアで最もコストがかかる工程は、「保守」である * なので、保守が容易となるように設計をせよ * その方法に、一般的なものはない * 例えば、基本構造の選択時に、アルゴリズムやコードの選択よりも保守性を重視する、といったことが挙げられる 解説ソフトウェア「以外の」製品、要するにハードウェアは、設計後最も費用がかかるのは、「生産」。なので、ハードウェア設計の際に一番考慮しなくてはならないのは、生産性。 ソフトウェアの場合、生産にはほとんど費用がかからない場合

          rochefort10

          ソフトウェア開発201の鉄則 原理75:設計:保守が容易なように設計せよ

          rochefort10

          ソフトウェア開発201の鉄則 原理126:コーディング:エラーを個人のものにするな

          要旨* ソフトウェア開発というものは、本来は、人類未踏の「詳細さ」「完璧さ」を求める行動である * なので、（間違いがつきものの人間である）開発者は、完璧さを求めるのではなく、エラーが発生することを前提に、継続的な改善ができるように努力すべきである * そのためには、エラーが発生したら、それを隠すことなく、オープンにして皆で共有しよう * それは開発者全員の知見に繋がり、継続的な改善の工場に繋がる 解説この原理、二つ、大事なことを言っている。 1. 間違いが一つもない、完

          rochefort10

          ソフトウェア開発201の鉄則 原理126:コーディング:エラーを個人のものにするな

          rochefort10

          ソフトウェア開発201の鉄則 原理76:設計:エラー修正が容易なように設計せよ

          要旨* どんなに経験を積んでも、ソフトウェア開発では必ずエラー（失敗）を起こすものだ * なので、ソフトウェア設計には、エラー発生時にその発見と修正が容易となるような方法を組み込むこと * その実現は難しいが、例えば、変数の正当性のチェックは端折らずすべてやるとか、不可能な条件を想定しその施策を机上で練る、といったことが挙げられる ＊システムの不具合を体系立てて分析し、未然の改善を助けるための「フォレストツリー解析」もその一助となるだろおう 解説人はどんなに習熟しても「エラ

          rochefort10

          ソフトウェア開発201の鉄則 原理76:設計:エラー修正が容易なように設計せよ

          rochefort10

          ソフトウェア開発201の鉄則 原理147:管理:非現実的な完成予定日を設定するな

          要旨* 非現実的な納期(==無茶な計画）の設定は、社員の士気の低下、離職といった悪影響をもたらし、これらの発生によってさらに納期が遅れる、といった負のスパイラルを発生させる * ソフトウェア開発のプロジェクトの大帝が、このような「きつい日程」の計画のもと進んでいるだろう * そのような状況下での開発では、日程を間に合わせようとして品質の維持は後回しにされがちである * いいことは一つもない、プロジェクトを成功させたいなら、無謀な納期の設定はするな 解説ほとんどのソフトウェア

          rochefort10

          ソフトウェア開発201の鉄則 原理147:管理:非現実的な完成予定日を設定するな

          rochefort10

          ソフトウェア開発201の鉄則 原理114:テスティング:半分のエラーは15%のモジュールで発見される

          要旨* エラーの発生箇所は、システム全般で均一ではなく、大きく偏るものだ * エラーの8割がモジュールの5割から見つかるとか、もっと極端に8割のエラーが2% のモジュールから見つかった実例もある * エラーが見つかったところには、さらにエラーが見つかる確率が高い * なので、モジュール毎のエラー発生箇所を記録せよ、それは、システムの欠陥位置や欠陥内容を特定するのに役立つ 解説パレートの法則「全体の数値の大部分は、全体の構成のうちの一部が生み出している」、ソフトウェアの世界で

          rochefort10

          ソフトウェア開発201の鉄則 原理114:テスティング:半分のエラーは15%のモジュールで発見される

          rochefort10

          ソフトウェア開発201の鉄則:原理125:テスティング:エラーの原因を分析せよ

          要旨* ソフトウェアでエラーが発生すると、その検出と修正には大きなコストがかかる * なので、最初からエラーがないようにすることを目指すべきである * その実現で有効な方法は、エラーが発生したときに、なぜそのエラーが発生したかの詳細を分析して明らかにし、それを開発者全員と共有することだ * そうすれば、同じタイプのエラーが発生する確率は減るだろう 解説ここでいう「エラーの原因分析」とは、 「なぜエラーが発生したのか、そのエラーを防ぐにはどうしたらよかったのか」を突き止める

          rochefort10

          ソフトウェア開発201の鉄則:原理125:テスティング:エラーの原因を分析せよ

          rochefort10

          ソフトウェア開発201の鉄則 原理185:進化:ソフトウェアは変化し続ける

          要旨* ソフトウェアのシステムは、使われれば使われるほど、追加機能や変更点が生まれてくるものだ * なので、どんなソフトウェアでも、継続的な変更（＝＝変化）が発生するものだ * その継続的な変化は、最初から作り直すまで、ずっと続く 解説「ずっと変化し続ける」というのは、「ずっと使われ続けている」ことの証でもある。変化に対応しなくてなならないコストと引き換えではあるが、喜ばしいことだ。 昔の組み込みソフトウェアでは、最終リリース版を、内容を書き換えることのできない「マスクR

          rochefort10

          ソフトウェア開発201の鉄則 原理185:進化:ソフトウェアは変化し続ける

          rochefort10

          ソフトウェア開発201の鉄則 原理138:管理人は思いもよらない動機で仕事をしている

          要旨* 他人がどんな同期で仕事をしているかは人それぞれで、自分とは決して同じではない * そして、人の動機付けになっていることを知るのは、むずかしい * なので、管理者として開発者の動機づけのための行動も、難しい。ある人には効いても、ある人にはうまくいかないこともある * 人の動機の内容をよく知るには、人の話をよく聞くことだ 解説実際に私の周囲にいたソフトウェア開発者に聞いた、「仕事の動機」を挙げてみる。 * モノづくりが好き * 他人に出来ない専門的な技術を活かせること

          rochefort10

          ソフトウェア開発201の鉄則 原理138:管理人は思いもよらない動機で仕事をしている

          rochefort10

          ソフトウェア開発201の鉄則 原理111:テスティング: テスティングは結果の存在をあらわにするだけだ

          要旨* テスティングは「欠陥を発見」するためのものである * テスティングは、「欠陥がない」つまり「正しい」ことを証明するものでは、決して、ない * テスティングを重ねた結果欠陥がない場合、「正しい確率」は確かにあがるが、それは「正しいことの証明」には決してならない * 正しさを証明するのは、テスティングではない、別の手法が必要 解説「悪魔の証明」をご存知だろうか。ある事実・現象が「全く無い(無かった)」というような、照明するのが非常に困難な命題を証明することだ。 「ある

          rochefort10

          ソフトウェア開発201の鉄則 原理111:テスティング: テスティングは結果の存在をあらわにするだけだ

          rochefort10

          ソフトウェア開発201の鉄則 原理129:管理:読んだことのすべてを信じるな

          背景* 人は、自分の信じることを支持する情報やデータを集めたがるものだ * なので、「この手法で生産性は95% 上がる」といった情報は、その情報の発信人の支持するデータや情報で説明されていることがあるので、一意に信じてはいけない * このような極端な意見は、実際にあったが例外的な事象であることがほとんどだ * なので、見聞きした情報は、盲目的に信じるのではなく、きちんと裏を取ってから受け入れよう 解説まぁ、なんと。世の中、この手の情報が溢れていることよ。 この書籍が出版さ

          rochefort10

          ソフトウェア開発201の鉄則 原理129:管理:読んだことのすべてを信じるな

          rochefort10

          ソフトウェア開発201の鉄則 原理128:管理:適切な解決策を用いよ

          要旨* 技術の問題には、技術的な解決策が必要 * 管理の問題には、管理的な解決策が必要 * 政治の問題には、政治的な解決策が必要 * 問題に対して、適切な解決策を施そう。マッチしない解決策では決して解決しない 解説何か問題が起きたら、解決しようとする前に、問題を的確に捉えた上で、正しい、あるべき解決策は何か、をまず明確にするようにするといい。 仮に、それが非現実的でも、いい。まずは、「あるべき姿」を明確にしよう。 で、次に、現実その正しい解決策が取り得るか、を検討しよう

          rochefort10

          ソフトウェア開発201の鉄則 原理128:管理:適切な解決策を用いよ

          rochefort10