twitter icon   twitter icon   rss icon

Linux.com Japan

Home Linux コミュニティ ブログ

ブログ

ブログ別アーカイブ l 未来のいつか l Android/OPhone雑記 l l
l アジアのペンギン l 烏龍の旅 l 第三のペンギン l TOMOYO Linux l

 

新着記事



レガシーコードは南斗聖拳(外から攻める)。新規開発は北斗神拳(内から攻める)、レガシーコード改善ガイド読書会ふりかえり

社内テスト勉強会でレガシーコード改善ガイド読書会の報告をした。 読書会を地味に開催してテストの価値観を共有できたのは非常によかった。そして実際、自分のプロジェクトに試してみた人たちの報告もあった。 一方で社内読書会の課題も見えてきた。やはり、参加者のスケジュール調整が難しいこと、少しずつ参加者が減ってしまうことなどである。皆忙しいし、時には突発のトラブルでスケジュールどおりに参加できない事はある意味致し方ない。忙しいと読書会どころではなく、それに参加しつづけるモチベーションの確保も難しい。*1 レガシーコード改善ガイド読書会View more presentations from Hiro Yoshioka. 今あるレガシーコードとどう向き合うか...
続きを読む...
 

勉強会カンファレンス2010に行ってきた

勉強会カンファレンス2010*1に行ってきた。そこでの感想など。 勉強会のメソッドは勉強会の数だけある。共通の問題もあればその勉強会固有の問題もある。それぞれの問題を出し合って、みんなでその解決策を議論するという方法は大変有効な方式だと再認識した。 最後のセッションで、岩切さんが、自分の困っていることをプレゼンしていて、そこからいろいろな議論が湧き上がってきて、非常に盛り上がったが、あんな感じのセッションがわたしにとって理想的な形だと思った。 岩切さんの困っていることというのは、ざっくり言うと、カンファレンスを開いても一列目、二列目の人たちは、笑いもしないし、ぴくりとも動かないし、隣の人といきなり話を始めて、何かを持ち帰っていこうというような感じの人がほとんどいない。それを聞きにくる人を巻き込んで、何かをしたい、だけど日本人だからそれができないかというと、DevLOVEなんかにいくと、とってもいい感じで盛り上がっている。自分が主催するセミナーでそれをやるにはどうすればいいんだろう、というようなことだと理解した。 わたしが、「細かいことは気にしない」という発言をしたあと、会場を交えていろいろな意見が飛び出し、そのライブ感が非常に素敵だった。人を巻き込むというゴールをいかに達成するかという問題に対しては、気にしないというのは解決でもなんでもないのだが、喧々諤々の議論が始まる導火線のような役割をはたした。 様々なアイデアは、会場に桜を仕込んで、いくつか質問をしてもらう。休憩時間を長めにとって、飲み物、お菓子などをふるまい、そこから横のつながりを広げる。個人名刺を作り、裏には、自分の興味のある分野とか個人史を書いて、ここにいるのは誰だということを示す。ネームプレートに興味のある分野を記す。共通の話題を見つけるために、どのようなことに悩んでいるかを挙手を求める。*2 自分も会社で勉強会を開くと、場から質問があんまりでなくて、ちょっと寒い感じがあるし、それをどうにかしたいという思いは一緒なんだけど、「よしおかさんは特別だから…」と、言われちゃったりして、それを松井さん(R社の中の人)に振ったら「わたしも人を増やすにはどうしたらいいんですかねって昔よしおかさんに聞いたら、『そんなことは気にしなくていいんだよ』って言われました」(場内爆笑) ひとそれぞれレベル感の違いがあるとしても抱えている問題というのはあって、それは勇気を出して表現することによって共有でき、共有することによって様々な解決案を考えられる。その問題を解決するのは結局は一人一人なんだけど、同じ問題で悩んでいる仲間がいるということを知るのは貴重な体験である。自分は孤独ではなかったということを知るのは重要だ。 勉強会カンファレンスという場の価値の一つにこの問題の共有というのがあると思う。 海外のカンファレンスでは、あんなに議論が盛り上がり、質問もいっぱい出るのに日本ではまったくそれが出ないというのはなんでだろう。という問題設定があったとき、「日本人の国民性として」とか、ほげほげだからという人のせいにする、あるいは自分が解決できない問題のせいにする人というのは多いが、それは問題の解決にはなんにもならないし、むしろ有害ですらある。自分が達成したいゴール、この場合、カンファレンスで質問ががしがし出るという状況をどう作るか、という問題をみなでどう解いていくか。それをみんなで議論するという方が生産的だし、なによりも楽しい。...
続きを読む...
 

