Category Archives: 開発プロセス

SaCSS Special06に参加してきた

SaCSS Special06 に参加してきました。
SaCSS Special06 : LOVE DESIGN SaCSS 【新潟グラム × SaCSS コラボ企画】

SaCSS ってのは札幌で開催されている勉強会で、主にコーダーやデザイナー向けのものです。詳しくはこちら。
SaCSS – 札幌のウェブデザイナー・コーダー向け勉強会・セミナー
サーバやプログラムを本業にしようとしている自分にとっては畑違いなのですが、当面は1人になるし、ブログの見栄えもちゃんとしたいし、ってことでフロント側の勉強会にも積極的に参加していこう、っていう訳です。そんな訳で、自分の PC には Adobe … みたいのは Reader ぐらいしか入っていないにも関わらず参加させてもらいました。

Continue reading SaCSS Special06に参加してきた

そのチームでの情報共有はどのツールで行うか

“Michael氏とPeter氏はその結果から構成に基づいたチームのための推奨をまとめた。彼らは、チーム構成、進捗報告の必要性に基づいて、有形のツール、Webベースのツール、それら2つの組み合わせのどれが必要になるか、以下のように結論付けた。”

InfoQ: アジャイル界隈ではシンプルなツールが好まれる
チーム運営ツールについての話。アジャイルチームの場合、と言っているが、普通のチームでも当てはまると思う。特定の製品を比較しているのではなく、Web ツールとスプレッドシート、有形のホワイトボードなどを比較している。
昔はチーム内での情報共有と言えばホワイトボードだったんだよね、たぶん。今でも外出や休暇の情報を共有するために使っているところは多いと思う。Web 化するのは簡単そうに思えるが、パッと目に入ってくるホワイトボードと同じ浸透度を保った Web ツールを作るのは意外と難しいと思う。
MS のオフィスが世界中に広まって、情報共有のために Excel を使うことが非常に多い。スキルの差こそあれ、大多数の人が説明なしに使えるツールというのは他のツールにない利点だ。ただし、その点でもホワイトボードに勝っているわけではない。それでもホワイトボードよりも広まったのは、保存のしやすさや遠隔地に情報を渡しやすいという点が大きいのだと思う。
しかし Excel は単一のファイルに全てが詰まっており、遠隔地にその情報を伝えるには複製をやり取りしなければならない、という特徴がある。それはバックアップを取りやすいという長所にもなるが、最新版の管理が難しいという短所にもなる。
と言うわけでデータはサーバという特別な場所で集中管理しましょう、って方向のツールが Web ツールだ。ここでは Web ツールと言うが、別にブラウザ経由でなくてもいいと思う。というか、Web になったのは最近で、昔は Java とかで専用アプリを作っていたはずだ。集中管理、という点がスプレッドシートからの進化だ。
このように、管理ツールは徐々に進化してきたかのように思えるかもしれないが、単にチームの形態が変化してきて、ニーズが変化したことによるツールの変化かもしれない。もちろん、それぞれのツールは進化していると思う。
というわけで、リンク先のどんなツールを使うべきかって表。チームの特性に対するクライアント等への進捗報告が必要か否かっていう観点で、どんなツールを適用すべきかってのを表している。これはアジャイルのための話ではない。

技術的負債という言葉にグッときた

“それは、全ての「あなたが今は、やらないと決めた内部的 なことで、しかし、そのままにしておくと、将来の開発を妨げるもの」である。[Ward Cunningham]。表面的には、アプリケーションは、高品質で、いい状態にあるように見えるが、これらの問題がその下に隠れている。QAは、アプリケーションは、良い品質で、ほとんどバグが無い、と言いさえするかもしれないが、それでも負債は、存在するのである。もしこの負債を管理せずに、減らしもしないと、コードを書いたり、保守したりするコストが、結局は、顧客への価値を上回ることになる。”

InfoQ: 技術的負債、マネージャの視点
「技術的負債」、っていい表現かもしれない。アジャイル的なキーワードと付いているけど、開発全般に言えることだと思う。
記事では技術的負債の増える要因がいくつか挙げられているが、中小企業が陥りやすいのはこれだと思う。

“経験不足の開発者 – あるプロジェクトでは、何のトレーニングも受けずに、あるいはオブジェクト指向プログラミングでは、どうコードを書くべきかを知らない開発者が Java/C#/Rubyで書いている。結果として、彼らは、慣れている言語、すなわち、 Visual Basicなどに相応しい書き方で書き続ける。”

InfoQ: 技術的負債、マネージャの視点
中小の企業では、なんとなくできる人が案件に投入されてしまいがちです。しかし、しっかりした仕事をしてもらうには、しっかりした知識・技能が必要です。Web で検索して解決できることを言っているのではありません。検索して得た知識をいかに実装するか、という話です。
というわけで、技術者としてしっかりした仕事をしたいなら、本質的なところを学ばなければならないよなぁ、って再確認しました。

アジャイルとか開発のトレンドについて話を聞いたらしい

InfoQ: プラクティスの現状 – 2010
Better Software、Agile West というソフトウェア開発に関するベストプラクティスについてのカンファレンスにて、色々な人に話を聞いたまとめ。

“「道に迷った」アジャイルに関するさらに興味深いコメントのいくつかは、あまりにも多くの支持者たちは本当に何が重要で、何が重要でないのかを認識出来なかったという事実に注目した。「かんばん対スクラムの議論は単に見当違いであり、アジャイルは特別なプラクティスやプラクティスのまとまりではなく1つの概念です。」「アジャイルは学ぶことであり、儀式やプラクティスを覚えることではありません。」”

InfoQ: プラクティスの現状 – 2010
アジャイルは方法論ではなく概念なんだとさ。だから、かんばん方式とスクラム方式を比べること自体が見当違いなんだとか。そもそも、「今回の開発はアジャイルで進めよう」って発言自体がおかしいってことかな?
『アジャイルは学ぶこと』ってのもいいフレーズですね。あんま意味分かってないけど。ただ、アジャイル的な方法論は色々あるけど、どれを適用するかは難しい、ってのは感じるところです。
もうひとつ。

“回答者たちで共有したもっとも注目すべき意見は、プロフェッショナリズムに対するたった1つの最大の障壁が、実現できない、不可能だ、倫理に反するなど実践者たちが、ノーと言えないことであった。”

InfoQ: プラクティスの現状 – 2010
ソフトウェア開発者はプロフェッショナルなのか、という問題。プロフェッショナルでありたい、ってのは希望です。
じゃあ、医者とかと比べてどうなんだ。医者は知識と経験、倫理を基に処置を行うか否か決定を下し、実践します。けれど、ソフトウェア開発者はプロジェクト内での地位があまり高くないのでノーとは言えない。ってことかな?
ちゃんとノーって言える人がプロフェッショナル?たぶん、そうじゃない気がする。
あと、原文のコメントが面白かった。

“So I understand what the assertion that “agile is mainstream” means: Agile has become the new Waterfall! “

InfoQ: State of the Practice – 2010
アジャイルがメインストリームであるという主張は、アジャイルが新しいウォーターフォールになったってことか、って感じかな。なんでかって言うと、彼らがやっていることは『ウォーターフォールとデイリースタンドアップミーティング』だからだそうな。
まぁ、社会がウォーターフォールだから、そこが落とし所な気がする。