良い名前をつけること

思考メモ

組織の設計や、制度の策定を考えている中で、もっとも悩むのが名前付けで、良い名前がバチっと決まったときは、その制度の運用を始めてもうまくいくことが多い。

プログラミングでも名前付けはとても大事。変数名、クラス名、テーブル名、様々な場面で名前を付ける。適当につけてしまうと、後で読み返すときに苦労する。

名前を付ける行為は、そこにあるはずの概念を言葉で掴み取ることだ。名前を付けられないとしたら、まだ本質を理解できていない。これはソフトウェア設計における重要な指針になる。

… もっと見る

組織の設計や、制度の策定を考えている中で、もっとも悩むのが名前付けで、良い名前がバチっと決まったときは、その制度の運用を始めてもうまくいくことが多い。


プログラミングでも名前付けはとても大事。変数名、クラス名、テーブル名、様々な場面で名前を付ける。適当につけてしまうと、後で読み返すときに苦労する。

名前を付ける行為は、そこにあるはずの概念を言葉で掴み取ることだ。名前を付けられないとしたら、まだ本質を理解できていない。これはソフトウェア設計における重要な指針になる。


うまく名前付けできたら、あたかも昔から決まっていたかのような感覚になる。なぜ、もっと早くに気付けなかったのかと思うが、よくよく考えるから名前を捕まえられる。

Rubyをつくったまつもとさんも「適切な名前をつけることができた機能については、その設計の8割が完成したと考えても言い過ぎでないことが多い」と仰っていた。


この感覚が、プログラミングというコード(ソフトウェア)のデザインと、経営という組織・制度(ソフトウェア)のデザインの名前付けにおける共通点と言える。

コーポレートガバナンスコードという言葉があるように、組織や制度を支える規則のこともコードと言うから、やはり私にとっては経営もコーディングなのかもな。

趣味としてのプログラミング

思考メモ

少しずつプログラミングを始めてる。ちょっとブランクあるからリハビリから。来年の新卒予定の学生たちと一緒に遊ぶ感じでやってる。

英語やスポーツ、楽器などと同じで、習うのも大事だけど、自分で練習して慣れることの方が上達には大事なので、毎日少しでもやる。

本当の初学者には、いきなり実用的なアプリより、動きのある方が楽しいし、変数の中身をイメージしやすいのでゲームを作っている。

最初のうちは理論などすっ飛ばして、チュートリアルを写経して、自分の書いたコードが動くのを楽し … もっと見る

少しずつプログラミングを始めてる。ちょっとブランクあるからリハビリから。来年の新卒予定の学生たちと一緒に遊ぶ感じでやってる。

英語やスポーツ、楽器などと同じで、習うのも大事だけど、自分で練習して慣れることの方が上達には大事なので、毎日少しでもやる。

本当の初学者には、いきなり実用的なアプリより、動きのある方が楽しいし、変数の中身をイメージしやすいのでゲームを作っている。

最初のうちは理論などすっ飛ばして、チュートリアルを写経して、自分の書いたコードが動くのを楽しむところから始めるのが良いかな、と。

動いた状態から少しずつ変えたりして、コードの意味を理解していけば良い。まだ正確な文法やコードの作法、保守性などは気にしなくて良い。

プログラミングは、実体のない活動なので、いくら失敗しても一円も原価はかからない。むしろ試行錯誤して動かすまでに楽しさがある。

そんな風に、まずはプログラミングが楽しいし、怖くないというように感じられるところから始めるのが良いのではないだろうか。

プロ野球選手もプロのミュージシャンも、みんな最初から職業を意識して始めた訳ではなく、見様見真似で遊ぶところから始めたはずだ。

そうした趣味で遊ぶようなプログラミングは、大人になってからも出来る機会があると良いな、と思う。休日の草野球やフットサルみたいに。

なにも職業としてやる人だけのものではないのは、プロ野球選手じゃなくても野球を楽しめるのと同じことで、プログラミングも楽しめると思う。

昨今の多くのプログラミングスクールは、転職や就職を目的としたものが多いけれど、そうでない大人のプログラミング教室があっても良いのに。

