徒然なるままに
前回のブログで書いた内容とは真逆の記事になる。
それだけ宣言して以下を書く。
書く目的を考えた。当初の目的はだんだん薄れてきたけれど、書き続けるモチベーションはまだ持続している。
それは公開記事を書くことで自分なりに得るものがあると感じているから。
ただその内容は自分をどう表現するかに集中したい。見てくれる人に役立つ内容なんてとても書けないし、それを目指すところに自分の居場所はない気がする。
結局のところそれほど自分のスキルはない訳で、しかもここは日記を書く場所であるということで、そう考えると気持ちも楽になるし書く意欲も継続できるというもの。
まだまだこれからも気持ちは揺れに揺れて、取り留めもない記事が量産されていくのだろうと思うが、それが日記とういうジャンルの良いところだろうと開き直る。
できればこういう取り留めもないことを毎日記事にして公開することが今後の自分の目標にしたいと考えて、今日の記事を締めくくる。
1ヶ月ぶりのご無沙汰と今後の展開
7月・8月と仕事が詰まって、結局8月は一度も書かずに過ごしてしまった。
これは言い訳だが、やはり一つの頭で幾つも考えを巡らせるということが如何に困難なものであるかとゆうことを実感した。
特に仕事はヤッパリ特別なもので、できるだけ頭をそちらに振り向けたいという思いがあって、ブログを書くことに悩む時間が惜しかった。
ようやく仕事がひと段落着き、さてブログをどうしようかと考えて、ヤッパリ続けたいという思いがあって今日の記事に繋がった。
ただ前と同じような記事の書き方を続けていても、成長がないし、折角だから少しでも前に進めた記事の書き方を模索しようと思っている。
以前は毎日書くということで続けるという習慣を身につけつつ、本当に続けられるかどうかを自分に問う気持ちもあった。
そこから取り敢えず続けたいという自分の意思を見出すことができたので、次のステップはより良い記事にしていきたいということだと考えている。
とにかくその場しのぎでもテーマを設定して短い時間でそれなりの記事が書けることはできるようになったので、そこからもう一歩踏み出して、もう少し中身のある話をまとめられたらと思う。
来週からまたブログに頭を悩ませる日々を送りたいと思う。
ルールは守るだけのものか
何をするにしてもまずルールを決めなくてはいけない。
複数の人が関わるものにはルールを設けておかないと意見の対立が常に起きてこちはスムーズに進まない。
だからルール作りは大切で、初めにこの取り組みがいい加減だと後々トラブルが頻発することになる。
しかしここからが問題で、一旦作ってしまったルールは何が何でも守るということが求められてしまう。
確かに苦労して決めたルールをそう簡単に変えてしまってはルールそのものの価値が失われてしまいかねないし、そうなったルールは誰も守ろうとはしなくなることは目に見えている。
かといって現実にそぐわなくなってしまったルールにしがみついて守ろうとするのはなんか変。
だからルールは作ることも大事だがそれをどう運用していくのか、それはいまの状況にそぐわなくなっていないか、常に監視して評価することの方がより大事なのではないかという気がする。
プログラミングの仕事でもルールはあって、コーディングルールや作業手順、履歴管理、認可など結構縛られている。
いままでの仕事のやり方であれば何の問題もなかったこれらのルールも、開発スピード重視に舵を切った途端足枷になることは大いにあり得る。
ルールに足を引っ張られる前に、ルールを変える勇気を持つことが必要だと考えている今日この頃。
躁と鬱の狭間
誰でもそうだと思うが、日々かるく躁と鬱の状態を行ったり来たりしているのではないかと思う。
それが振れすぎると病気ということになるのだろうが、ある程度は自分の気持ちの状態を認識して過ごしているのではないだろうか。
躁状態であれば仕事は捗る。集中力が半端ない。変な自信がついて何があっても問題なく乗り越えられると思っているし、積極的な自分に驚くこともある。
逆に鬱の時は、気持ちが沈んでどうしようもない。一人でいると寂しく、かといって大勢の中では自分が埋もれてしまって存在感のなさでまた落ち込む。
やる気も出ないし積極的にもなれない。取り敢えず酒でも飲んでこの鬱の気持ちを慰めるだけ。
ただ近頃はこの状態を自分なりに楽しめる様になってきている。今自分はどの状態にあるのか、躁であれば仕事は捗るぞと思い、鬱であればさらに落ち込む前に仕事を切り上げようと思う。
そうやって自分と向き合うことで日々の退屈な日常も面白く過ごせる様になる。何よりひどくなる前に手を打てる。
日常から自分と向き合うことの大切さを考えよう。
リーンスタートアップ
リーンスタートアップという開発手法がある。
最小限の製品を市場に投入して、ユーザーの声を聞きながら製品に磨きをかけていく。
開発から販売までのサイクルを速く回すことで、製品としての市場の価値を迅速に高めていく。
という考えなんだけど、なかなかそれが上手く回らない。
まず最小限の製品を投入するというところの線引きが難しい。
メーカーはどうしても製品価値をできるだけ高くするところから入ってしまうように思う。
最初に積み上げてしまうと機能を削ぎ落とすことに躊躇する。機能を削るというのはやはりマイナスのイメージが立つ。
それに市場にメーカーのブランドがあると、そこにもこだわりができて、これではブランドに傷がつくみたいな一種の見えみたいなものがあるのではないだろうか。
そうなると結局機能てんこ盛りの製品をリーンスタートアップという言葉に乗せて、出来るだけ早く市場に投入するという、開発する側にとってはあり得ない方向に向かってしまうことになる。
しかし日本のモノづくりの原点は結局そこにあるような気がする。
常に完璧な製品を目指す。すでに出した製品に肉付けしていくとうことはせず、市場の声に応える形で新たに製品設計からはじめて新製品を投入し続ける。
それが良いのか悪いのか。
少なくとも、製品のサイクルが短くなっていく現市場においては、かなり体力を消耗してしまうことになることは明らか。
もはや根本から考えを変えていく必要がある時代。
開発はスピードか品質か
たぶんこの二つには選択はなくてどちらもということになるのだろう。
しかし実際に開発する人間にとってはこの問いは切実な問題ではないだろうか。
もちろんどちらも実現できれば良いのだろうし、そういう開発手法なども色々議論されていることではある。
だが現実的には日本のメーカーは品質にこだわる傾向にあると思うので、製品出荷を伸ばしてでも品質を確保する側に倒れるのだと思う。
そうであれば初めから品質確保にどの程度の時間が必要かを見積もって出荷予定日を決めるものだろうと思うのだが、なかなかそうはいかない。
どうしても製品企画の段階でこの製品はこの日に間に合わせたい。そうしないとマーケティングで他社に勝てないという話になる。
であれば製品企画の段階でこの日に間に合うように製品を作るとしたらどのような仕様であれば可能か絞り込んで欲しいもの。
この時点で破綻するのは製品仕様は削れない、いや検討した結果競争力を上げるためにはこの機能を追加することが欠かせないという議論が開発現場を知らない人たちの間で盛り上がってしまうこと。
海外を見てみるとうまくやっているなと思うのが、まずそこそこの機能で製品を出してみる。その反応を見ながら徐々に機能をあげてファームアップデートで対応する。
そうしてユーザーを取り込んでいくのが素晴らしいと思う。
日本のメーカーにそれを望むのは今の所難しそう。
コーディングの醍醐味
基本的にコーディングという作業は地味で、パソコンの画面と向き合ってひたすらキーボードを叩くということなのだが、それでも幾つか醍醐味を味わうことができる。
一つはコンパイル。
今ではPCの性能も上がって、コンパイル時間に気を使うこともなくなってきているが、昔はコンパイルにかかる時間を考慮して、ある程度コーディングを終えてから一気にコンパイルを通すという手順を踏むことになる。
その際にコンパイルが一発でエラーなしで通った時の喜びはそれを経験した人にはわからないだろうと思う。そこに醍醐味を感じるのは自分だけだろうか？
もう一つの醍醐味は、プログラムが一発で思い通りの動作をしてくれた時、これこそ無上の喜びと言っていい。
これを究極に目指して喜びに浸りたいという一心でコーディングに励んでいる。
そう簡単なことではないのだけれど。
逆に一番挫折感を味わうのがいきなりの停電。
何度か味わったことがあるが、いいところまでコーディングが進んで、そろそろセーブして一息つこうとしていたところで停電が起きると頭が真っ白状態。
それまでの数時間の努力が一瞬にしてパッと消えてしまった時の挫折感は半端ない。
しかしそれは昔の話になった。ノートパソコンを使っている限り停電の心配はいらないし、保存に時間もかからないから、今は習慣で1行毎に保存している。
コーディングという一見地味に見える作業にもいろいろあることを言いたかったブログです。