テストは誰が書くのか

昨日のエントリの補足的なもの。id:hyoshiok:20100612#p1 テストは誰が書くのか。もちろんコードを書いた人が書く。コードは誰が書くのか。設計をした人が書く。誰が設計をするのか。要求を分析した人がする。このように一つの機能について一人が責任を持って行うのがベストプラクティスになっている。 ところが、日本のソフトウェア産業の8割以上は受託開発と言われているが、そのような現場では誰かが一貫してすべての工程に責任を持つということは普通行われていない。工程を上流下流とわけ、いわゆる一次受けと呼ばれる大手SIベンダーが要求分析をし、その下に設計実装する下請け、孫請けを持つという多重構造になる。 要求分析をして、仕様にまとめるわけであるが、実装のコスト(実装のしやすやしにくさ、実装工数の大きさ)はほとんど考慮されない。契約文書として、これこれを実装することみたいなものがあらかじめ取り交わせられる。開発期間中に仕様の変更はさらなるコストアップになるので、行われない。行うことは悪であるというパラダイムになる。工程を別業者に発注する以上、契約という形で縛らないといけないので、これはある意味、必要悪の世界である。顧客のビジネス上の利益の最大化というのはお題目としてはあっても、構造上それを実行するのは、難しい。 このような構造にあるので、テスト容易なコードを書くというのは、現場のインセンティブとして生じにくい。テストを書く人とコードを書く人が分離されていれば、そのようなことになる。受託開発の場合、かかった工数に人月単価をかけて売上になるので、人月単価がかわらなければ、工数がかかればかかるほど売上がたつので、ここでも、工数削減というインセンティブは生じない。 結局のところ、ウォータフォール型の受託開発モデルでは競争力のあるソフトウェア開発を実践することは非常に難しいことになる。 一方で自社開発の場合は、仮に要求を出す部門と開発する部門が社内的には別々部門であったとしても、同じ会社なので同一の目標に向かって同じ目線で語ることができる。テストを書くことによって生産性が向上するとしたらそれは開発部門だけではなく、事業部門にとっても利益がある。事業部門にとってみれば、テストを書こうが書くまいが、提供されるサービスによって利益が上がればいいわけで、その意味で、必要な機能が提供されさえすれば満足度は高い。 アジャイルな開発方法論は、より素早く、品質の高いソフトウェアを生み出す方法論としてウォーターフォールモデルよりも優れている。少なくとも自社開発の場合は、ウォーターフォールモデルを利用する必然性はないと言ってもいい。 要求分析、設計、実装、テスト、運用など一つの組織が一貫して行うことで競争力を持つ。そのような環境の中ではプログラマの責任範囲は広いし、やりがいもある。 一人が要求分析から、設計、実装、テスト、そして運用についても見通せると、効率のよい実装、テストしやすい実装、運用に負荷がかからない実装というような観点から実装を見直す機会ができる。...
続きを読む...
 

第104回カーネル読書会のお知らせ

日時:6月17日(木)19:00開場、19:30時ころ開始(いつもより30分遅いです) お題:カーネル読書会会議 発表者:みんな 内容:久々にいきなりビアバッシュから始めます。カーネル読書会のこれからについて、風穴さんのMeeGoの話など、あれやこれや。 会費:1500円(ピザとビール代)、学生無料。 19:00頃 開場、LTないし自己紹介など 19:30頃 お題開始。ビアバッシュ。 20:30頃 懇親会開始 21:30頃 中締め 場所は楽天タワー...
続きを読む...
 

テストを書くこととテストをすることの違い