ただし、プログラミング教室に通ったところで、職業プログラマになるのは相当に厳しい。ピアノ教室に通ってもプロのピアニストにはなれない。

それで良いのだ。大人がピアノ教室に通うのはプロになるためよりも、自分の趣味や教養として、楽しむために通っている人の方が多いはず。

スポーツや音楽を少し嗜むだけで、プロプレーヤーの凄さがわかるのと同じように、職業プログラマの凄さを理解できるようになると世界は変わる。

そしてプログラミングの場合は、趣味の延長上でも普段の仕事にも活かすことができる。業務改善で自らプログラミングできれば素晴らしい。

経理の人がプログラミングを覚えたら、自動化して効率的に数字を出せるように、マーケの人なら自分でA/Bテストを組めるかもしれない。

いずれ多くの職業にとって、今のパソコンを扱うのと同じ程度のリテラシーとしてプログラミングが求められる時代がくるかもしれない。

業務の付加価値としてのプログラミングが広まる程に、プログラミングを専門にする職業プログラマの価値が高まっていくかもしれない。

そのようにプロとしてプログラミングをやっていこうとする人には、趣味の教室より長い時間と実践を積める本当の意味での学校があると良い。

もし、そんな学校を作るなら、お金さえ払えば誰でも受けれるのではなく、大学のように入学に試験があり、卒業にも判定があるようにしたい。

私はプログラミングが好きなので、プログラミングを楽しんでいる人を見ると嬉しくなるし、誇りを持って取り組んでいる人を見ると尊敬する。

誰もが音楽を楽しむようにプログラミングを楽しむ。一方で、専門のプロとして価値を生むには相当な技量が求められるからこそ尊敬される。

そんな世界が実現できたら良いな、と。

プログラマの仕事はコードを書くことか

思考メモ

プログラマの仕事を端的に表すときに「コードを書く」と言ったりするが、それによって単調な仕事だと勘違いされることがある。その誤解は、カメラマンの仕事を「シャッターを押す」だったり、小説家の仕事を「日本語を書く」と言うようなもの。手を動かしてはいるが、実際は頭を使うことが主な仕事だ。

ソフトウェアは、一つのアプリケーションが一つの作品のようなもので、一部の改変が全体に影響を与えることがあるし、一部に品質の悪さがあると全体の品質を落としかねない。製造業のように同じものを沢山つくる訳 … もっと見る

プログラマの仕事を端的に表すときに「コードを書く」と言ったりするが、それによって単調な仕事だと勘違いされることがある。その誤解は、カメラマンの仕事を「シャッターを押す」だったり、小説家の仕事を「日本語を書く」と言うようなもの。手を動かしてはいるが、実際は頭を使うことが主な仕事だ。


ソフトウェアは、一つのアプリケーションが一つの作品のようなもので、一部の改変が全体に影響を与えることがあるし、一部に品質の悪さがあると全体の品質を落としかねない。製造業のように同じものを沢山つくる訳ではないから、多少の不良品を許容するような作り方はできない。製造でなく設計なのだ。


コードを書くことを単純作業だと誤解した経営者は、より多くのソフトウェアを製作するために人を増やせば良いと考える。しかし、実際には闇雲に人手を増やせば、むしろ全体の生産性を落としてしまうことになる。まさしく『遅れてるプロジェクトへの要員追加は、さらに遅らせるだけである』の言う通り。


沢山の人を入れても混乱せずに生産性と品質を出せるようにと考える勢力と、人を増やさず少人数のままで一人当たりの出来ることを増やして生産性と品質を高めるように考える勢力がある。抽象化や仮想化を重ねるソフトウェア技術の進歩の方向性は後者だと思うし、エンジニアの気持ちとしても後者を望む。


ソフトウェアをチーム開発していくなら、ソースコードの設計に対するポリシーや品質の価値観を揃えること、その上で少人数チームを維持すること、人の増員を単純な足し算で考えないことなど、ソフトウェアの本質とエンジニアのモチベーションについて深く理解した上でマネジメントしていく必要がある。

ページ 1
ページ上部へ