会社でレガシーコード改善ガイドの読書会をやっていて、次回で読了だ。4月に入ってから週に1回くらいのペースでやっていて、2ヶ月半くらいかかった。途中、ゴールデンウィークや所用で開催しないこともあったので、10回くらいで完走したことになる。 一人当たり、1章ないし2章くらいを担当して、その章に書いてあることを説明した後にみんなであーだこーだ議論をする。気になったことを質問したり、どうも良く分からないことをみんなで考えたりする。 テストがないコードはレガシーコードだ!というキャッチフレーズはわたしの心をとらえた。 参加者の皆さんとその価値観を共有できた事はうれしい。 現場での開発の実情をいろいろ教えてもらった。テストを書くことはあまり一般的ではないということにわたしは衝撃を覚えたのであるが、この読書会を通じて、テストを書かない開発というのがレガシーコードを作っている事に他ならないという共通の認識を得たことの価値は大きい。 システム変更の方法は、大きく2つに分けることができると本書は主張する。ひとつは、「編集して祈る」、もう一つは「保護して変更する」方法である。 編集して祈るというのが残念な事に業界標準になっている。つまり変更作業をして、その機能を何らかの方法で確認して、周辺もざっと調べて特に問題がないことを確認して、結果がうまくいくことを祈るという方法である。祈るのである。 一方の保護して変更するというのは、足場を組んで、転落防止の柵や網をはって、転落しないようにしたり、万が一転落してもセーフティーネットによって保護されるというようなものである。ソフトウェアで言えば、テストで保護するということである。テストプログラムによって、意図しない破壊が起こっていないことを確認するのである。 バグとテストとデバッグ バグというのはソフトウェアの期待する動作と実際の動作の差分である。期待する動作というのは、通常何かの文書、例えば要求仕様書などに、書かれているものであるが、そのような文書が存在しない場合もあるし、そもそも日本語で明確に書けないような非機能要件というのもある。まあ期待値との差が出たらそれはバグと考えるというのが大雑把な理解である。*1...
続きを読む...
 

ミラクルどら焼き

syoshidaです。お久しぶりです。 さて、MIRACLE LINUXは10周...
続きを読む...
 

Questetraワークフローシステムを導入しました。

4月からワークフローシステムを導入しました。以前からなるべく紙の処理を無くしたい...
続きを読む...
 

diary

00:00 おはようございます!00:02 Mac: Mac狙いのマルウェアに新たな亜種、iPhotoに見せかけ感染狙う - ITmedia エンタープライズ : http://www.itmedia.co.jp/enterprise/articles/1004/20/news019.html00:04 JQuery:...
続きを読む...
 

組み込みボードで学ぶ TOMOYO Linux(セキュアOS) 適用技術:独立行政法人 雇用・能力開発機構 高度職業能力開発促進センター(愛称:高度ポリテクセンター) −在職者訓練『組み込みボードで学ぶTOMOYO Linux適用技術』のご紹介−(情報元のブックマーク数http://www.apc.ehdo.go.jp/seminar/course/10semi22294.html)

ぉーーー!組み込みボードで学ぶTOMOYO Linuxですか。おもしろそうだなぁ。セキュリティ侵害に対する関心が高まっており、その解決策としてセキュアOSが使われ始めてきています。 出荷後の修正が難しい組み込み機器では、セキュアOSの有効性が高いと考えられています。本セミナーでは組み込み機器開発者向けに、セキュアOSに関する基礎としてSELinux及びTOMOYO Linuxについて解説し、実際に... 続きを読む...
続きを読む...
 

OpenOffice3.2は、なかなかいいよ。

Ubuntuユーザである私は、もちろんOpenOfficeを利用しています。 最...
続きを読む...
 
97 / 101 ページ
Linux Foundationメンバーシップ

30人のカーネル開発者

人気コンテンツ


Linux Foundationについて

Linux Foundation はLinux の普及,保護,標準化を進めるためにオープンソース コミュニティに資源とサービスを提供しています

 

The Linux Foundation Japan

サイトマップ

問い合わせ先

サイトに関するお問い合わせはこちらまで

Linux Foundation Japan

Linux Foundation

Linux Training

提案、要望

Linux.com JAPANでは広く皆様の提案、要望、投稿を受け付ける予定です。

乞うご期待!